🚀 go-pugleaf

Microsoft today has a real-mode operating system, a 286 protect-mode and
a 386 protect-mode operating system packaged as one product, and is soon
to release a 32-bit secure pre-emptive multi-processor portable operating
system

The distinguishing features of these OSes relate to programming interfaces and
the applications written to them, and to issues surrounding hardware and
driver support.

We've also shipped with the Win32 SDK for Windows NT "Win32s" a sub-set
implementation of the Win32 API for Windows 3.1. We've also shipped a version
of Windows 3.1 with workgroup extensions, and announced that those extensions
will be in Windows NT 3.1. We've shown "Modular Windows", a scaled-down
version of Windows for consumer markets, and we've explained how OBject Linking
and Embedding Version 2.0 grows to become a completed distributed system in
future releases of Windows.

The point I'm trying to make is that an operating system division between
Windows 3.1 and Windows NT 3.1 is not the right split for newsgroups which
more usefully should be split according to the issues they are likely to
discuss and the audiences participating.

I would suggest that programmers discuss programming interfaces, those
being Win16 & Win32, with both of those being supported in Windows 3.1
and Windows NT 3.1. I would suggest that users often worry about setup
issues, particularly hardware configuration and driver support.

I would suggest that some applications, and some programming tools have
such a following as to deserve to be broken into their own group, but
I would strongly recommend that all the above pertain to one scaleable
operating system family called Windows ("NT" is a trademark of Northen Telecom
and our operating system is always called Windows NT, and on Compuserve
WinNT is used for its short forum name)

comp.os.ms-windows.win32 is already set up as _the_ place for Win32-related
programming issues. This would be improved by the removal of setup and
driver-related questions to a new group comp.os.ms-windows.setup.winnt. If
specific platforms such as dec alpha, mips, or intergraph clipper have their
own issues, these could be further split out later. If Symetric MP machines
have their own setup issues, these could be further split out.

Programming for the Win16 API is consistant whether you're on Windows 3.1
or running the same app on Windows NT 3.1.

Programming to the Win32 API has 2 scaleable uni-processor x86 variants
today, with 3 announced RISC platforms, and Symetric MP demoed up to 16
processors. I think it would serve programmers better to group these
discussion together, since they have a great deal in common, and with better
support of the Win32 API destined for Windows on MS-Dos, they will only have
more in common as time goes by.

So I'm making a plea not to break Windows-related discussions into
unrelated groups based upon current product packaging, but
rather into audience-related groups, and to recognise Windows is a
scaleable family of implementations of the same API and same user
Interface with the same applications running on each.

So I'd suggest the creation of comp.os.ms-windows.setup.winnt today,
and perhaps comp.os.ms-windows.winnt for topics like "has app A
by vendor B been tested on Windows NT 3.1?" - "what POSIX apps have been
ported to Windows NT?" - "Dos this ms-dos application violate
Windows NT's security mechanisms?" Perhaps also comp.os.ms-windows.workgroup
and comp.os.ms-windows.modular, comp.os.ms-windows.pen for product
related miscalaneous questions - Perhaps each of these should be nodes off
the comp.os.ms-windows.misc tree? Perhaps the .misc tree doesnt need
to have a seperate winnt section if programmers and setup issues are
handled elsewhere, and religious discussion is kept to the .advocacy
group?

When we provide support, we find it much the most efficient to divide
our groups into user-related and programmer-related groups, and then
into product related issues within user-related, like setup & device
support, and into api-related groups within the programming groups,
with divisions for DDK-related programming and some specific APIs
like ODBC, MAPI, OLE, Pen, etc

-- Alistair Banks, Microsoft Systems Division