From: db3l@ans.net (David Bolen)
Subject: Re: Utils dont work in a window - WHY?
Date: Mon, 5 Oct 1992 11:07:00 GMT
	<price.717967414@helios><unruh.717986584@physics.ubc.ca>
	<1992Oct02.031942.12161@ans.net> <1992Oct5.120038.11229@waikato.ac.nz>
Organization: Advanced Network & Services, Inc. - Elmsford, NY

In article <1992Oct5.120038.11229@waikato.ac.nz> hamish@waikato.ac.nz writes:

>> Well, an OS/2 window is attached to an OS/2 session.  Therefore, it
>> contains none of the DOS emulation support necessary to execute DOS
>> executables.  (...)    [and it requires some work to link the DOS session
>> to the OS/2 session for all but the simplest DOS output programs]
>> 
>> This doesn't mean it can't be done - who knows, maybe IBM is working on it.
>> It would certainly be nice for all the simple command line DOS utilities
>> out there.
>
>A big load of bullocks. Having the VDM code check change its output from one
>window to another would be one of the simplest things to re-code. All it has
>to do it redirect its output from a window that it would open, to a window
>that is already open.

Well, I've never seen any of the source to handle OS/2 or DOS windows, so
I don't think I'm qualified to say whether it's a "big load of bullocks" or
not.  Are you?

>There is no need to adjust for different windows etc. If it will
>display on one PM window  the API to display on another won't change... If it
>does then OS/2 is a mess, and I can't see that somehow.

Sure there is.  Think about it this way:


	386 prot mode - ring 3	OS/2 Process	----->	  OS/2 Window
			    	      \
			      	       \
			                V
	386 virt 8086 mode   	    DOS Process	----->	  DOS Window


Normally, you start a DOS command in the OS/2 process (which already owns
and manages its window, and which runs the *86 processor in protected mode,
ring 3).  In order to process the DOS setup, whether its in a separate or
same window, OS/2 has to create a new task that runs in the *86 virtual
8086 mode, and start up DOS emulation.

Now, in this new task, I would imagine it is very difficult, if not
impossible for the DOS task to directly issue window output calls to the
previous OS/2 window.  All of the various handles would have to be
converted into something valid within the virtual 8086 addressing space,
and a DOS task addressing, and a DOS task can't directly transfer through a
call gate to the OS/2 system calls (or the emulated call gate OS/2 may
still use).  At the least you'd need context switching for every call in
order to get into protected mode to execute the code, which would probably
be an unbearable overhead.

So what you need to build is a layer that allows the DOS process to make
requests of the OS/2 process to display things in it's window (akin to how
fsfilter lets you access disks through the HPFS driver I suppose).  This
isn't impossible, and as I mentioned in my previous post I hope IBM works
on it, but I'm not going to stand up and claim it's trivial, because (a)
I'm not sure I know all the factors involved and (b) even without knowing,
I don't think it is (IMHO).

Now if you know stuff about the internals I don't and you know it's easy,
then that's great - but if not, I'd think before claiming it's trivial
(which is how I interpreted your "bullocks" comment... what's a bullock
anyway?)

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/
Newsgroups: comp.os.os2.misc