alistair@microsoft.UUCP (Alistair BANKS) (08/19/90)
In article <6447@ncrcae.Columbia.NCR.COM> heath@ncrcae.Columbia.NCR.COM (Robert Heath) writes: >Did anyone read in the trade press recently about a means of running >Windows applications under some version of OS/2 ? What's the scoop ? Microsoft has announced two levels of solution for the above. The first is called the "Source Migration Kit" (SMK) and is a re-link solution for running Windows 3 applications under OS/2 1.2 and beyond. The theory is that Windows applications have a different .exe & .dll format than OS/2, but otherwise they differ only in what APIs they call, & in what order - so Microsoft has had an on-going project in place to provide OS/2 .dlls which provide the same APIs as in Windows 3.00 - these APIs have been implemented as a layer on top of OS/2 and Presentation Manager as appropriate - the following caveats are as a result of the 286 processor, and of the different underlying nature of the operating systems. 1. The Win3 app must be segment clean - same rule as Win3 standard or enhanced mode. 2. The 286 cannot do a sufficient job of catching invalid Int 21 & Int 10 etc calls, and so under OS/2 1.2 you must remove such calls from your Win3 code (replace them with standard C library equivalents). Under Win3 you are asked not to use these direct interrupts as they execute slower than the clean equivalents under standard or enhanced modes. 3. OS/2 has a superior protection model compared with Windows - if your application relies on direct memory access with another cooperating application, this code must be re-written. This is bad practise anyhow, and under Win3 you are asked to use the DDE_SHARE flag to do such things. 4. Windows and DOS device drivers are insufficient for reliable operation under OS/2 - therefore the minority of applications which require special device drivers for operation will need to have those device-driver portions re-written for OS/2. OS/2 & Presentation Manager now have screen, printer and mouse drivers written for the majority of devices - this point refers to a few, very special uses of device-driver code such as metafile drivers, or fax or scanner drivers. Given the above caveats, you should be able to have common .obj files for your Win3 and OS/2 efforts, re-link twice to produce two runnable executables. The SMK is currently available in Alpha form, soon to go beta, and is available to Win3 SDK customers by calling Microsoft and asking for the Windows hot-line, and then asking for the SMK. The "level two" solution is announced as a statement of direction - the SMK solution can be improved further in two ways on future versions of OS/2 - #1: If we can assume a 386/486 then we can clean up those "dirty" Int 21/Int 10 and avoid caveat #2; #2 improvement, we can make the OS/2 program loader capable of recognising Win3 .exe and .dll formats and load them successfully at run-time, i.e. load and run the same binaries as run under Win3. We have announced we would like to do this for OS/2 2.0 - but caveats #1, 3 & 4 are still in place - we would be wrong to sacrifice OS/2's protection for the small minority of Windows applications which are written to behave badly around sensible protection rules, and DOS/Windows drivers are not written for use in a protected, pre-emptively scheduled environment. It will become clearer over time that with the SMK technology and improvements referred to in OS/2 2.0, that Windows apps should be written for and tested against both Dos-Windows and these Windows-like solutions for OS/2. We believe that this work will allow people to write and purchase Windows applications, and choose DOS or OS/2 for the salient features of the underlying operating system, without being hindered by the choice of graphics API or availability of applications. Alistair Banks OS/2 Group Microsoft