efowler@milton.u.washington.edu (Eric Fowler) (09/18/90)
I have been trying to bring up windows under MKS and getting the message "conventional memory is fragmented..[try it in real mode]". Outside of problems running in standard mode, all is well in win3Land. Trying real mode gets the opening screen and then the DOS prompt(no windows). =Eric HW:Epson Equity 386/20, 3 megs extended, no network, no printer, no modem. Video7 VGA. I have recently installed MKS. I know windows well, MKS not at all.
steveha@microsoft.UUCP (Steve Hastings) (09/20/90)
In article <7689@milton.u.washington.edu> efowler@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. >Outside of >problems running in standard mode, all is well in win3Land. You specified that you had a 386. I suggest you try running 386 Enhanced mode. Then you can have multiple MKS shells, running at the same time. You can even switch between them with hotkeys by making a series of .PIF files, all of which run the same program (the MKS shell) but each specifying a different hotkey. -- Steve "I don't speak for Microsoft" Hastings ===^=== ::::: uunet!microsoft!steveha steveha@microsoft.uucp ` \\==|
joeb@hpnmdla.HP.COM (Joe Barnhart) (09/22/90)
I know this isn't exactly what you asked for... But I have been very succesful at running MKS under Windows 3.0, instead of the other way around. Just put WIN in your AUTOEXEC.BAT file, then in Windows create an icon to launch MKS. You just specify SH.EXE as the program you want to run and provide the "-L" switch as a parameter. Works great. Joe B.
dale@mks.com (Dale Gass) (09/27/90)
steveha@microsoft.UUCP (Steve Hastings) writes: >X-Original-Newsgroups: comp.unix.msdos > efowler@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
jstuart@kentvax.kent.edu (Jeff Stuart) (09/27/90)
We got it working here. We have a login shell which calls command.com to run a batch file which calls windows among other things. Also we run windows in standard mode not real. This is running on (believe it or not but true) a REAL IBM AT. -- Jeff Stuart Internet: kentba!jstuart@mcs.kent.edu Kent State University UUCP : ...!uunet!telxon!teleng!kentba!jstuart Kent, Ohio 44449 (216) 672-3282 #include std.disclaimer