Windoze3 under MKS toolkit

[Dale Gass]

steveha at microsoft.UUCP (Steve Hastings) writes:
>X-Original-Newsgroups: comp.unix.msdos
>
efowler at milton.u.washington.edu (Eric Fowler) writes:
>>I have been trying to bring up windows under MKS and getting the message
>>"conventional memory is fragmented..[try it in real mode]".
>I suggest you try running Win3 under clean DOS, and make a Program Manager
>item to run the MKS shell.  Run MKS shell from inside Windows, not the
>other way around.

The problem seems to be that WIN.COM is quite fussy about having nothing
exist in memory above itself (possibly because it does virtual memory 
mappings with this memory).

A situation of having an environment located above WIN.COM when it it's
being executed occurs when using INIT.EXE and LOGIN.EXE (not by the Korn
Shell).  When LOGIN is called (usually by INIT.EXE), it prompts for the
username/password, and then overlays itself with the login shell (or
program).  However, since the environment that LOGIN wants to give to
the shell is bigger than LOGIN's own environment, the exec() call will
attempt to find another place for the environment (as overlaying the
existing environment will not work).  It is this high environment which
causes WIN.COM to fail.  (Also, doing an "exec win.com" from the shell
[with or without LOGIN.EXE] when the environment has grown to be larger
than when SH.EXE was invoked, will cause the same high-environment
behaviour.)

I have tried calling WIN.COM with programs compiled with various compilers,
with the same result.  Turbo-C, Watcom, and even Microsoft C all allocate
the environment at top of memory when there's no room to overlay the current
environment.  The surprising part is that Turbo and Watcom will overlay the
current environment in an exec() if it will fit, and use the top of memory
otherwise, but Microsoft C (from the maker of Windows) will *always*
put the envionment at top of memory, and thus will never be able to invoke
WIN.COM.

Steven has (as usual) a valuable suggestion: using plain old COMMAND.COM to 
invoke windows, from which you can invoke multiple MKS logins/shells.  This is
probably sufficient for most people (although it won't work in the case 
where you want to have multiple users who take turns at the same machine by 
using LOGIN, some of whom want to use windows, and some who don't).

Ideally, we would like to see Windows able to handle high environments, as it 
is quite a common method used in overlaying execs.  

However, we do have a "fix" (I hesitate to use that word since we weren't
doing anything wrong :-) which can be obtained from MKS technical
support.  

Further information can be obtained at the MKS support phone number given 
in your manual, or at uunet!watmath!mks!inquiry.

-dale