From: Werner L. <wl...@gn...> - 2012-02-02 18:24:07
|
Folks, with cmd.exe, if both `foo.com' and `foo.exe' are in the same directory, `foo.com' takes precedence and gets executed. However, this is not the case with the MSYS shell. Why? Werner |
From: Eli Z. <el...@gn...> - 2012-02-02 19:13:10
|
> Date: Thu, 02 Feb 2012 19:23:44 +0100 (CET) > From: Werner LEMBERG <wl...@gn...> > > with cmd.exe, if both `foo.com' and `foo.exe' are in the same > directory, `foo.com' takes precedence and gets executed. > > However, this is not the case with the MSYS shell. Why? Why in the world do you care about .com programs on today's Windows versions? |
From: Werner L. <wl...@gn...> - 2012-02-02 21:35:49
|
>> with cmd.exe, if both `foo.com' and `foo.exe' are in the same >> directory, `foo.com' takes precedence and gets executed. >> >> However, this is not the case with the MSYS shell. Why? > > Why in the world do you care about .com programs on today's Windows > versions? First of all, it's not clear to me why MSYS should deviate from the standard behaviour, obviously for no good reasons. Secondly, if you want to make a Windows GUI application write to a console if started from a console but do nothing if started as a GUI (similar to Unix applications), there is the nice trick of having two binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, and Windows executes `foo.com', a command-line program. This in turn spawns `foo.exe', a GUI program, and communicates with it using stdout and friends which are redirected to pipes. Werner |
From: <ct...@th...> - 2012-02-02 21:49:59
|
On Thursday, February 2, 2012 3:35pm, "Werner LEMBERG" <wl...@gn...> said: > Secondly, if you want to make a Windows GUI application write to a > console if started from a console but do nothing if started as a GUI > (similar to Unix applications), there is the nice trick of having two > binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, > and Windows executes `foo.com', a command-line program. This in turn > spawns `foo.exe', a GUI program, and communicates with it using stdout > and friends which are redirected to pipes. I can't resist my curiosity on this one. Is the .com program a 16-bit, single segment tiny mode binary? Or is this win32 console application renamed to .com? Would this .com program take into consideration times when there is no gui? ssh sessions for instance? My "solution" to this "problem" in the past has been to detect if the process has a console with winapi, and if not allocate one. This behavior can then be disabled with command line switch (which can be part of the start up icon). I also just checked for ssh with environment variable. www.thomasstover.com |
From: Jim M. <jmi...@ya...> - 2012-02-02 22:32:23
|
http://en.wikipedia.org/wiki/COM_file >________________________________ > From: "ct...@th..." <ct...@th...> >To: MinGW Users List <min...@li...> >Sent: Thursday, February 2, 2012 1:49 PM >Subject: Re: [Mingw-users] Precendence of COM and EXE > >On Thursday, February 2, 2012 3:35pm, "Werner LEMBERG" <wl...@gn...> said: > >> Secondly, if you want to make a Windows GUI application write to a >> console if started from a console but do nothing if started as a GUI >> (similar to Unix applications), there is the nice trick of having two >> binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, >> and Windows executes `foo.com', a command-line program. This in turn >> spawns `foo.exe', a GUI program, and communicates with it using stdout >> and friends which are redirected to pipes. > >I can't resist my curiosity on this one. > >Is the .com program a 16-bit, single segment tiny mode binary? Or is this win32 console application renamed to .com? > >Would this .com program take into consideration times when there is no gui? ssh sessions for instance? > >My "solution" to this "problem" in the past has been to detect if the process has a console with winapi, and if not allocate one. This behavior can then be disabled with command line switch (which can be part of the start up icon). I also just checked for ssh with environment variable. > > >www.thomasstover.com > > >------------------------------------------------------------------------------ >Keep Your Developer Skills Current with LearnDevNow! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-d2d >_______________________________________________ >MinGW-users mailing list >Min...@li... > >This list observes the Etiquette found at >http://www.mingw.org/Mailing_Lists. >We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > >_______________________________________________ >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users >Also: mailto:min...@li...?subject=unsubscribe > > > |
From: <min...@sp...> - 2012-02-02 23:15:38
|
Werner LEMBERG wrote: >>> with cmd.exe, if both `foo.com' and `foo.exe' are in the same >>> directory, `foo.com' takes precedence and gets executed. >>> >>> However, this is not the case with the MSYS shell. Why? >> >> Why in the world do you care about .com programs on today's Windows >> versions? > > First of all, it's not clear to me why MSYS should deviate from the > standard behaviour, obviously for no good reasons. > > Secondly, if you want to make a Windows GUI application write to a > console if started from a console but do nothing if started as a GUI > (similar to Unix applications), there is the nice trick of having two > binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, > and Windows executes `foo.com', a command-line program. This in turn > spawns `foo.exe', a GUI program, and communicates with it using stdout > and friends which are redirected to pipes. The precedence in cmd.exe is not quite as simple as .com then .exe - it's determined by the PATHEXT environment variable. If that's changed for any reason, your "nice trick" could break. Why not have foo.exe for the console, and foo-win.exe for the GUI? Typing "foo" from the console runs foo.exe, while GUI users are more likely to use a shortcut (which you create for them, pointing to foo-win.exe) or see both .exes in the application's folder and guess which is the right one (which they'd have to do anyway given the choice of foo.exe or foo.com). |
From: Werner L. <wl...@gn...> - 2012-02-03 05:20:32
|
>> Secondly, if you want to make a Windows GUI application write to a >> console if started from a console but do nothing if started as a >> GUI (similar to Unix applications), there is the nice trick of >> having two binaries, `foo.com' and `foo.exe'. You say `foo' on the >> command line, and Windows executes `foo.com', a command-line >> program. This in turn spawns `foo.exe', a GUI program, and >> communicates with it using stdout and friends which are redirected >> to pipes. > > I can't resist my curiosity on this one. > > Is the .com program a 16-bit, single segment tiny mode binary? Or > is this win32 console application renamed to .com? [...] AFAIK, it's a real 16-bit tiny binary. See this: http://code.google.com/p/dualsubsystem/ Werner |
From: Jim M. <jmi...@ya...> - 2012-02-03 05:46:13
|
technically, you can have i386 instructions in it or i686 instructions in it or whatever. but according to the wikipedia article, you are limited to a single *segment*. if you define *that* as 16-bit, then OK. basically you are working in real mode. .com's don't have to be 16-bit. you can write it for whatever proc you want - but you are limited as to the size of the file unfortunately. If you really wanted to extend it, I don't know if you can ring-0 it and piggyback data on the end of the file or not. that would of course be entirely defeating the purpose of a .com file (and why would anyone want do do something like this? you still need either DOS or a 32-bit version of windows or XP Mode to run it). you would still run into the problem of whether or not the program loader would be able to load your program if you are doing this at all anyway since specs are probably being violated, so it's a bad idea in the first place. the .com involves a PSP, Program Segment Prefix. I vaguely remember something about this being a JMP instruction to 0x100 where your code is expected to start, but I may be muddling this. .com is maybe good for TSR's, loading module-based programs, and utilities that basically don't do a whole lot. also, I hear of late that disreputable people are using .com's to spread malware in email because they resemble domain names, so beware of attachments that look like a URL or domain name. blah. >________________________________ > From: Werner LEMBERG <wl...@gn...> >To: min...@li...; ct...@th... >Sent: Thursday, February 2, 2012 9:20 PM >Subject: Re: [Mingw-users] Precendence of COM and EXE > > >>> Secondly, if you want to make a Windows GUI application write to a >>> console if started from a console but do nothing if started as a >>> GUI (similar to Unix applications), there is the nice trick of >>> having two binaries, `foo.com' and `foo.exe'. You say `foo' on the >>> command line, and Windows executes `foo.com', a command-line >>> program. This in turn spawns `foo.exe', a GUI program, and >>> communicates with it using stdout and friends which are redirected >>> to pipes. >> >> I can't resist my curiosity on this one. >> >> Is the .com program a 16-bit, single segment tiny mode binary? Or >> is this win32 console application renamed to .com? [...] > >AFAIK, it's a real 16-bit tiny binary. See this: > > http://code.google.com/p/dualsubsystem/ > > > Werner > >------------------------------------------------------------------------------ >Try before you buy = See our experts in action! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-dev2 >_______________________________________________ >MinGW-users mailing list >Min...@li... > >This list observes the Etiquette found at >http://www.mingw.org/Mailing_Lists. >We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > >_______________________________________________ >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users >Also: mailto:min...@li...?subject=unsubscribe > > > |
From: Werner L. <wl...@gn...> - 2012-02-03 05:28:32
|
> Why not have foo.exe for the console, and foo-win.exe for the GUI? > Typing "foo" from the console runs foo.exe, while GUI users are more > likely to use a shortcut (which you create for them, pointing to > foo-win.exe) or see both .exes in the application's folder and guess > which is the right one (which they'd have to do anyway given the > choice of foo.exe or foo.com). Yes, I will do that now. I thought there MUST be a way to be emulate the convenient Unix way of having a single binary for both GUI and TTY output (my program has a --tty command line switch), but I now see that this isn't possible. Werner |
From: Jim M. <jmi...@ya...> - 2012-02-03 05:54:31
|
for the -tty switch: windows has console-mode programs and windows PE's. the windows PE's (GUIs) have WinMain() and the console mode executables have main(). you would need to write your own commandline argument parser for a windows PE, because it just gives you a plain old string instead of char**argv. I gave up trying to write mine for simpler projects for now. there are Console series Win32 API functions available at your disposal. also available are the standard C and C++ libraries. see http://msdn.microsoft.com to search for any functions that are Console related. >________________________________ > From: Werner LEMBERG <wl...@gn...> >To: min...@li...; min...@sp... >Sent: Thursday, February 2, 2012 9:28 PM >Subject: Re: [Mingw-users] Precendence of COM and EXE > > >> Why not have foo.exe for the console, and foo-win.exe for the GUI? >> Typing "foo" from the console runs foo.exe, while GUI users are more >> likely to use a shortcut (which you create for them, pointing to >> foo-win.exe) or see both .exes in the application's folder and guess >> which is the right one (which they'd have to do anyway given the >> choice of foo.exe or foo.com). > >Yes, I will do that now. I thought there MUST be a way to be emulate >the convenient Unix way of having a single binary for both GUI and TTY >output (my program has a --tty command line switch), but I now see >that this isn't possible. > > > Werner > >------------------------------------------------------------------------------ >Try before you buy = See our experts in action! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-dev2 >_______________________________________________ >MinGW-users mailing list >Min...@li... > >This list observes the Etiquette found at >http://www.mingw.org/Mailing_Lists. >We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > >_______________________________________________ >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users >Also: mailto:min...@li...?subject=unsubscribe > > > |
From: Werner L. <wl...@gn...> - 2012-02-03 06:39:33
|
> for the -tty switch: > > windows has console-mode programs and windows > PE's. the windows PE's (GUIs) have WinMain() and the console mode > executables have main(). > > you would need to write your own commandline argument parser for a > windows PE, because it just gives you a plain old string instead of > char**argv. I gave up trying to write mine for simpler projects for > now. Handling the command line is no problem, but echoing to the console *without* opening a new one... I have to accept that the Unix way simply doesn't work with Windows. Its crippled stdin/stdout/stderr handling is a PITA, but that's life. I have learned my lesson. Werner |
From: Eli Z. <el...@gn...> - 2012-02-03 08:13:27
|
> Date: Fri, 03 Feb 2012 07:39:16 +0100 (CET) > From: Werner LEMBERG <wl...@gn...> > > Handling the command line is no problem, but echoing to the console > *without* opening a new one... You can do it the other way around: link your program as a console program which can behave as a GUI one (i.e. open its own windows) when necessary. > I have to accept that the Unix way simply doesn't work with Windows. > Its crippled stdin/stdout/stderr handling is a PITA, but that's life. What exactly is "crippled" about that? It's different from what you are used to on Posix platforms, but being different doesn't necessarily mean to be crippled. Maybe you lack some additional information to get over that? What exactly are your problems with the standard handles? A GUI program shouldn't care about them, for starters. |
From: Werner L. <wl...@gn...> - 2012-02-03 08:42:04
|
>> I have to accept that the Unix way simply doesn't work with >> Windows. Its crippled stdin/stdout/stderr handling is a PITA, but >> that's life. > > What exactly is "crippled" about that? It's different from what you > are used to on Posix platforms, but being different doesn't > necessarily mean to be crippled. Well, `crippled' was the wrong word. You are right, it's `different'. Werner |
From: Eli Z. <el...@gn...> - 2012-02-03 09:37:58
|
> Date: Fri, 03 Feb 2012 09:41:41 +0100 (CET) > From: Werner LEMBERG <wl...@gn...> > > > >> I have to accept that the Unix way simply doesn't work with > >> Windows. Its crippled stdin/stdout/stderr handling is a PITA, but > >> that's life. > > > > What exactly is "crippled" about that? It's different from what you > > are used to on Posix platforms, but being different doesn't > > necessarily mean to be crippled. > > Well, `crippled' was the wrong word. You are right, it's `different'. Anyway, if you need some help figuring out its dark barely documented corners, don't hesitate to ask. It looked weird at first to me as well, but I eventually found I can do with the Windows standard handles everything can I do on Posix platforms. You just need to be aware of the "differences". E.g., a Windows program can have no valid standard handles to begin with. |
From: Thomas S. <ct...@th...> - 2012-02-03 14:57:02
|
On Fri, 03 Feb 2012 06:28:16 +0100 (CET) Werner LEMBERG <wl...@gn...> wrote: > Yes, I will do that now. I thought there MUST be a way to be emulate > the convenient Unix way of having a single binary for both GUI and TTY > output (my program has a --tty command line switch), but I now see > that this isn't possible. You can do more than you might think. Take a look at the notes for things like AllocConsole(), AttachConsole(), FreeConsole(), etc. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682073%28v=vs.85%29.aspx As some windows only programmers may not be aware, some of the cross platform GUI libraries let you start with a real main() in all cases, alleviating the extra headache of winmain() in both portability and in schemes such as the above. Also, on newer windows versions there is a similar paradigm and api for desktops. However there is always a desktop - services and ssh spawned processes for instance just have desktops off in memory. ...and for completeness, there still is cygwin |
From: Eli Z. <el...@gn...> - 2012-02-04 16:38:18
|
> Date: Sat, 04 Feb 2012 16:22:01 +0000 > From: Keith Marshall <kei...@us...> > CC: Werner LEMBERG <wl...@gn...>, el...@gn... > > On 03/02/12 08:07, Eli Zaretskii wrote: > > See how Emacs does it, and you will realize that things aren't really > > that hard or complicated. > > Emacs may not be the best example here; not because there's anything > intrinsically wrong with it, but simply because the sheer size of the > code base may seem intimidating. The code I had in mind is rather small, see below. It can be easily understood by someone who knows nothing about Emacs on Windows. > Closer to home, mingw-get.exe is little more than a stub. It includes > the code to parse the command line, (using a getopt_long_only() call > which (mostly) mimics the GNU prescribed behaviour of the function of > that name), and it handles the --help and --version options directly. > Beyond this, if it is invoked without arguments, it simply exec()s [*] > mingw-get's GUI mode application, (a separate gui.exe which currently > does nothing particularly useful). runemacs.exe, which was what I had in mind, does something very similar. |
From: Werner L. <wl...@gn...> - 2012-02-04 16:48:52
|
> runemacs.exe, which was what I had in mind, does something very > similar. I've seen this code, thanks. I've even understood it :-) Fortunately, I can freely decsign the interface of my not-really-published-yet program, and I've now decided to *not* implement a `--tty' command line option (which corresponds to emacs's `-nw'). Werner |
From: Keith M. <kei...@us...> - 2012-02-04 17:16:28
|
On 04/02/12 16:38, Eli Zaretskii wrote: >> Date: Sat, 04 Feb 2012 16:22:01 +0000 >> From: Keith Marshall <keithmarshall@...> >> CC: Werner LEMBERG <wl@...>, eliz@... >> >> On 03/02/12 08:07, Eli Zaretskii wrote: >>> See how Emacs does it, and you will realize that things aren't really >>> that hard or complicated. >> >> Emacs may not be the best example here; not because there's anything >> intrinsically wrong with it, but simply because the sheer size of the >> code base may seem intimidating. > > The code I had in mind is rather small, see below. It can be easily > understood by someone who knows nothing about Emacs on Windows. This helps, thanks. >> ...description of mingw-get.exe behaviour snipped... > > runemacs.exe, which was what I had in mind, does something very > similar. Werner apparently wasn't intimidated. Others may be. Knowing that they should look for the source for runemacs.exe may help to lower the potential intimidation barrier. For completeness: in the corresponding mingw-get.exe case, the source may be found in src/clistub.c -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2012-02-02 22:12:44
|
On 02/02/12 21:35, Werner LEMBERG wrote: >>> with cmd.exe, if both `foo.com' and `foo.exe' are in the same >>> directory, `foo.com' takes precedence and gets executed. >>> >>> However, this is not the case with the MSYS shell. Why? >> >> Why in the world do you care about .com programs on today's Windows >> versions? > > First of all, it's not clear to me why MSYS should deviate from the > standard behaviour, obviously for no good reasons. When the "standard" says that .com is a 16-bit, real mode, single segment (64 kB max) binary, with no relocatable sections permitted? When a binary conforming to this standard MUST run under NTVDM? MSYS, (and MinGW), don't profess to support this legacy MS-DOS subsystem. I think that's a pretty good reason. > Secondly, if you want to make a Windows GUI application write to a > console if started from a console but do nothing if started as a GUI > (similar to Unix applications), there is the nice trick of having two > binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, > and Windows executes `foo.com', a command-line program. This in turn > spawns `foo.exe', a GUI program, and communicates with it using stdout > and friends which are redirected to pipes. But in this scenario you are abusing a (mis)feature of the MS-DOS legacy support subsystem, to achieve something it was never designed to support. Surely, would you not be better to adopt a structure similar to the framework which mingw-get already has in place to support its future GUI capability? -- Regards, Keith. |
From: Jim M. <jmi...@ya...> - 2012-02-02 22:36:15
|
by the way, .com's won't run under 64-bit OS's because command.com is missing on 64-bit windows OS's. >________________________________ > From: Keith Marshall <kei...@us...> >To: MinGW Users List <min...@li...> >Sent: Thursday, February 2, 2012 2:12 PM >Subject: Re: [Mingw-users] Precendence of COM and EXE > >On 02/02/12 21:35, Werner LEMBERG wrote: >>>> with cmd.exe, if both `foo.com' and `foo.exe' are in the same >>>> directory, `foo.com' takes precedence and gets executed. >>>> >>>> However, this is not the case with the MSYS shell. Why? >>> >>> Why in the world do you care about .com programs on today's Windows >>> versions? >> >> First of all, it's not clear to me why MSYS should deviate from the >> standard behaviour, obviously for no good reasons. > >When the "standard" says that .com is a 16-bit, real mode, single >segment (64 kB max) binary, with no relocatable sections permitted? >When a binary conforming to this standard MUST run under NTVDM? MSYS, >(and MinGW), don't profess to support this legacy MS-DOS subsystem. I >think that's a pretty good reason. > >> Secondly, if you want to make a Windows GUI application write to a >> console if started from a console but do nothing if started as a GUI >> (similar to Unix applications), there is the nice trick of having two >> binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, >> and Windows executes `foo.com', a command-line program. This in turn >> spawns `foo.exe', a GUI program, and communicates with it using stdout >> and friends which are redirected to pipes. > >But in this scenario you are abusing a (mis)feature of the MS-DOS legacy >support subsystem, to achieve something it was never designed to >support. Surely, would you not be better to adopt a structure similar >to the framework which mingw-get already has in place to support its >future GUI capability? > >-- >Regards, >Keith. > >------------------------------------------------------------------------------ >Keep Your Developer Skills Current with LearnDevNow! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-d2d >_______________________________________________ >MinGW-users mailing list >Min...@li... > >This list observes the Etiquette found at >http://www.mingw.org/Mailing_Lists. >We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > >_______________________________________________ >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users >Also: mailto:min...@li...?subject=unsubscribe > > > |
From: Eli Z. <el...@gn...> - 2012-02-03 07:47:35
|
> Date: Thu, 02 Feb 2012 22:35:28 +0100 (CET) > From: Werner LEMBERG <wl...@gn...> > > Secondly, if you want to make a Windows GUI application write to a > console if started from a console but do nothing if started as a GUI > (similar to Unix applications), there is the nice trick of having two > binaries, `foo.com' and `foo.exe'. You say `foo' on the command line, > and Windows executes `foo.com', a command-line program. This in turn > spawns `foo.exe', a GUI program, and communicates with it using stdout > and friends which are redirected to pipes. You can do the same with a .bat or .cmd file and a .exe file. The batch file would invoke an auxiliary program, say fooc.exe, to do what your foo.com was supposed to do, with foo.exe being a GUI program. Emacs on Windows does something like that, although it doesn't have the batch file to glue both programs into a single command. |
From: Eli Z. <el...@gn...> - 2012-02-03 07:58:12
|
> Date: Thu, 2 Feb 2012 14:36:08 -0800 (PST) > From: Jim Michaels <jmi...@ya...> > > by the way, .com's won't run under 64-bit OS's because command.com is missing on 64-bit windows OS's. Are these two really related? AFAIK, .com files are run by NTVDM, the DOS emulator that is part of Windows (is there such a beast on 64-bit Windows, btw?). They are not run by command.com. So the mere fact that command.com is absent says nothing at all about the ability to run .com programs. |
From: Eli Z. <el...@gn...> - 2012-02-03 08:09:55
|
> Date: Thu, 2 Feb 2012 21:54:24 -0800 (PST) > From: Jim Michaels <jmi...@ya...> > > for the -tty switch: > windows has console-mode programs and windows PE's. the windows PE's (GUIs) have WinMain() and the console mode executables have main(). > > you would need to write your own commandline argument parser for a windows PE, because it just gives you a plain old string instead of char**argv. I gave up trying to write mine for simpler projects for now. This is all very inaccurate. See how Emacs does it, and you will realize that things aren't really that hard or complicated. |
From: Keith M. <kei...@us...> - 2012-02-04 16:22:13
|
On 03/02/12 08:07, Eli Zaretskii wrote: > See how Emacs does it, and you will realize that things aren't really > that hard or complicated. Emacs may not be the best example here; not because there's anything intrinsically wrong with it, but simply because the sheer size of the code base may seem intimidating. I know Werner will be intimately familiar with the groff code base; its pre-grohtml incorporates windows specific code, which illustrates the method of hooking up stdio pipelines, and using the spawn() family of functions in place of POSIX's fork() ... exec() idiom. Closer to home, mingw-get.exe is little more than a stub. It includes the code to parse the command line, (using a getopt_long_only() call which (mostly) mimics the GNU prescribed behaviour of the function of that name), and it handles the --help and --version options directly. Beyond this, if it is invoked without arguments, it simply exec()s [*] mingw-get's GUI mode application, (a separate gui.exe which currently does nothing particularly useful). When invoked *with* arguments, then it loads mingw-get-0.dll, (using LoadLibrary(), (the windows functional equivalent of POSIX's dlopen() function)), and delegates all further processing to a handler function within the DLL; when this finally returns, mingw-get.exe then exec()s lastrites.exe to clean up any defunct files which couldn't be deleted until mingw-get.exe itself released them; (windows doesn't allow deletion of files while they remain open in any process). [*] For POSIX aficionados: while appearing syntactically identical to its POSIX counterpart, exec() on windows behaves semantically rather differently. It's behaviour is similar to this POSIX snippet: if( (child = fork()) == 0 ) exec( ARGUMENTS_FOR_CHILD ); if( child > 0 ) exit( NO_EXPLICITLY_DEFINED_VALUE ); -- Regards, Keith. |
From: Werner L. <wl...@gn...> - 2012-02-04 16:46:15
|
> Closer to home, mingw-get.exe is little more than a stub. [...] Thanks for the explanation. I've eventually decided to use the approach which has been suggested to me from the very beginning: One binary for the console and another one for the GUI. Werner |