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
rfutscher@pbs.org (02/28/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. <much deleated> I had a simular problem with my floppies. Some times windows would tell me I had the wrong disk in the drive. I had to reboot to clear the problem. When I replaced my AWARD BIOS with a newer version the problem went away. Robert Futscher rfutscher@pbs.org
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)