>>It requires a fuller implementation of the Win32 API than is made available >through WIN32S, the subsystem used in conjunction with Win3.x to partially >support Win32 applications. WIN32S is no longer an officially supported >platform for Microsoft, and has never been a stable and reliable option for >using Win32.
>
>I think WIN32S is already installed. I knew that Win 3.1 needed a bunch of extra files so I used the Setup Wizard to create an install program for my app, and selected that I wanted WIN32S included.
>

I think you're missing what I'm saying, so I'll expand what I said a bit, and maybe it will make some sense.

Win3.x is a Win16 system; it's based around a memory model that doesn't in and of itself support the 32 bit linear address sapce, and many of the features that give the more advanced Win32-based operating systems their real power and features.

When the 32 bit Windows envrionment was introduced, virtually everyone was still using the Win16 environment from Win3.x, and Microsoft needed a way to make some of the newly emerging Win32 technologies available to the Win16 environment. They developed a piece of code, the WIN32S subsystem, which in a limited way added some Win32 capabilities to Win16. The areas added were primarily the ability to work with the 32 bit linear adress model used by Win32 applications, and a limited access to some of the Win32 API, mostly done by mapping calls to the Win32 API back to Win16 calls.

This allowed some of the original Win32 applications to be run under Win16. However, the supported Win32 model was very limited in scope. New capabilities added to Win32 that didn't exist in Win16 in the first place generally were not supported, and the general operating system enhancements like ActiveX and OLE Automation using the Win32 model were never supported.

WIN32S was found to be a rather unstable environment, and with the widespread acceptance of Win95, Microsoft decided not to continue supporting, much less enhancing, the WIN32S environment about a year after the introduction of Win95. While it was still available, it didn't gain capabilities, and Microsoft no longer provided technical support for it.

The changes that enhanced the Win32 environment subsequent to the termination of development of WIN32S resulted in major improvements and changes in the Win32 environment, to the point that now, virtually no new software for the Win32 environment will run under WIN32S. This is why VFP5 and later won't run under Win32S - the products exploit features not present or supported in WIN32S. Win32S never supported changes in the driver models, new API entries, or from a practical perspective, any of the Win32 technology beyond the use of the linear address space, and it isn't going to be enhanced to do so. From this perspective, it's a dead end.

MSCOMM32 uses the ActiveX/OLE Automation interface, which while VFP can support the interface, the underlying operating system can't, so MSCOMM32 isn't going to work for you. You have two choice - get your Win16 users to upgrade to a more stable and current environment so that you can use MSCOMM32, or find something other than MSCOMM32 to handle communications using the Win16 interfaces.

Some things to consider - moving to Win98 will retain the ability to run the vast majority of Win16 and DOS Applications (there are exceptions; I've had to find alternatives for a few pieces of software that wouldn't run under anything but Win3.x, and there are plenty of DOS programs like games that are not well-behaved in the Win9x environment), will be able to support newer hardware more completely, and you'll be able to make use of more of Microsoft's key technologies in the Win32 environment. And at this point, more and more of the new hardware coming out relies on changes in the hardweare environment, too - devices designed for PnP environment, for example, are easier to use wiuth Win9x than with Win3.x, and in fact some new hardware has no drivers available at all for the WIn16 model.

In short, give your users a choice, continue with Win16 and pay you to find something that'll do the low-level comm tasks that would be easy with MSCOMM32, or move up to current software technologies.

>My app actually works -- It comes up on the screen just like it's supposed to. It's just that the communications part doesn't seem to be working. It sits there but doesn't respond to serial input like it's designed to do.
>
>Thanks for your help
>-Jeremiah