Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=1932
Your paranoid
Dmitry Timoshkov dmi...@baikal.ru wrote:
Based on a patch of Wolfgang Walter.
Is there anything wrong with this patch?
--
Dmitry.
Dmitry Timoshkov dmi...@baikal.ru writes:
MSDN for FlushFileBuffers says:
Flushes the buffers of a specified file and causes all buffered data to be
written to a file.
Linux man page says:
tcdrain() waits until all output written to the object referred to by fd has
been transmitted.
It's
Hello Dmitry,
we had this problem, too. I sent a patch to wine-devel some time ago (I think
2008). It had the same flaw as yours. I sent a different patch after Alexandre
gave me the same answer. I then posted 2009 an different one. It did not make
it into wine, though. I don't know why as
Alexandre Julliard julli...@winehq.org wrote:
It's a blocking call, you can't do that on the server side.
Can then something like in the patch from Wolfgang Walter be done
instead?
--
Dmitry.
Dmitry Timoshkov dmi...@baikal.ru writes:
Alexandre Julliard julli...@winehq.org wrote:
It's a blocking call, you can't do that on the server side.
Can then something like in the patch from Wolfgang Walter be done
instead?
Something like that, yes.
--
Alexandre Julliard
Wolfgang Walter w...@stwm.de writes:
@@ -2749,19 +2752,46 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile,
IO_STATUS_BLOCK* IoStatusBlock
{
NTSTATUS ret;
HANDLE hEvent = NULL;
-
-SERVER_START_REQ( flush_file )
-{
-req-handle = wine_server_obj_handle( hFile
Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard:
Wolfgang Walter w...@stwm.de writes:
@@ -2749,19 +2752,46 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile,
IO_STATUS_BLOCK* IoStatusBlock
{
NTSTATUS ret;
HANDLE hEvent = NULL;
-
-
Wolfgang Walter w...@stwm.de writes:
Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard:
You probably don't want to fail just because there's no unix fd.
What is the correct behaviour if there ist no such handle? Should I only fail
in the case FD_FILE_SERIAL ?
You'd want to
Am Montag, 26. August 2013, 19:55:04 schrieben Sie:
Wolfgang Walter w...@stwm.de writes:
Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard:
You probably don't want to fail just because there's no unix fd.
What is the correct behaviour if there ist no such handle? Should I
Dmitry Timoshkov dmi...@baikal.ru writes:
This patch should be quite obvious in its intent: it changes vtable type
to IUnknown which helps to remove This* to IUnknown* casts in order to
avoid obvious problems with vtable pointer placement inside of object
implementation. Basically this is
(which is much cleaner IMO since
every COM object implements IUnknown), but the implementation itself is cast
free, and looks now as an actual COM object. I found this 'This' to object cast
while investigating a crash in the COM code and decided to fix it since it's
clearly wrong and may lead to other
Dmitry Timoshkov dmi...@baikal.ru writes:
The patch actually removes the casts, the only cast that remains is the cast
on the caller's side for the vtable pointer (which is much cleaner IMO since
every COM object implements IUnknown), but the implementation itself is cast
free, and looks now
Alexandre Julliard julli...@winehq.org wrote:
The patch actually removes the casts, the only cast that remains is the cast
on the caller's side for the vtable pointer (which is much cleaner IMO since
every COM object implements IUnknown), but the implementation itself is cast
free
Dmitry Timoshkov dmi...@baikal.ru writes:
Alexandre Julliard julli...@winehq.org wrote:
The patch actually removes the casts, the only cast that remains is the
cast
on the caller's side for the vtable pointer (which is much cleaner IMO
since
every COM object implements IUnknown
This patch should be quite obvious in its intent: it changes vtable type
to IUnknown which helps to remove This* to IUnknown* casts in order to
avoid obvious problems with vtable pointer placement inside of object
implementation. Basically this is just a clean up patch.
Is there anything else to
Looks like I missed replacing the ITypeInfo casts with impl_from
calls, e.g.:
static HRESULT WINAPI ITypeInfo_fnGetTypeComp( ITypeInfo2 *iface,
ITypeComp * *ppTComp)
{
ITypeInfoImpl *This = (ITypeInfoImpl *)iface;
You can apply these, or wait until I amend them to fix that,
And why bother checking UNICODE?
Please clarify.
+MIDL_INTERFACE(509aaeda-5639-11d1-b6a1-f8757bf9)
+IPrintDialogServices : public IUnknown
+{
+#ifdef UNICODE
+virtual HRESULT STDMETHODCALLTYPE GetCurrentDevMode(LPDEVMODEW,UINT *) = 0;
+virtual HRESULT STDMETHODCALLTYPE
Vincent Povirk madewokh...@gmail.com wrote:
Does PrintDlgEx really use an interface with the same iid but
different function signatures depending on whether the A or W version
is called? If so, I think it would be best to define both versions, so
that our tests and implementation can easily
Why not use DECLARE_INTERFACE_ here? And why bother checking UNICODE?
On Mon, Apr 8, 2013 at 12:10 PM, Dmitry Timoshkov dmi...@baikal.ru wrote:
---
dlls/uuid/uuid.c | 1 +
include/commdlg.h | 80
+++
2 files changed, 81 insertions(+)
Nikolay Sivov bungleh...@gmail.com wrote:
Why not use DECLARE_INTERFACE_ here?
Because it seemed simpler to me without it.
And why bother checking UNICODE?
Please clarify.
--
Dmitry.
Henri said the other. It seems there is no consensus. ;)
Of course there is consensus. The consensus is:
- It depends on the situation
- There are acceptable naming conventions
- IDirectMusicLoaderImpl_IDirectMusicLoader_QueryInterface is not one
of the acceptable solutions
:)
On 8 November 2012 00:22, Michael Stefaniuc mstef...@redhat.com wrote:
But using just the capitalized letters from the name of the COM class as
a prefix and skipping the Impl would be in hindsight the better
standard. There are still 170+ COM interfaces to clean up which is a
sizable number
don't mention the
fact
the TRACE are not serialized between thread).
I the case of quartz most of the duplicated interfaces are
implemented
by the same base (C++) object. Or should be implemented that way. So
while multiple COM classes support the same interface most
2012/11/8 Henri Verbeet hverb...@gmail.com
On 8 November 2012 00:22, Michael Stefaniuc mstef...@redhat.com wrote:
But using just the capitalized letters from the name of the COM class as
a prefix and skipping the Impl would be in hindsight the better
standard. There are still 170+ COM
On 8 November 2012 13:13, Christian Costa titan.co...@gmail.com wrote:
dmloader_IDirectMusicLoader_Method or dmloader_Method?
E.g. dmloader_QueryInterface().
I was just saying removing the interface name was not a good thing imo
Yeah, I'm just disagreeing.
of the COM
class as
a prefix and skipping the Impl would be in hindsight the better
standard. There are still 170+ COM interfaces to clean up which is a
sizable number regardless of it being just 13% of the total interface
implementations, so we could still change the standard
the capitalized letters from the name of the COM
class as
a prefix and skipping the Impl would be in hindsight the better
standard. There are still 170+ COM interfaces to clean up which is a
sizable number regardless of it being just 13% of the total interface
:
But using just the capitalized letters from the name of the COM
class as
a prefix and skipping the Impl would be in hindsight the better
standard. There are still 170+ COM interfaces to clean up which is
a
sizable number regardless of it being just 13% of the total
interface
mailto:mstef...@redhat.com wrote:
But using just the capitalized letters from the name of the COM
class as
a prefix and skipping the Impl would be in hindsight the better
standard. There are still 170+ COM interfaces to clean up
which is a
sizable number regardless
...@gmail.com
mailto:hverb...@gmail.com
On 8 November 2012 00:22, Michael Stefaniuc
mstef...@redhat.com mailto:mstef...@redhat.com
mailto:mstef...@redhat.com mailto:mstef...@redhat.com wrote:
But using just the capitalized letters from the name of the COM
I was just saying removing the interface name was not a good thing imo
or am I missing something?
Right, the interface name needs to be there as it matches the COBJMACROS
name. Basically the C macro with a prefix.
Why? If you really want to keep interface name the better way imho is as
is as
it's usually done in mshtml, like HTMLDOMTextNode_*,
so here you don't need to add anything like prefix.
The first rule of COM in Wine is:
Do what Jacek says, not what he does!
;)
Ok. I note... ;)
HTMLDOMTextNode_* aka dropping the I is fine too as long as you do
*not* use the same
**IDirectMusicLoader_AddRef
I disagree. It is redundant, too long and thus hard to read.
I even have patches that remove some of them. I've never submitted those
as you beat me to the dm* COM cleanup.
I agree too if there is only one interface. I think it is but I would
like to be sure before submitting
patches that remove some of them. I've never
submitted those
as you beat me to the dm* COM cleanup.
I agree too if there is only one interface. I think it is but I
would like to be sure before submitting a patch.
I will check it and submit a patch
On 11/06/2012 11:05 PM, Christian Costa wrote:
Sure, separate patch to remove the duplicate name is fine. Just start
with that as it makes the subsequent COM cleanup patch shorter as it
cleans up the function header (whitespace and LPJUNK).
That's what I try to do altough I don't clearly
. It is redundant, too long and thus hard to read.
I even have patches that remove some of them. I've never
submitted those
as you beat me to the dm* COM cleanup.
I agree too if there is only one interface. I think it is but I
would like
of quartz most of the duplicated interfaces are implemented
by the same base (C++) object. Or should be implemented that way. So
while multiple COM classes support the same interface most of the time
there is one implementation only.
It's partly true. Sometimes some methods
On 11/6/2012 20:47, Christian Costa wrote:
---
dlls/dmloader/dmloader_private.h | 16 +++---
dlls/dmloader/loader.c | 107 +++---
2 files changed, 73 insertions(+), 50 deletions(-)
diff --git a/dlls/dmloader/dmloader_private.h
Le 06/11/2012 20:26, Nikolay Sivov a écrit :
On 11/6/2012 20:47, Christian Costa wrote:
---
dlls/dmloader/dmloader_private.h | 16 +++---
dlls/dmloader/loader.c | 107
+++---
2 files changed, 73 insertions(+), 50 deletions(-)
diff --git
those
as you beat me to the dm* COM cleanup.
And for example if an object has 2 interfaces X and Y that both derives
from Z then you will have 2 methods with the same name.
How will you make the distinction ?
You don't need to make a distinction as you have in most of the cases
only one
some of them. I've never submitted those
as you beat me to the dm* COM cleanup.
I agree too if there is only one interface. I think it is but I would
like to be sure before submitting a patch.
I will check it and submit a patch for that.
Too long and hard to read, I don't agree. See my response
hard to read.
I even have patches that remove some of them. I've never submitted those
as you beat me to the dm* COM cleanup.
I agree too if there is only one interface. I think it is but I would
like to be sure before submitting a patch.
I will check it and submit a patch for that.
Too long
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=20483
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=20484
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://winetestbot.dolphin/JobDetails.pl?Key=123
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://winetestbot.dolphin/JobDetails.pl?Key=122
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://winetestbot.dolphin/JobDetails.pl?Key=121
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=20152
Your paranoid
On 07/02/2012 01:32 AM, Marvin wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19684
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19686
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19677
Your paranoid
On 07/01/2012 12:12 AM, Marvin wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
Argh!
Please skip this patch, it is incomplete and just skips the rest of the
tests on Wine. I'll resubmit it when I implement COM aggregation for
MediaDet. Patch 4/4 can be still applied as it doesn't depends on this.
bye
michael
On 06/26/2012 11:53 PM, Michael Stefaniuc wrote
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19578
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=19577
Your paranoid
On 06/27/2012 12:02 AM, Marvin wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
No qedit.dll on those two boxes.
Full results can be found at
Hello Aric,
On 05/18/2012 04:27 PM, Aric Stewart wrote:
diff --git a/dlls/quartz/avisplit.c b/dlls/quartz/avisplit.c
index 5027e90..bac1b24 100644
--- a/dlls/quartz/avisplit.c
+++ b/dlls/quartz/avisplit.c
@@ -288,7 +288,7 @@ static HRESULT AVISplitter_next_request(AVISplitterImpl
*This,
Ahh, my understanding of COM cleanup grows...
-aric
On 5/18/12 10:27 AM, Michael Stefaniuc wrote:
Hello Aric,
On 05/18/2012 04:27 PM, Aric Stewart wrote:
diff --git a/dlls/quartz/avisplit.c b/dlls/quartz/avisplit.c
index 5027e90..bac1b24 100644
--- a/dlls/quartz/avisplit.c
+++ b/dlls/quartz
On 5/11/2012 09:19, Christian Costa wrote:
diff --git a/dlls/dmusic/dmusic_private.h b/dlls/dmusic/dmusic_private.h
index 73a05d4..96334c9 100644
--- a/dlls/dmusic/dmusic_private.h
+++ b/dlls/dmusic/dmusic_private.h
@@ -167,13 +167,14 @@ extern HRESULT WINAPI DMUSIC_CreateDMSynthPort(REFIID
2012/5/11 Nikolay Sivov bungleh...@gmail.com
On 5/11/2012 09:19, Christian Costa wrote:
diff --git a/dlls/dmusic/dmusic_private.h b/dlls/dmusic/dmusic_private.h
index 73a05d4..96334c9 100644
--- a/dlls/dmusic/dmusic_private.h
+++ b/dlls/dmusic/dmusic_private.h
@@ -167,13 +167,14 @@ extern
Le 02/04/2012 00:03, Michael Stefaniuc a écrit :
---
-static HRESULT WINAPI IDirectMusicPerformance8Impl_MusicToReferenceTime
(LPDIRECTMUSICPERFORMANCE8 iface, MUSIC_TIME mtTime, REFERENCE_TIME* prtTime) {
- IDirectMusicPerformance8Impl *This = (IDirectMusicPerformance8Impl
*)iface;
Hello Christian,
On 04/02/2012 09:05 AM, Christian Costa wrote:
While you're at it, could you put a 4 spaces indentation to whole method.
I thought about that but that would make the patch huge and it is
already big. The re-indentation can be done when the functions get
implemented.
bye
On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban ja...@codeweavers.com wrote:
On 03/30/12 17:55, Aric Stewart wrote:
diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h
index 35cd52b..d2f680c 100644
--- a/dlls/quartz/quartz_private.h
+++ b/dlls/quartz/quartz_private.h
@@
On 3/31/12 3:36 PM, John Klehm wrote:
On Fri, Mar 30, 2012 at 11:08 AM, Jacek Cabanja...@codeweavers.com wrote:
On 03/30/12 17:55, Aric Stewart wrote:
diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h
index 35cd52b..d2f680c 100644
--- a/dlls/quartz/quartz_private.h
+++
On 03/30/12 17:55, Aric Stewart wrote:
diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h
index 35cd52b..d2f680c 100644
--- a/dlls/quartz/quartz_private.h
+++ b/dlls/quartz/quartz_private.h
@@ -38,7 +38,7 @@
#define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time)
Meaning that I should not shift TO using that macro instead shift AWAY
from using it?
I have been doing some cleanup and been shifting to using it more.
-aric
On 3/30/12 11:08 AM, Jacek Caban wrote:
On 03/30/12 17:55, Aric Stewart wrote:
diff --git a/dlls/quartz/quartz_private.h
On 03/30/12 18:09, Aric Stewart wrote:
Meaning that I should not shift TO using that macro instead shift AWAY
from using it?
I have been doing some cleanup and been shifting to using it more.
ICOM_THIS_MULTI macro should go away. Your patch made ICOM_THIS_MULTI
look a bit better by using
ok thanks,
Glad I got this feedback before I started submitting my com cleanup
patches that used it.
-aric
On 3/30/12 11:26 AM, Jacek Caban wrote:
On 03/30/12 18:09, Aric Stewart wrote:
Meaning that I should not shift TO using that macro instead shift AWAY
from using it?
I have been doing
makes it much better, but I guess it's mostly
up to how Alexandre wants these.
Honestly, when Jacek documented it in the beginning I didn't like it
either. But having to deal now with the bad, the ugly and the censored
COM implementations in Wine I have overcome my hate for casts and
actually like
On 22 March 2012 00:50, Michael Stefaniuc mstef...@redhat.de wrote:
-static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown
*iface, REFIID riid, void **object)
+static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown
*iface, REFIID riid,
+
Hi,
Michael Stefaniuc wrote:
static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer
+if (pUnk) {
+WARN(invalid parameter: pUnk != NULL\n);
+/* *lplpDSCaptureBuffer = NULL; Not done by native dsound */
+return DSERR_NOAGGREGATION;
+}
What's your
DSERR_NOAGGREGATION;
+}
What's your rationale for doing so?
Bug compatibility with native is fine, however not setting NULL is
problematic before you've reached 100% compatibility, have you?
Not in this case which deals with COM aggregation. dsound doesn't
supports that and it is documented
= NULL; Not done by native dsound */
+return DSERR_NOAGGREGATION;
+}
What's your rationale for doing so?
Bug compatibility with native is fine, however not setting NULL is
problematic before you've reached 100% compatibility, have you?
Not in this case which deals with COM
Michael Stefaniuc mstef...@redhat.com writes:
Now i would have had different options how to deal with that.
- Silently drop the test.
- Dropping the test and documenting why it deviates from the standard test.
- Adding the test and marking it todo_wine.
- Add the test and fix the code as the
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=15558
Your paranoid
Marvin wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=15558
Your
Hi,
I'm not satisfied with the current winmm+mmdevapi logging. I suspect that COM
logging of other components is similarly bad. Consider the following
snippet. It looks like a +relay log, not showing what I want to see.
0022:trace:winmm:waveOutWrite (0xc000, 0x21f140, 32)
0020
On 27 September 2011 13:49, joerg-cyril.hoe...@t-systems.com wrote:
snippet. It looks like a +relay log, not showing what I want to see.
That's mostly intentional, for COM traces in general at least. The
main purpose of the initial trace in COM calls is to show that a
function gets called
For those interested in coccinelle
Michael Stefaniuc wrote:
On 08/18/2011 03:29 PM, Dan Kegel wrote:
Seems to cause a test failure here?
Argh, indeed!
- (IUnknown*)runtimes[i]
+ runtimes-ICLRRuntimeInfo_iface
The array subscript got dropped and that wasn't a manual change. Need to
check
Seems to cause a test failure here?
make[1]: Entering directory
`/home/dank/wineslave.dir/sandbox/slave/runtests/build/dlls/mscoree/tests'
../../../tools/runtest -q -P wine -M mscoree.dll -T ../../.. -p
mscoree_test.exe.so metahost.c touch metahost.ok
metahost.c:135: Test failed: got unexpected
On 08/18/2011 03:29 PM, Dan Kegel wrote:
Seems to cause a test failure here?
Argh, indeed!
- (IUnknown*)runtimes[i]
+ runtimes-ICLRRuntimeInfo_iface
The array subscript got dropped and that wasn't a manual change. Need to
check if I'm hitting a bug in coccinelle or just a feature.
bye
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
. 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
Am 11.08.2011 17:21, schrieb Nowres Rafid:
I propose to associate .bat and .com files with wine's cmd in GNOME,
KDE and others
Did you mean .bat and .cmd?
This. are the both endings for commandline (batch) scripts
Yes
On Fri, 2011-08-12 at 08:50 +0200, Thomas Heckel wrote:
Am 11.08.2011 17:21, schrieb Nowres Rafid:
I propose to associate .bat and .com files with wine's cmd in GNOME,
KDE and others
Did you mean .bat and .cmd?
This. are the both endings for commandline (batch) scripts
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.ra...@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
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
, 2011 at 5:21 PM, Nowres Rafid nowres.ra...@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
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
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
Hello Alistair,
sorry that I missed the first time. And Alexandre should have marked it
as PENDING (good idea but current implementation is rejected).
Alistair Leslie-Hughes wrote:
Changelog:
oleaut32: COM Cleanup ICreateTypeLib2Imp
Best Regards
Alistair Leslie-Hughes
From
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11823
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11825
Your paranoid
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11824
Your paranoid
On 06/19/2011 02:27 PM, Marvin wrote:
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
Marvin wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11350
This
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=11350
Your paranoid
1 - 100 of 251 matches
Mail list logo
