I propose to associate .bat and .com files with wine's cmd in GNOME, KDE and others
On Thu, Aug 11, 2011 at 5:21 PM, Nowres Rafid <nowres.rafed(a)gmail.com> wrote:
I propose to associate .bat and .com files with wine's cmd in GNOME, KDE and others
AFAIK COM files are ancient self-contained real-mode DOS code, with no ability to load DLLs. Shouldn't they rather be loaded by DOSBox, which we delegate DOS applications to on the AMD64 architecture anyway? BAT files should associate with Wine, but on Windows double-clicking them runs them in a terminal window (when last I checked). Thus we'd have to create a new wine-cmd.desktop which associates with BAT files. I'll look into it. While I am at it, EXE files are not clearly Wine's either - they could be real-mode DOS executables, or .NET code intended for Mono on *nix. At some point, Wine/Mono/DOSBox and related projects need to have a talk about some kind of arbitration mechanism. Damjan Jovanovic
I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me. There's a non-zero chance that wine start /unix will actually start cmd and make a terminal for BAT files. It makes one for console executables. If it doesn't, there's a possibility that start.exe will do that on Windows, in which case that is a Wine bug that we should fix. You should test that before making a new thing. There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types.
On Thu, Aug 11, 2011 at 6:18 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote:
I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me.
There's a non-zero chance that wine start /unix will actually start cmd and make a terminal for BAT files. It makes one for console executables. If it doesn't, there's a possibility that start.exe will do that on Windows, in which case that is a Wine bug that we should fix. You should test that before making a new thing.
There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types.
On Windows, double-clicking a BAT file causes it to open in a terminal window which automatically closes after the file is finished running, whereas using "start" cause the terminal window to stay open even after the file is finished running. On Wine using "start" wrongly closes the Window automatically, but since that's what we want for a double-clicked BAT file, "wineconsole" has the same behaviour and can be used instead. Unfortunately wineconsole doesn't like *nix paths, so it can't be used from a .desktop file directly...
On 08/11/2011 09:18 AM, Vincent Povirk wrote:
I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me.
There's a non-zero chance that wine start /unix will actually start cmd and make a terminal for BAT files. It makes one for console executables. If it doesn't, there's a possibility that start.exe will do that on Windows, in which case that is a Wine bug that we should fix. You should test that before making a new thing.
There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types.
To extend this, the relevant project is Freedesktop.org's shared-mime-info and if it can't yet tell them apart that's simply a bug. Is there a super-easy way for shared-mime-info to tell these guys apart? Thanks, Scott Ritchie
On Mon, Aug 15, 2011 at 1:02 AM, Scott Ritchie <scott(a)open-vote.org> wrote:
On 08/11/2011 09:18 AM, Vincent Povirk wrote:
I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me.
There's a non-zero chance that wine start /unix will actually start cmd and make a terminal for BAT files. It makes one for console executables. If it doesn't, there's a possibility that start.exe will do that on Windows, in which case that is a Wine bug that we should fix. You should test that before making a new thing.
There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types.
To extend this, the relevant project is Freedesktop.org's shared-mime-info and if it can't yet tell them apart that's simply a bug.
Is there a super-easy way for shared-mime-info to tell these guys apart?
Thanks, Scott Ritchie
Parsing the EXE headers requires pointer traversal (for example you need to go to the offset specified in IMAGE_DOS_HEADER's e_lfanew dword at offset 0x40 in the file to get to the extended header which starts with "NE" in the case of a Win16 executable). While "file" can do this and "man 5 magic" even has examples on how it is done for an EXE file, the simple parsing done by shared-mime-info seems unable to follow pointers. Damjan Jovanovic
Damjan, I dont believe it is necessary to have separate desktop files for different commands. Just append whatever you need in a new section. I believe chromium does that to differentiate some --flags. On Thu, Aug 11, 2011 at 6:57 PM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote:
On Thu, Aug 11, 2011 at 5:21 PM, Nowres Rafid <nowres.rafed(a)gmail.com> wrote:
I propose to associate .bat and .com files with wine's cmd in GNOME, KDE and others
AFAIK COM files are ancient self-contained real-mode DOS code, with no ability to load DLLs. Shouldn't they rather be loaded by DOSBox, which we delegate DOS applications to on the AMD64 architecture anyway?
BAT files should associate with Wine, but on Windows double-clicking them runs them in a terminal window (when last I checked). Thus we'd have to create a new wine-cmd.desktop which associates with BAT files. I'll look into it.
While I am at it, EXE files are not clearly Wine's either - they could be real-mode DOS executables, or .NET code intended for Mono on *nix. At some point, Wine/Mono/DOSBox and related projects need to have a talk about some kind of arbitration mechanism.
Damjan Jovanovic
Am 11.08.2011 18:18, schrieb Vincent Povirk:
I'm not sure DOSBox is able to competently open some random executable file. One would have to make a config file that sets up a drive mapping, runs the file, and quits. If Wine can do these things (and maybe also properly handle cases where the COM executable expects to be run on a windows machine or, say, a dos machine with win3.1 installed), it seems like a fine choice to me.
Wine can. See winevdm/winevdm.c:start_dosbox. I'm currently working on fixing issues on both sides. Am 11.08.2011 17:57, schrieb Damjan Jovanovic:
While I am at it, EXE files are not clearly Wine's either - they could be real-mode DOS executables, or .NET code intended for Mono on *nix. At some point, Wine/Mono/DOSBox and related projects need to have a talk about some kind of arbitration mechanism.
Am 11.08.2011 18:18, schrieb Vincent Povirk:
There was some talk on #mono (or #monodev) to the effect that the arbitration mechanism for different kinds of files is called mime types, and a DOS exe, x86/x64 PE exe, and CLR exe are all different and should have different mime types.
Talks are good, but did one project already do something for that, wo we can build upon it? -- Best Regards, André Hentschel
participants (7)
-
André Hentschel -
Damjan Jovanovic -
Jerome Leclanche -
Nowres Rafid -
Scott Ritchie -
Thomas Heckel -
Vincent Povirk