Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!lotus!lotus.com!robertk From: robertk@lotatg.lotus.com (Robert Krajewski) Newsgroups: comp.windows.ms Subject: Re: give me solid facts.... Summary: Opening a file is not the same as starting a program Message-ID: Date: 5 Apr 91 15:30:59 GMT References: <1991Mar27.061300.7636@nntp-server.caltech.edu> <1991Apr2.002941.5578@leland.Stanford.EDU> <1991Apr2.033520.21271@cs.uoregon.edu> Sender: news@lotus.com Organization: /homes/robertk/.organization Lines: 69 In-Reply-To: akm@obelix.cs.uoregon.edu's message of 2 Apr 91 03:35:20 GMT In article <1991Apr2.033520.21271@cs.uoregon.edu> akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: The problem is: given that an application is running, and an "WinExec" call is executed, what should happen? (I am assuming that Progman, Winfile etc essentially do a WinExec when asked to run an application.) WinExec should just make a new instance of the application. Of course, it might fail because the application can't have more than one instance (because it's a large model application), or because the application itself enforces such a policy. Anyway, WinExec isn't the right place to fix this message. >Windows *can* do it the Mac way--why Microsoft didn't choose to add the >functionality is beyond me. I put it in an editor I'm working on and it >took about 10-20 lines of simple code. You basically get the handle of the >previous instance and send it a message with the file to be opened. This is a reasonable solution, which fixes it for just one program: yours. What I was talking about below was a more general mechanism for solving the problem. I don't agree with Robert here. WinFile is *just* another application. It is *not* part of the OS. >>Basically, it would involve extending the currently >>anemic file association mechanism. It's not the file system per se that sucks (although a better one like OS/2 HPFS or Mac HFS *would* make life easier). The reason why I mention extending the file association mechanism (which shows up as the [Extensions] section of your WIN.INI) is that I *don't* want WinFile to be special. Any other application has access to the same data. Anyway, associations between files and applications are globally useful. We would like to take something a little higher level than merely starting a program, and offer the some support for it in the OS. (Or at least we should know where to look for the right thing to do !) The Mac got that right seven years ago. For example, one reasonable extension that could be made is that the line: wri=write.exe ^.wri would not only mean: If you open .wri, use the command line write.exe .wri but also If there is already an instance of write.exe (which can be determined quite cleanly), send it an ``open new file'' message with the parameter .wri. If the message fails (the instance does not handle it), go back to the old way and try launching a new instance. Having a general mechanism is nice because it means that programs like Bridge, which exist for the purpose of hooking other applications together much like a shell, can treat applications and documents like objects, with operations like Open. That's really the one advantage of coming up with a general protocol for doing this, instead of the application implementing it itself. In the Mac world, this ``open file'' operation will be a standard AppleEvent, and MultiFinder will stop using the file-open-dialog-circumvention kludge. Note that the message could be its own proper message (defined by Microsoft), or it could be part of a new set of things built on top of DDE.