port I/O in Win95 v Win2k

[Guest]

Hi all,

I'm a newbie to VC++, and I'm having some trouble building an executable using some old non-visual code. I'm writing my code on a Win2k machine for use on a Win95/98 machine, using Visual C++ .NET. I'm using inp() and outp() functions from the conio.h runtime library, and they are giving me the following error:

error LNK2019: unresolved external symbol _inp referenced in function "unsigned long __cdecl read_rmd(int,int)" (?read_rmd@@YAKHH@Z)

Is this because I'm on a Win2k machine? It compiles fine in TurboC++ (Borland, I know, old school).

FYI, I'm making a function that takes in a command string and spits out a response string, for use as a .DLL with some labview code. The function controls a robot via stepper motors at a low level.

Any help would be great! Thanks!

-Fong

 

[Guest]

Another note, a workaround might be to modify my code to activate port-level control of my stepper controller card using Win2K/NT, I think. Is this correct?

If this is so, how would I go about doing this? My controller card is on an ISA bus, and I can set its base address and IRQ via jumpers. I have an NT4.0 machine with an ISA bus in addition to my W2k and W95 (w/ ISA bus) machines.

-Fong

 

[William DePalo [MVP VC++]]

Another note, a workaround might be to modify my
code to activate port-level control of my stepper
controller card using Win2K/NT, I think. Is this correct?

If this is so, how would I go about doing this?
My controller card is on an ISA bus, and I can
set its base address and IRQ via jumpers. I have
an NT4.0 machine with an ISA bus in addition to
my W2k and W95 (w/ ISA bus) machines.

No version of NT (3.5x, 4.x, 2K, XP, 2K+3) will allow low-level direct
access to the hardware in 32 bit application. That is to say you can't try
to access the I/O ports associated with a serial or parallel device, but you
can call an API (e.g. ReadFile(), WriteFile() etc) which will call the
device driver which will do the job.

If you need to do this, you either build a driver or buy a third party
tool-kit that has kernel mode components.

(There is some emulation/virtualization that NT does for 16 bit applications
but I am not sure of the details).

Regards,
Will

 

[Guest]

Thanks Will, for your response
Unfortunately, the vendor of the card does not have a driver for NT, and don't plan on making one

So how can I make my compiler just build my code for a Win95 machine then? It compiles fine by itself, but won't put the .DLL together for me. Thank

-Fong

 

[William DePalo [MVP VC++]]

Thanks Will, for your response.

You are welcome.

So how can I make my compiler just build my code for a Win95 machine then?

Sorry but I won't be much help. If I remember correctly, 95 is
schizophrenic. In other words, where NT sees stability important, 95 values
compatibility with DOS more highly. So, sometimes it pretends to be a
modern, protected-mode 32 bit operating systema and sometimes it shows its
DOS heritage. I think the same NT rules apply where 32 bit applications are
concerned. However, if you have the tools, you may be able to build a 16 bit
application that does bad old DOS tricks and run it on 95. I might be wrong.

Note that _no recent_ MS compiler will build a 16 bit application, they got
out of that business at least 5 years ago.

If you want to build a driver yourself, you can order the device driver kit
from MS (~ $25 in the US) and spend 6 months wading through examples to
learn how, or you can buy a toolkit such as this (this is not a
recommendation, just an option)

http://www.compuware.com/products/driverstudio/

There are other options, too. At http:www.lvr.com you will find some info on
programming serial and parallel devices which might be useful.

Regards,
Will

 

[Guest]

Thanks again, Will

One of my friends suggested I try using "_inp" instead of "inp", "_outp" instead of "outp" in my code, but wasn't sure what it would do. I recompiled it using a global replace inserting that underscore, and now it compiles fine! Any idea what happened, and whether I will see any issues because of this? He thought it might be somehow accessing assembly level functions

I haven't had a chance to try my DLL out on my test computer yet due to some Labview issues, so I can't just test it directly at this time

-Fong