bturner@hpcvlx.HP.COM (Bill Turner) (11/22/88)
No, this isn't in the manuals, but knowing a bit about how Windows works helps. The device drivers for MSW have module names DISPLAY, MOUSE, and KEYBOARD. When a program is run, the module name is kept in memory. If you try to run a program with the same name as a module that has already been loaded, then Windows assumes that the program has already been loaded and just re-executes the in-memory version. This is also why you want to make sure the NAME/LIBRARY line in the .DEF file matches the program name. If it doesn't, Windows gets confused as to whether the program is already loaded or not. --Bill Turner
posert@bonnie.ics.uci.edu (Bob Posert) (11/22/88)
In article <453@gold.GVG.TEK.COM> John Schultheiss writes: >In article <1281@helios.ee.lbl.gov> mikec@ux1.lbl.gov (Mike Chin) writes: >@Try renaming a window app to "DISPLAY.EXE", and then >@ [...] > >Rule # 2. When in doubt, check the .DEF file. In general, applications will >exhibit strange behavior whenever the NAME in the .DEF file does not match >the name of the application's .EXE file. >[...] If what you meant was that you changed >the names of all the source files, changed the makefile's contents, and the >.DEF file's contents to reflect these other changes, then there must be some- >thing unique about the name DISPLAY.EXE name, which is certainly a possibility. This piqued my interest, so I ran strings on win200.bin. Part of the list was: SYSTEM.DRV KEYBOARD.DRV MOUSE.DRV DISPLAY.DRV SOUND.DRV COMM.DRV FONTS.FON OEMFONTS.FON GDI.EXE USER.EXE MSDOSD.EXE MSDOS.EXE KERNEL Renaming an executable to any of these followed by .exe (e.g. oemfonts.exe) yields a file that windows will not run. I used calc.exe for my tests. Even a slight variation yields a file that will run; windows will run both msdosc.exe and msdose.exe, but not msdosd.exe. When I renamed calc.exe to msdos.exe and double clicked on it, I got a regular ms-dos window. This seems reasonable, but unexpected. --Bob -- Bob Posert I'm: posert@bonnie.ics.uci.edu or {sdcsvax|ucbvax}!ucivax!bonnie!posert Here's good luck to the pint pot, good luck to the Barley Mow. Jolly good luck to the pint pot, good luck to the Barley Mow.
blair@enint.Wichita.NCR.COM (Brian Lair) (11/29/88)
In article <959@paris.ics.uci.edu>, posert@bonnie.ics.uci.edu (Bob Posert) writes: > Even a slight variation yields a file that will run; > windows will run both msdosc.exe and msdose.exe, but not msdosd.exe. Fortunately, this oddity is explained in Petzold, p. 806: "Some dynamic libraries are designed for use only by a specific program. For instance, the MSDOS.EXE file is a Windows program* that uses a dynamic library called MSDOSD.EXE, which contains machine-dependent functions to format disks. Windows can be adapted for different MS-DOS machines by changing only the MSDOSD.EXE library module rather than the larger MSDOS.EXE program module." (Reprinted without permission. Void where prohibited.) * Someone pointed out in a previous posting, however, that MSDOS.EXE is more than likely NOT a Windows program, but merely a placeholder to direct the MS-DOS Executive Window to run another instance of itself. -- Brian R. Lair NCR Corporation, E&M Wichita, Advanced Development Brian.Lair@Wichita.NCR.COM <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!brian.lair> <{ucsd,pyramid,nosc.ARPA}!ncr-sd!ncrwic!brian.lair>
jonnyg@umd5.umd.edu (Jon Greenblatt) (11/29/88)
In article <366@enint.Wichita.NCR.COM> blair@enint.Wichita.NCR.COM (Brian Lair) writes: %In article <959@paris.ics.uci.edu>, posert@bonnie.ics.uci.edu (Bob Posert) writes: %> Even a slight variation yields a file that will run; %> windows will run both msdosc.exe and msdose.exe, but not msdosd.exe. % %Fortunately, this oddity is explained in Petzold, p. 806: % %"Some dynamic libraries are designed for use only by a specific program. %For instance, the MSDOS.EXE file is a Windows program* that uses a dynamic ....... %(Reprinted without permission. Void where prohibited.) % %* Someone pointed out in a previous posting, however, that MSDOS.EXE is %more than likely NOT a Windows program, but merely a placeholder to direct %the MS-DOS Executive Window to run another instance of itself. I'm the *someone and I would like to disagree with Petzold. MSDOS.EXE is 1 byte on my system. It would seem to me that a one byte windows program is imposible. MSDOS.EXE is 46224 bytes in the distribution, that says to me that MSDOS.EXE is loaded into the windows executable at setup time. When windows starts up, the MSDOS.EXE code is already there. It is my assumption that the screen driver is loaded under the name DISPLAY. Since these instances are already loaded, trying to execute them again will only create a new instance, the actual .EXE will be ingnored. This to me is a major flaw in windows, there should realy be a magic number associated with the .EXE which is read and compared when a new disk volume or directory is used. If Windows becomes popular, how could two independent companies help but come up with programs with Identical names. I program with Actor so my understanding of MS Windows is neccesarily a little weak but Petzold seems wrong to me. I say neccesarily weak because I try to keep a much simpler looking environment in Actor than in C using the standard windows calls. Through encapsulation, I usualy make things 10 times more powerful, 10 times more flexable, and use a 20th of the code and debugging time. Have I converted anyone? BTW most of my code is highly interactive and involves complex graphic operations based on user input. Simular encapsulation could be done in C but its Ooooh so much easier in Actor. Please excuse my spelling and syntax, it's way past my bed time!! JonnyG. (jonnyg@umd5.umd.edu) (jonnyg@rover.umd.edu)