Is there anyone out there who can help?. I am an embedded programmer who is
developing a windows application to run on Windows NT, 98, 95.
Could anybody tell me the differences between developing an MFC application
for Windows NT, 98, and 95.

Peter,

More often than not, there are no significant differences for the
programmer - until you push the limits in some form or another.

For example, Window 9x has a 16-bit heritage - it's GDI (Graphics
Device Interface) is still 16-bit and as such is limited to +-32K
co-ordinate range.

Only Windows NT has a full implementation of Unicode, Windows 9x has
functions to convert back and forth between Unicode and multi-byte
characters, but none of the APIs are inherently Unicode.

If you need to do low-level device driver programming, then they're
all subtly different - and I don't envy your task.

If you've not yet read a basic Windows programming book - such as
Programming Windows by Charles Petzold, I suggest that you invest in a
copy, as coming in from developing embedded systems will be something
of a shock (it was for me).

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.

It is quite practical to develop one app that runs on all versions -- they are
all referred to as Win32.  There are, however, many advanced APIs that are
available only on NT.  Check the quick info section of every API function you
use -- it tells about supported/not supported on the various versions.

If you need to support all three you can develop one single exe to run on all
three but it will be quite important to test it thoroughly on all three.

There is only one MFC -- it works on all OS versions.

There are significant performance, reliability and operational benefits in NT,
especially relevant in embedded-like applications.  If you don't have to support
9x there are lots of reasons to stick with NT exclusively.

--
Scott McPhillips [VC++ MVP]

You've already go a lot of good advice here. Here's
an article from the MS web site:

http://msdn.microsoft.com/library/psdk/win95/chilimit_2y5v.htm
This details many of the limits in the Windows 95/
98 architecture.

and a brief note: almost all API calls documented under
platform SDK have a 'Requirements' section at the bottom,
(called QuickInfo in older versions) that tells you what
versions of what platforms support the call. Also note the
remarks and parameters sections; there are often
subheadings for platform differences, like so:

WriteFileEx
......

Parameters
hFile         [in] Handle to the file to be written to. This file
handle must have been created with the
FILE_FLAG_OVERLAPPED flag and with GENERIC_WRITE
access to the file.

Windows NT/ 2000: This parameter can be any handle
opened with the FILE_FLAG_OVERLAPPED flag by
the CreateFile function, or a socket handle returned
by the socket or accept function.

Windows 95/98: This parameter can be a communications
resource opened with the FILE_FLAG_OVERLAPPED
flag by CreateFile, or a socket handle returned by socket
or accept. You cannot perform asynchronous write
operations on mailslots, named pipes, or disk files.
.........

Remarks

Windows 95/98: On this platform, neither WriteFileEx nor
ReadFileEx can be used by the comm ports to communicate.
However, you can use WriteFile and ReadFile to perform
asynchronous communication.

Requirements
  Windows NT/2000: Requires Windows NT 3.1 or later.
  Windows 95/98: Requires Windows 95 or later.
  Header: Declared in Winbase.h; include Windows.h.
  Library: Use Kernel32.lib.

MFC was designed largely platform-independent, at least for the 32-bit
world. So a pure MFC based program should work on all 32-bit windows
versions.

but some common controls have features built in that need the functionality
of win98 and/or IE4 or later, such as flat or transparent toolbars
(TBSTYLE_FLAT, TBSTYLE_TRANSPARENT)

this is the theory. but I don't know any exeptions to the rule, sorry 8(

Thorsten

Also, develop it for NT first and then check it out on the Win9x platforms.
I started off doing it the other way round. There are a lot of parameters to
system calls which are ignored in Win9X but not in NT. There are some subtle
"gotchas" as well, in things like manipulating the registry.

You have got a lot of good advice already...while all these are true, I feel
there is no substitute for testing, even some of the MFC classes doesn't
work across all the platforms the same way. !!!

Unfortunately some of these things are not very well documented and
debugging these makes your schedule meaningless.(well, I am talking from
experience)

anyway, good luck.