TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: David Lewis
from: Thos Davis
date: 1996-01-26 04:54:04
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™.