pcampb@brahma.trl.oz.au (Peter Campbell) (04/23/91)
raedgari@uokmax.ecn.uoknor.edu (Robert Allen Edgar II) writes: > I have a couple of problems with 4dos 3.03 and windows 3.0. > I have a 386SX with 4dos 3.03, dos 4.01, and windows 3.0. > My config.sys file contains the line : > SHELL=C:\4DOS.COM /P /E:512 > My autoexec.bat file contains the line : > SET COMSPEC=C:\4DOS.COM >1. While running a communications program which is minimized I get a > warning when I try to run a non-windows application at the same > time. > It says something to the effect that something is using the comm port, > which it is, and that I may loose characters if I run the application > now. It also gives me a choice, that is yes run it or no don't. Is > this a problem I should worry about? Can it be fixed? Should I > just live with it? >2. The other problem is that it seems I can't run a non-windows app. in > a window as I could before installing 4dos. Alt+Enter doesn't seem > to do anything when 4dos is initialized before windows. Is there > a parameter that needs to be set in my config.sys or autoexec.bat > files that is not already set. Well, Bob, I've been having very similar problems since I changed 3.02a into 3.03. The problems occur when I have one of two setups. The first setup started when I read a flyer sent out with my registered copy of 4DOS that said for standard and real mode windows shells you should use the "/v" flag when you call 4DOS, as it can cause problems when you don't. Although I nearly always use enhanced mode for Windows 3.0 I put it in just in case, and this worked OK. However, when I got the new version it had a similar story but said to put in a new environment variable 4DSHELL which should have the "/v", i.e. have "set 4DSHELL=/v" in your autoexec.bat. So I put in this as well, and, just to be on the safe side, put "set COMSPEC=4dos.com /v" in their as well At this point I got the problem you did in #2 - when I tried to start up a non-windows application it just wouldn't let me. I got rid of the comspec line - after all, 4dos effectively puts "COMSPEC=4dos.com" in your environment automatically anyway, and this time I got a different error - it would start up the shell/non-windows application OK, but then it would give the error: 4DOS server error -- swap in failed due to I/O error which I thought was a lot of help, as this error was NOT in the document file - although there were a few like it (none of which helped). I got this error whenever I made a shell - e.g. if I was in DOS, ran XTreeGold and executed a program (which means Xtree makes a new shell) the same thing would happen. The big trouble was this appeared to be intermittent - it wouldn't happen if I didn't have network connections, and sometimes it wouldn't even if it did, so I thought it was network troubles. After a few hours of toing and froing I finally worked out that it wasn't my network, but the fact that when I put the network stuff in it increased the size of my environment. Despite the fact that I had an environment set at 1024 bytes, the error consistently occurred whenever I took up over 512 bytes (i.e. less than half a K free) and tried opening a shell. I thought OK, this is it, and increased the size of my environment to 1536 bytes, just to be on the safe side, and this worked - I haven't have any problems since - I just need to make sure there is a free 512 bytes in the environment of my Primary 4DOS shell, and everything is OK. HOWEVER, a bit later I thought "what if it was the 4DSHELL" that was doing it? So, I took out this line, and lo & behold, this worked as well! I could cut my environment back to 1024 (or even 550) bytes, and then EVERYTHING would work properly. As soon as I put back the set 4DSHELL=/v in my autoexec.bat all the problems started again - whether I had SHELL=C:\4dos.com /v /E:1024U /P /U or SHELL=C:\4dos.com /E:1024U /P /U in my config.sys. So, my suggestion is to IGNORE THE COMMENT ABOUT PUTTING set 4DSHELL=/v in your autoexec.bat file, REMOVE THE set COMSPEC=4dos.com from here as well, and if you haven't done so already put the "/v" switch in the SHELL command in your config.sys file. If this doesn't work then try increasing the size of your environment by 512 bytes - e.g. 512 to 1024 in this case. Has anyone else had this problem? If so can you work out why it disappears when you EITHER remove the 4DSHELL line OR increase the environment size (or both)? Also, could someone outside of Australia (e.g. you, Bob) please do a follow-up article on this or else post me email saying that they have seen this article, as we have been having trouble with sending news articles, and I don't know if it is still happening. If I haven't had any replies/follow-ups within a week I'll try sending this article again. Peter K. Campbell p.campbell@trl.oz.au My opinions are my own, so don't sue.
traub@rtf.bt.co.uk (Michael Traub) (04/24/91)
In article <3419@trlluna.trl.oz> pcampb@brahma.trl.oz.au (Peter Campbell) writes: >raedgari@uokmax.ecn.uoknor.edu (Robert Allen Edgar II) writes: >> I have a couple of problems with 4dos 3.03 and windows 3.0. >> I have a 386SX with 4dos 3.03, dos 4.01, and windows 3.0. >> My config.sys file contains the line : >> SHELL=C:\4DOS.COM /P /E:512 >> My autoexec.bat file contains the line : >> SET COMSPEC=C:\4DOS.COM > >So, my suggestion is to IGNORE THE COMMENT ABOUT PUTTING > set 4DSHELL=/v >in your autoexec.bat file, REMOVE THE > set COMSPEC=4dos.com >from here as well, and if you haven't done so already put the "/v" >switch in the SHELL command in your config.sys file. > >If this doesn't work then try increasing the size of your environment by >512 bytes - e.g. 512 to 1024 in this case. > >Has anyone else had this problem? If so can you work out why it >disappears when you EITHER remove the 4DSHELL line OR increase the >environment size (or both)? > >Also, could someone outside of Australia (e.g. you, Bob) please do a >follow-up article on this or else post me email saying that they have >seen this article, as we have been having trouble with sending news >articles, and I don't know if it is still happening. If I haven't had >any replies/follow-ups within a week I'll try sending this article >again. > >Peter K. Campbell >p.campbell@trl.oz.au > >My opinions are my own, so don't sue. Well your article got to the UK at least! I suggest you try: set 4DSHELL=/v/e:1024 Michael Traub BT Customer Systems, Brighton Systems Centre. traub@rtf.bt.co.uk