-Problem- 16 Bit Comm Port Access in Windows NT 
Author Message
 -Problem- 16 Bit Comm Port Access in Windows NT

We have a package originally developed to run on Windows 95 / Windows 3.1 /
WfWg which communicated with external hardware via the PC's serial ports.
This has worked well in Win 3.11 / wfwg / 95 but attempting to use the
software in NT causes problems.

The software is coded in the current version of Visual C++, and we _have_
to use the comm ports via the WOW interface. We do not have the resources
to re-code the applications for 32-bit operation and a large amount of the
code is contained in VBXs.

It appears that the comm port messages are being intercepted before our
code sees them, so we are effectively missing the interrupt messages etc.
for incoming data. Also, we have _Never_ been able to get COM1 to work on
an NT 4.0 Workstation. We can find no apparent reason for this.

So, the question, has anyone had any previous experience of this particualr
problem? Or can you tell me a way to implement serial communications in
NT4.0, without resorting to 32-Bit code (as we do not have the resources
available to re-write the rest or our software). We have seen that some
16-Bit comms packages run by constantly polling the serial port, but we
ideally do not wish to do this as it is a somewhat inelegant solution.
(unless it is the only way).
Any information on accessing the serial ports, in Visual C++, on NT
Workstation will be gratefully recieved.

I apologise in advance if my query is a little vague as i am carrying out
these requests for my colleague who writes the software. If you have any
queries or require any more information please email me at:



Thanks

Matthew Bednall



Fri, 06 Aug 1999 03:00:00 GMT  
 -Problem- 16 Bit Comm Port Access in Windows NT


Quote:

>We have a package originally developed to run on Windows 95 / Windows 3.1 /
>WfWg which communicated with external hardware via the PC's serial ports.
>This has worked well in Win 3.11 / wfwg / 95 but attempting to use the
>software in NT causes problems.

NT does not allow win 3.1,dos and win 3.11 apps to have direct access to
the hardware. this is why dos games do not have sound in NT (eg. DOOM)
dos drivers and windows drivers are not allowed to have access to the sound
card,com ports,the video card etc. there might be a library available to allow
a 16 bit program to access hardware in NT. I don't know of one, but i am
sure someone has tried to solve this problem.
Quote:
>I apologise in advance if my query is a little vague as i am carrying out
>these requests for my colleague who writes the software. If you have any
>queries or require any more information please email me at:



>Thanks

>Matthew Bednall



Sat, 07 Aug 1999 03:00:00 GMT  
 -Problem- 16 Bit Comm Port Access in Windows NT



Quote:
> We have a package originally developed to run on Windows 95 / Windows 3.1
/
> WfWg which communicated with external hardware via the PC's serial ports.
> This has worked well in Win 3.11 / wfwg / 95 but attempting to use the
> software in NT causes problems.

...


> Thanks

> Matthew Bednall

I've had a similar problem with a Win16 app not being able to access the
comm port.  Under Win95, I was able to use mkcompat.exe and fix the
problem.  NT does not have this, but I have heard that there is a similar
utility for NT.

Does anyone know the name of this utility and where I can find it?  It must
exist! Oh, please, exist!

-Michael Sparks



Sat, 07 Aug 1999 03:00:00 GMT  
 -Problem- 16 Bit Comm Port Access in Windows NT

Quote:


>>We have a package originally developed to run on Windows 95 / Windows 3.1 /
>>WfWg which communicated with external hardware via the PC's serial ports.
>>This has worked well in Win 3.11 / wfwg / 95 but attempting to use the
>>software in NT causes problems.

>NT does not allow win 3.1,dos and win 3.11 apps to have direct access to
>the hardware. this is why dos games do not have sound in NT (eg. DOOM)
>dos drivers and windows drivers are not allowed to have access to the sound
>card,com ports,the video card etc. there might be a library available to allow

This is not entirely true. I have several Win3.x apps that run perfectly
under NT. Various communications programs can access COM ports, I have
several  Win3.x games that can use sound without any special drivers, other
than those that came with NT. Why don't we find out what kind of access the
program needs to have before writing it off completely.

********************************************************************************


* Opinions - Mine Only             http://pages.prodigy.com/VA/wjake/home.html *
********************************************************************************



Fri, 13 Aug 1999 03:00:00 GMT  
 -Problem- 16 Bit Comm Port Access in Windows NT

Correction below.



Quote:

> >>We have a package originally developed to run on Windows 95 / Windows
3.1 /
> >>WfWg which communicated with external hardware via the PC's serial
ports.
> >>This has worked well in Win 3.11 / wfwg / 95 but attempting to use the
> >>software in NT causes problems.

> >NT does not allow win 3.1,dos and win 3.11 apps to have direct access to
> >the hardware. this is why dos games do not have sound in NT (eg. DOOM)
> >dos drivers and windows drivers are not allowed to have access to the
sound
> >card,com ports,the video card etc. there might be a library available to
allow

> This is not entirely true. I have several Win3.x apps that run perfectly
> under NT. Various communications programs can access COM ports, I have
> several  Win3.x games that can use sound without any special drivers,
other
> than those that came with NT. Why don't we find out what kind of access
the
> program needs to have before writing it off completely.

Actually, what Matthew asserted is entirely true.  Those Win3.x games are
using API's that are available on the NT WOW process.  The COM ports are
virtualized well enough that many serial communication programs still run.
They are trying to access the serial port, but the attempt is trapped and
the OS figures out how to achieve the same effect as if the access had
been successful.  But no hardware access is permitted to applications.

That said, it may indeed be too soon to write off using that package on NT.

--
-- Larry Brasfield
The aforementioned views are mine alone.



Fri, 13 Aug 1999 03:00:00 GMT  
 -Problem- 16 Bit Comm Port Access in Windows NT
Quote:



> > We have a package originally developed to run on Windows 95 / Windows 3.1
> /
> > WfWg which communicated with external hardware via the PC's serial ports.
> > This has worked well in Win 3.11 / wfwg / 95 but attempting to use the
> > software in NT causes problems.

> ...


> I've had a similar problem with a Win16 app not being able to access the
> comm port.  Under Win95, I was able to use mkcompat.exe and fix the
> problem.  NT does not have this, but I have heard that there is a similar
> utility for NT.

> HHHHHH



Fri, 13 Aug 1999 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Accessing Windows NT Registry from a 16 bit application

2. Problem with using 16 bit getmodulehandle in Windows NT

3. Launching and Monitoring a 16-bit Windows app from VB5 application running on Windows NT 4.0

4. How to detect 16-bit Windows-based application running under Windows NT

5. Launching and Monitoring a 16-bit Windows app from VB5 application running on Windows NT 4.0

6. Help..-NT 4.0-ISA access with 16 Bit GFA and 32 Bit DLL

7. VB Support for Parallel Port in NT 4.0, 16 Bit

8. Problems with 16 bit Crystal Info on Windows 3.11 (Windows for Workgroups)

9. Unable to run VB4 16-bit app in Windows NT u62148@uicvm.uic.edu

10. Windows NT WOWEXEC Won't allow VB 4.0 16-bit app to terminate

11. VB 4.0 16 bit application written on Windows 3.11 for Win NT 4.0

12. Windows NT WOWEXEC Won't allow VB 4.0 16-bit app to terminate

 

 
Powered by phpBB® Forum Software