Xref: utzoo comp.os.msdos.misc:1999 comp.windows.ms:12437 comp.os.os2.misc:1277
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!netcomsv!resnicks
From: resnicks@netcom.COM (Steve Resnick)
Newsgroups: comp.os.msdos.misc,comp.windows.ms,comp.os.os2.misc
Subject: Re: OS/2 2.0 is here! vs Windows 3.0 vs NeXT/MACH
Message-ID: <1991May9.003009.14478@netcom.COM>
Date: 9 May 91 00:30:09 GMT
References: <1991May7.164109.13128@amd.com> <-47gvh+@rpi.edu> <1991May8.214231.28026@amd.com>
Sender: netnews@netcom.COM (USENET Administration)
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 44

In article <1991May8.214231.28026@amd.com> phil@brahms.amd.com (Phil Ngai) writes:
>barryf@aix01.aix.rpi.edu (Barry B. Floyd) writes:
>>compelled to run what I got on top of OS/2. Unless some mighty special 
>>magic is performed by OS/2, I suspect Win 3.0/DOS app's running on top
>>of OS/2 will not perform better than running as is in their native
>>environment.

(Sorry - I missed the original)

The "magic" is that the kernel of OS/2 is re-entrant where as DOS isn't
Even when windows is running. As an example:

Task a opens a file 
task b opens a file.

Under DOS/Windows, if a task switch occurs when task a is in the middle of
a DOS call, task b will be blocked until task a finishes his call. 

Under OS/2 task a and b may access the operating system "simultaneously"
(not really, but you know what I mean)

There are other issues with Windows that aren't present in OS/2. In Windows,
if you allocate memory, you are given a "handle" rather than a pointer.
This handle must be locked and released as it is used. In OS/2 when
you allocate memory, you are given a "handle" in the form of a selector.
There is not need for the program to lock or unlock this handle becuase it
is handled inherently by the procesor and the OS. Windows cannot do this 
because it needs to be able to run in real-mode where you don't have selectors
or a real virtual memory manager. I have several Windows programs which
are direct ports to OS/2. These programs perform much like their Windows
counterparts in that they deal with the locking and releasing of memory
which ultimatly hampers performance.


 - Steve

-- 
-------------------------------------------------------------------------------
        resnicks@netcom.com, steve@camphq, IFNA:        1:143/105.0, 
                 co moderator for comp.binaries.os2
 Real life: Steve Resnick. Chief Software Architect, Process Scientific, Inc
 Flames, grammar and spelling errors >/dev/null
 The Asylum OS/2 BBS - (408)263-8017 12/2400,8,1 - Running Maximus CBCS 1.2
-------------------------------------------------------------------------------