🚀 go-pugleaf

Paolo Marcucci (marcucci@oat.ts.astro.it) wrote:

> To set things right, win32(s) is a collection of modules that turns
> windows into a 32 bit os. A *real 32 bit* os. The tunkye thing is for 
> os modules that are not modified by the installation of win32.

> Installing win32 will create a \windows\system\win32s directory where
> those modules are stored. Their names are (almost) the same of the
> standard 16 bit versions, but the api is slightly (!) changed.

> So, applications that makes use of the win32 api will run in a 32 bit
> workspace, while normal windows apps will run with the old 16 bit win
> modules.

> That's the reason why some 32 bit programs run faster on an os that
> looks like 32 bit. They make use of all the api provided by win32.


No offense, but that's not correct.  Win32s thunks essentially *all*
Win32s API calls down to Win16.  While the Win32s app is running in 32-bit
mode, all Win32s API calls consume additional thunking overhead and then
run in 16-bit mode.  This is why Win32s apps can actually run slower than
corresponding Win16 apps; they only run faster if they do a lot of
internal 32-bit processing. 

This changes somewhat with Windows 95 (aka Chicago, aka Windows 4.0). 
Portions of Windows 95 have been rewritten from 16-bit code to 32-bit
code; other portions have not.  The result is that both 16-bit and 32-bit
apps will experience some degree of thunking.  Overall, Windows 95 should
run 32-bit apps faster than Windows 3.1 with Win32s. 

Best regards,
John  <JNavas@Netcom.com>