| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | What would it take? |
[ David Lewis writes ] DL|What would it take to add Win95 compatibility to Warp? How would |it run, like the current Win-OS/2 in a DOS VDM, or as a 32-bit |application in its own address space. What exactly would have to |be written, some VDDs or DLLs or what. In another conference (comp.os.os2.programmer.misc) there is currently a discussion about the origins of Windows NT. To sum it up, NT is based on the code to OS/2 that MicroSoft had license to when the divorce occurred. In fact, originally Windows NT was to be known as OS/2 NT. AND, NT will run OS/2 16 bit code unmodified. AND, NT comes with three file systems; FAT, NTFS, and HPFS. Apparently, NT's kernal is _essentially_ OS/2 kernal. Now, IBM is currently working to provide a Developers API extension, which is essentially a renaming of some calls and the introduction of certain others. This will allow a core of over 200 system calls to be shared between OS/2 and Win32. The problem is that there are hundreds more calls which are not supported. And there are some fundamental differences between the Windows system and OS/2 including a different graphics origin (OS/2 has origin in the lower left corner of the window, Windows uses the upper left), as well as different system structures. The extensions will not allow the running of Win32 programs, rather it will allow compilation of Win32 code into OS/2 code, although programs using the Win32 code, will not have complete access to OS/2 system code. And finally, OS/2 for the PowerPC is based on a kernal technology which was originally envisioned as an Operating System Integrator (to the best of my knowledge, my own term). The kernal would allow different Operating Systems to co-exist on the same processor. So where does this leave us? Apparently, Windows NT and OS/2 are significantly the same at the kernal level. The ability to run both shells natively at the same time would however require more than just a dll. Device drivers could be shared between the two systems as this involves the kernal. But because applications under OS/2 and Win32 see different address space models, the system would have to provide both or provide a loader which could distinguish the two and load Win32 programs to OS/2 spec. However, if you don't mind not running Win32 natively, it seems that it would be easy enough to provide an OS/2 program which could run Win32 applications by running those parts of the program which were not system, and reformating all Win32 system calls to OS/2 calls on the fly. One drawback here would be that any Win32 program would necessarily run more slowly under OS/2 than under Windows95, all else being the same. And if a developer could develop for only one platform and automatically have access to both, that's probably what he would do (case in point: WordPefect). And if OS/2 would always run any given program more slowly than Windows95, why would anyone want OS/2. Another, (and this would also pertain to a parallel gui as described above) is that if IBM came out with the perfect emulator, MicroSoft could break it, by providing new functionality which was contrary to the implementation of the emulator. And of course, because we already see books providing descriptions of Win32 internals, anything that runs Win32 code would need to provide a number of undocumented features and "side effects". This means that OS/2's Win32 subsytem would be completely at the mercy of MicroSoft. So IBM is not interested in providing a Win32 emulator. That's why they're providing the developer extensions; so developers will be able to more easily port Win32 code to OS/2. And if its easy enough, everyone will. After all, right now there are an estimated ten million users of OS/2. If adding five percent development time will allow a company to have products in both markets, why wouldn't it. Of course this would still allow an independent developer to provide an emulator, but any emulator would necessarily be limited. Thus, it would probably be relatively easy to provide an emulator which would run all Win32 programs currently available, but there could be no guarantee that it would run programs which become available a year from now. So, what's the answer to Mr. Lewis's question? There are any number of ways that a Win32 subsystem/emulator could be implemented. And there are drawbacks to each of them. However, the more comprehensive the setup, the more difficult the project. And perfect emulation would certainly inspire retribution from MicroSoft. ___----------------------------------------------------------------- Thos "I'm not an expert, but I play one online" Davis ___ X SLMR 2.1a X --- Maximus/2 2.02* Origin: OS/2 Shareware BBS, Fairfax, VA: 703-385-4325 (1:109/347) SEEN-BY: 50/99 270/101 620/243 711/401 409 410 413 430 808 809 934 955 SEEN-BY: 712/407 515 517 628 713/888 800/1 7877/2809 @PATH: 109/347 716 13/25 396/1 270/101 712/515 711/808 809 934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.