Subj:  Win32s: W32 Subset 4 W31                Section: Product Information
From:  Alistair Banks/Microsoft 73740,3417     # 1144, 3 Replies 
  To:  All                                     Date: 26-Feb-92 06:58:07

"Win32s(TM): The Win32(TM) Subset API for Windows 3.1"

There's been allusion and rumour about something we call "Win32s" recently
- We've now officially announced it, so I'll explain...

Here and elsewhere we've explained many times that Win32 is a single new
API which will be first made available in Windows NT this year, and later
in a major update to Windows on MS-Dos.

Win32s is a developers toolkit which delivers a binary compatible subset
of the Win32 API on Windows 3.1. As Win32 is defined as "the Win16 API
stretched to portable 32-bit + new functionality", so Win32s API is
exactly that subset of Win32 without the "new functionality".

Late in Win3.1's development cycle, we defined some hooks that we'll
document under our "Open Tools" banner, which allow a VxD to load to
handle the new flat Win32/Windows NT .exe type. You may have already heard
of "BigWin" & other "Windows extenders". Win32s is a combination of VxDs
and .dlls (a runtime) which adds on to Win3.1 to support Win32 32-bit
binaries on Win3.1. All the Win32 APIs are included in the Win32s .dlls,
and those which aren't functional simply return an error code.

So you can develop one Win32 app, & have it start a thread. On Win3.1 that
CreateThread call will return an error, so you take "Plan B", and on
Windows NT the call will succeed, so off you go... Error returns will be
given for all functionality beyond that in Win16 including beziers, paths,
memory mapped file i/o, semaphores, etc, but given the clean error return,
you can choose to write a single binary that works on Win3.1, and yet
fully exploits the features of Windows NT.

We think Win32s will bring more market justification (in the the large
Win3.1 installed base) to bring Win32 applications to market more quickly,
and therefore allow Windows NT to succeed more quickly than it might,
given only Windows NT's technical merits.

Win32s: Details...

Win32s toolkit comes from Microsoft's languages group & will include their
forthcoming 32-bit C & C++ compiler and the Win32s runtime for Win3.1.
This runtime & an installer will be shippable by developers for no-royalty
with an application that uses it. Therefore, the application created will
work on any enhanced mode Windows 3.1, and will not require any further
upgrade to Windows (last year, Windows was shipped onto >80% 32-bit
platforms). Microsoft will be agressively promoting Windows 3.1 &
upgrades. We have no doubt that Win3.1 & Windows NT will be by far the
highest volume platform for 32-bit graphical applications. We also believe
that a Win32s application will be suitable for every catagory. Win32s will
be available mid-year, in the same timeframe to the same people as the
Windows NT SDK - clearly we expect Win32s & Win32 development to be "in
tandem".

Since we're leaving the Win32s interfaces open, with our "Open Tools"
policy, we expect other 32-bit Windows extenders to be developped or
upgraded to Win32s functionality to be shipped with other development
tools. As announced previously, the Win32s functionality will be shipped
with Windows on MS-Dos itself in a future major upgrade which supports the
full Win32 API.

There's one exception to the rule that Win32s adds no functionality beyond
32-bitness & Win16 APIs - We're great fans of structured exception
handling, and we want every Win32 application to use it, so we've included
that functionality in Win32s. You can read about structured exception
handling in the Win32 API Specifications, available on MSOPSYS, lib 2 "ISV
Communications", and now available in printed form from MS-Press.

The full Win32 functionality is very compelling, and an argument could be
made to add each new feature to Windows (we're working on that!), but we
consider the timely delivery of Win32s to be its most important priority.

Architectural Issues:

A Win32 application using the Win32s toolkit will find some of its APIs
serviced within a 32-bit VxD, and some of its APIs serviced by the 32-bit
.dlls. In general "base" functionality will go to the VxD, and the
equivalents of Win16 APIs in the .dlls.

Win32 applications can't use Int XX functionality, so the Win32s VxD has
Win32 entries for each Int 21 & various other Int XX (BIOS) calls. The
Win32 memory management APIs are directly implemented in the Win32s VxD
(you can't map 32-bit memory management to 16-bit reasonably) and the Int
XX equivalents are mapped back to the virtualised MS-Dos.

The Win32s .dlls "thunk" back to Win16 - As a Win32 application makes a
call, so its 32-bit parameters are copied from the 32-bit stack to a
16-bit stack, and the 16-bit entry point is called. You'll notice that
you're only very allocated Window handles up to 0x0000FFFF, as you'd
expect, but don't assume it, since that won't be true when you run the
same binary on Windows NT.

There are other semantic difference between Win3.1 & Windows NT - Win3.1
runs Win32 apps non-preemtively in a single shared address space, while
Windows NT runs them pre-emptively in seperate address spaces. Its
therefore important that you test your Win32 app on both Win3.1 & Windows
NT, and that you use DDE_SHARE memory, when you really mean it to be
shared.

If you need to call 16-bit functionality from 32-bit code, you'll have to
do this using "RPC" or client-server techniques. Your 32-bit app would
package its parameters into a data structure and send it as a message to a
dummy 16-bit .exe which would call the 16-bit .dll on its behalf. DDE,
OLE, Clipboard, Metafile, Bitmaps are all interchangeable between Win16 &
Win32 applications on both Win3.1 & Windows NT.

Win32s: Speed & other comparisons:

Q: How much faster will a Win32s app go on Win3.1 than a Win16 app?

A: It depends how often you cross the "thunk" boundary, and how much
simpler your data access gets using 32-bit access. The thunks are an
overhead (<10% per call), and the simpler data access speeds up
applications. The answer will be different for each application.

Architecturally Win32s provides 32-bitness in the same way as OS/2 2.0 -
OS/2 2.0 provides a 32-bit API over 16 bit drivers, 16-bit file systems,
16-bit graphics engine (PMGRE & PMGPI), with 32-bit kernel & memory
management; Win3.1+Win32s has 32-bit drivers (VxDs), some of which call to
16-bit file systems (MS-Dos in Virtual mode), & some of which directly
implement functionality (Win32s Memory Management), a 32-bit pre-emptive
kernel (Windows enhanced mode), 16-bit graphics and windowing (GDI &
USER). Both OS/2 2.0 & Windows 3.1 contain various drivers which use
32-bit capabilities when they find them, and both offer backward
compatibility for 'old' 16-bit drivers. Both Win3.1 & OS/2 2.0 have an
architecture that allows 16-bit pieces to be replaced with 32-bit pieces
selectively, as the work is done.

IBM is claiming that 32-bit apps give you great speed advantages. We're
more conservative, but believe that in general 32-bitness will speed up
your Windows application more than thunking will slow it down. In any
case, the architecture is very competitive, and a great step while we work
on a 100% 32-bit Windows on MS-Dos to match our 100% 32-bit Windows NT.

Summary: Win32s fills a percieved "gap" sooner between Windows on MS-Dos &
Windows NT by providing a common, binary compatible 32-bit API between
them. It'll be available to developers in the same timeframe as Windows NT
is, and it will make Windows 3.1 & Windows NT the highest volume 32-bit
graphical platform soonest. It makes life simpler for developers,
particularly those not used to segmentation, and in general, faster.

-- Alistair