mm@idca.tds.PHILIPS.nl (M. Molenaar) (02/27/91)
I am working on an installation tool running under Windows 3.0. The tool will be delivered on a floppy and must be run by "win a:\run\install" (without quotes of course), or within Windows via the program- or filemanager. After loading the program a problem is raised: if the tool asks to insert the first diskette in drive A: and the right floppy is inserted, Windows generates a system error message "Cannot read from drive A:". This occures at the SDK-function 'OpenFile()' to open a file on drive A: and for all floppy's other than the original one were the tool is started from. Conclusion: the (operating) system does not detect a change of a floppy. I have made all segments (code+data) and all resources (dialogboxes, stringtable, icons, etc) PRELOAD and FIXED. Windows 3.0 is running on a 386-machine in enhanced mode under MS-DOS 4.01. The problem does not arise on all 386-machines and never if the tool is started up from the harddisk. All floppydrives have 'change line support'. We suspect it is a timing problem were possibly the hardware interrupt 0Eh has no effect. Is there anyone who can confirm or refute this suspicion? Does anyone know, or has anyone a hint how to solve this problem? Thanks in advance, Marco
wolf@netcom.COM (Buckskin Tech.) (02/28/91)
In article <1386@ssp18.idca.tds.philips.nl>, mm@idca.tds.PHILIPS.nl (M. Molenaar) writes: > > Conclusion: the (operating) system does not detect a change of > a floppy. > > The problem does not arise on all 386-machines and never if the > tool is started up from the harddisk. > All floppydrives have 'change line support'. We suspect it is a > timing problem were possibly the hardware interrupt 0Eh has no > effect. Is there anyone who can confirm or refute this suspicion? Well, I can tell you that some early sub-versions of Windows had a BUNCH of problems with floppies, and they all seemed to be timing-related. You might try finding a brand-new Windows to try out. Also, are you REALLY sure that the change-line is supported? You can remount the floppy and FORCE change-line support with a DEVICE=DRIVER {blah blah} command (the exact format of which escapes me at the moment...help me out, folks). I once saw a 386 clone that would NOT recognize changed disks until this was done. If none of this helps, you might be able to force a floppy read of the FAT. I'm reaching here, but doesn't an attempted write force a FAT read? - Phil @ Buckskin Technologies
mm@idca.tds.PHILIPS.nl (M. Molenaar) (02/28/91)
Yesterday (27 febr 91) I wrote an article about an installation problem were I had problems with changing diskettes within Windows 3.0. Windows generated a system message "Cannot read from drive A:". Well, I have found that the problem arises if the environment variable COMSPEC specifies that the COMMAND.COM is present in a SUBdirectory of the root, e.g. SET COMSPEC=c:\dos\command.com. So COMMAND.COM MUST be specified in the root. If not, the dos- prompt within Windows cannot start too and reports "Cannot find command.com". Can anyone tell me if this is really a solution or only a bypass? If a DOS application runs under Windows, apparently the environment settings are (re)set to default. So COMSPEC will be set to C:\COMMAND.COM. How can I tell to Windows to use the environment variables specified in config.sys and autoexec.bat ? Kind regards, Marco
press@venice.SEDD.TRW.COM (Barry Press) (03/02/91)
In article <1388@ssp18.idca.tds.philips.nl> mm@idca.tds.PHILIPS.nl (M. Molenaar) writes: >Well, I have found that the problem arises if the environment >variable COMSPEC specifies that the COMMAND.COM is present in >a SUBdirectory of the root, e.g. SET COMSPEC=c:\dos\command.com. >So COMMAND.COM MUST be specified in the root. If not, the dos- No cigar. I've setup a lot of machines running Windows, and each and every one of them has DOS in a subdirectory, a SHELL command in the config.sys, and comspec pointing to command com in the subdir. None of them have command.com in the root. All run Windows and DOS sessions just fine. I don't know if the config.sys setup matters, but I use this sort of thing: shell=c:\dos\command.com c:\dos /p /e:xxx The c:\dos parameter has to do with telling it where to reload from. I usually force comspec in the autoexec as well. -- Barry Press Internet: press@venice.sedd.trw.com
altman@sbstaff2.cs.sunysb.edu (Jeff Altman) (03/03/91)
In article <1388@ssp18.idca.tds.philips.nl> mm@idca.tds.PHILIPS.nl (M. Molenaar) writes: > >Well, I have found that the problem arises if the environment >variable COMSPEC specifies that the COMMAND.COM is present in >a SUBdirectory of the root, e.g. SET COMSPEC=c:\dos\command.com. >So COMMAND.COM MUST be specified in the root. If not, the dos- >prompt within Windows cannot start too and reports "Cannot find >command.com". MArco: The problem you are having is that the so called "DOS Prompt in Windows" is really just an Icon in the Program Manager. If you use the properties command in the ProgMan you will find that the File NAme is specified as C:\COMMAND.COM. Therfore, if Command.com is not in the specified location it will report that it cannot find Command.com. This has absolutely nothing to do with the specification of the COMSPEC variable. To fix it just change the file name to include the proper path to your Command.com. -- - Jeff (jaltman@ccmail.sunysb.edu)