Read and write port under XP from DOS window using DJGPP

[sa007jbond]

hal + writeport

Hi,
I use BC 3.1 and DJGPP for DOS programming, for READ/WRITE port
I use this two functions:
int inp(unsigned portid);
int outp(unsigned portid, int value);

This don't work under windows XP.

Is possible READ and WRITE port from DOS window under Windows XP and how?

Regards

 

[newmania]

writeport in xp

I think it can not be. Couse of most xp port drivers support only visual programming languages, like visual c++, visual basic...

 

[Epegic]

write port windows xp

It may be possible.
Windows NT/2000/XP block all direct IO access form user program so that inp()/outP() not worked anymore. You have to find any shareware/freeware port access driver and use the function calls provided. With the aid of these driver, you can access IO ports directly again. I did not tried them in DOS box but they worked on windows environment.

 

[maziar]

using com1 under dos in xp

It may be possible.
Windows NT/2000/XP block all direct IO access form user program so that inp()/outP() not worked anymore. You have to find any shareware/freeware port access driver and use the function calls provided. With the aid of these driver, you can access IO ports directly again. I did not tried them in DOS box but they worked on windows environment.

please give more comment ...

 

[Cathay]

djgpp parallel port

Dr. Dobb's journal has an article to install a backdoor for direct read write I/O port call 'giveio' I try and it works. I think it was published in late 1997

 

[Santa]

dos com1 under xp

I don't think the GiveIO stuff is recommendable.
I tried it in its time and it removes all protections
making the system very susceptible. If I remember
well, this was also NT targetted. I don't know if it would
work on W2K or XP.

Try this instead which is cleaner. It comes from Beyond Logic.

Somebody correct me if I am wrong, problem is when you want
to access a legacy ressource like COM1, to know what are the
true port addresses on the PCI bus since you bypass the HAL.

Hope this helps.

 

[Bat]

read com port in dos

There is UserPort (search in Google) to that do the job.
It give all application acces to a port, or a list of port or a range.

If there only needed E/S port open, it should not be unstable unless the code dont make awful things with the port ...)

But, I dont know if it work for DOS mode (never try)...

The other solution, is to make a VDD (the DOS app run in a Virtual Machine NTVDM - a VDD is a driver for this virtual machine, that interface a legacy driver for DOS (example) whit the 32 bit driver).
I think it can be possible to make such a driver for I/O ...

If anyone know about the subject ....

 

[vomit]

read com port in dos window

A good driver to do parallel port I/O in WinNT and later is called DLPortIO.

**broken link removed**

It contains code samples for various languages, e.g. C API:

DlPortWritePortUchar(m_dwAddr, (UCHAR)m_dwValue);

DlPortWritePortUshort(m_dwAddr, (USHORT)m_dwValue);

DlPortWritePortUlong(m_dwAddr, m_dwValue);

 

[Epegic]

djgpp example outp(

Besides drivers such as DLportIO, you have to use 32 bit compliers to write console mode program in order to work in DOS box, BC3.1 meight not work anymore.

 

[maziar]

userport djgpp

i have one programmer work in win98 and me but not run in NT/2000/XP (use paralell port)

have any way work it in win xp ?

 

[Santa]

With any deprotection stuff like BeyondLogic or GiveIO, you will
enable your old app to write/read directly to the hardware but,
as I said (and tried) before, your old app will use untranslated legacy
addresses and probably (and hopefully) read/write to unexistent
PCI bus addresses. Too bad!

If you make your own non-legacy hardware, it could probably work
since you will target real PCI bus adresses.

 

[maziar]

With any deprotection stuff like BeyondLogic or GiveIO, you will
enable your old app to write/read directly to the hardware but,
as I said (and tried) before, your old app will use untranslated legacy
addresses and probably (and hopefully) read/write to unexistent
PCI bus addresses. Too bad!

If you make your own non-legacy hardware, it could probably work
since you will target real PCI bus adresses.

can give more comment how do it ?

 

[Santa]

Well,

I stopped intensive programming for more hardware/hdl quite a time ago
but the same problem as yours bring me back to software matters
from time to time (Thanks Bill G. :x ).

I have also new hardware that I want to degug or control under
NT/W2K/XP or in-house applications that I would like to keep working
with previously made hardware but new OS.

Here we come with the protections of these OSes. Everyone would
like to drill a hole in the protection only for its own process and
useful ports. If I remember well. BeyondLogic stuff would give you
this but would, since it is its purpose, bypass the functions of the
OS that remap access to legacy hardware addresses to real physical
adresses of the hardware on the PCI (or other) bus.

Before you come to this conclusion, you sctrach your head and ask
yourself why your prog that writes to 0x3F8 does not send data to COM1.

Now, how could this corrected? I give you here my ideas, some may
perhaps not be so easily applicable or require adaptations.

In the case you have only legacy hardware you want to access, you
find where the legacy addresses have been remapped and use these
addresses. Problem is this is bound to change at each reboot and the
BeyondLogic stuff would certainly not permit you to add a stub for
resolving this before starting its wrapper around your process.
It would not either modify the I/O call in the target application so that
it accesses the good adresses. So this is not a practical way for
legacy. For the other stuff, it should work if the still alive OS does
not get in your way accessing what you would like to be your own
playground.

In my opinion. the only solution to make a legacy app with direct I/O
accesses work under NT and later is to write a legal wrapper process that
starts your process under its control (like BeyondLogic) , remaps legacy
addresses and drills the hole to the corresponding real physical adresses
(and there only, not to the legacy address). Even in this case, the OS
is not aware you are playing with its believed private stuff and could
get in your way trying to do the same job as you at the same time.
i.e. if you receive a byte on COM1, nothing garantees the OS will not
be the first to get it if you didn't remove the OS driver or the IRQ.

So, we come to the conclusion that the best way is hard. You write the
wrapper app and it calls your app but dialogs officialy with the hardware
through the OS. It means this wrapper would come with your own driver
to control the specific legacy hardware and would have to replace the OS
corresponding driver. Sob. There you need diving in the NTDDK and
you are far from a simple modification.

If you write your own app and want to call (legacy or not) hardware,
solutions exist at Compuware (ex-Numega) but if you are not
the father of the application you want to run or own the source...

I hope somebody with NTDDK knowledge could give a well informed
opinion here in case I missed something.

 

[bjwlgh]

As I know ,XP/NT/98 is working under protect mode.If you want to access the hardware,you must write the driver(VXD or WDM).I think driverstuido is the best tool for developing it .u can develop the driver using c or c++.