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 andr
Dmitry Timoshkov wrote:
> Based on a patch of Wolfgang Walter.
Is there anything wrong with this patch?
--
Dmitry.
Am Montag, 26. August 2013, 19:55:04 schrieben Sie:
> Wolfgang Walter 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
Wolfgang Walter 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 still
Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard:
> Wolfgang Walter writes:
> > @@ -2749,19 +2752,46 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile,
> > IO_STATUS_BLOCK* IoStatusBlock>
> > {
> >
> > NTSTATUS ret;
> > HANDLE hEvent = NULL;
> >
> > -
> > -SERVE
Wolfgang Walter 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 );
Dmitry Timoshkov writes:
> Alexandre Julliard 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
julli...@winehq.org
Alexandre Julliard 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.
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 ther
Dmitry Timoshkov 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 a blocking
Dmitry Timoshkov writes:
> Alexandre Julliard 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
>
Alexandre Julliard 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
>
Dmitry Timoshkov 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
t
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 as an actual COM object. I found this 'This' to object cast
while investigating a crash in the COM cod
Dmitry Timoshkov 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 just a clean up
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 c
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, too
Vincent Povirk 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 provide/use both.
>> 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 GetCurr
Nikolay Sivov wrote:
> Why not use DECLARE_INTERFACE_ here?
Because it seemed simpler to me without it.
> And why bother checking UNICODE?
Please clarify.
--
Dmitry.
Why not use DECLARE_INTERFACE_ here? And why bother checking UNICODE?
On Mon, Apr 8, 2013 at 12:10 PM, Dmitry Timoshkov wrote:
> ---
> dlls/uuid/uuid.c | 1 +
> include/commdlg.h | 80
> +++
> 2 files changed, 81 insertions(+)
>
> diff --gi
> >
> >
> > 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 solutio
ou really want to keep interface name the better way imho 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!"
>
>
>
>
>
>> 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 bet
; <mailto:hverb...@gmail.com
> <mailto:hverb...@gmail.com>>>
> >
> > On 8 November 2012 00:22, Michael Stefaniuc
> mailto:mstef...@redhat.com>
> > <mailto:mstef...@redhat.com <mailto:mstef...@redhat.com>>>
chael Stefaniuc >> <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
>>>
t; > > 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
> >
rom 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
> implemen
On 11/08/2012 01:13 PM, Christian Costa wrote:
>
>
> 2012/11/8 Henri Verbeet mailto:hverb...@gmail.com>>
>
> On 8 November 2012 00:22, Michael Stefaniuc <mailto:mstef...@redhat.com>> wrote:
> > But using just the capitalized letters from the name
On 8 November 2012 13:13, Christian Costa 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.
2012/11/8 Henri Verbeet
> On 8 November 2012 00:22, Michael Stefaniuc 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
gt; > Just take quartz with object that can have up to 10 interfaces and
> > > interfaces that can be implemented by up to 10 objects.
> > > Put a bit of multithreading on top of it (and I don't mention the
> fact
> > > the TRACE are not seria
On 8 November 2012 00:22, Michael Stefaniuc 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
> sizabl
but this meaningfull name.
> > Just take quartz with object that can have up to 10 interfaces and
> > interfaces that can be implemented by up to 10 objects.
> > Put a bit of multithreading on top of it (and I don't mention the fact
> > the TRACE are not serialized
t's
> > easier to read in
> > a log file.
> > IDirectMusicLoaderImpl___IDirectMusicLoader_AddRef
> >
> > I disagree. It is redundant, too long and thus hard to read.
> > I even have 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
sagree. 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 i
;>>> Impl__
>>>> but in some case where there is only 1 interface for the object:
>>>> Impl_
>>>> is better.
>>>>
>>>> The interface name should be clearly visible IMO it's easier to read in
>>>> a log file.
>>>> IDirectMusicL
me 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 respo
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 to Nikolay.
And for example if an objec
face for the object:
> Impl_
> is better.
>
> The interface name should be clearly visible IMO it's easier to read in
> a log file.
> IDirectMusicLoaderImpl_IDirectMusicLoader_AddRef
I disagree. It is redundant, too long and thus hard to read.
I even have patches that remove some
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 a/dlls/
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 b/dlls/dmloader/dmlo
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 android
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 android
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 android.
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 android.
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 android.
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 android
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
> http://testbot.winehq.org/Job
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 android
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 android
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
> http://testbot.winehq.org/Job
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 android
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
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 android
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 android
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 Stefa
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
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
> *Thi
2012/5/11 Nikolay Sivov
> 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 HRESUL
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
rii
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
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;
+sta
On 3/31/12 3:36 PM, John Klehm wrote:
On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban 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_p
On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban 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
>> @@ -38,7 +38,7 @
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
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 C
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 b/dlls/quart
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(ti
gt;> - *object = NULL;
>> -return E_NOINTERFACE;
>> +IUnknown_AddRef((IUnknown*)*ppv);
>> +return S_OK;
>> }
> I'm not sure this really makes it much better, but I guess it's mostly
> up to how Alexandre wants these.
Honestly, when Jacek do
On 22 March 2012 00:50, Michael Stefaniuc 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,
> + void **ppv)
> {
Michael Stefaniuc 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 change is triv
> 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.
>
>> What I mean is that if there's a situation where Wine's CreateCaptureBuffer
>>
= 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 whic
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 ration
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
>
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 android
On 27 September 2011 13:49, 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 at all, since these don'
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)
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
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
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
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 chanc
andle 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 ma
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?
>
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
o 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 fo
e 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
PM, Nowres Rafid 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 loade
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 wi
On Thu, Aug 11, 2011 at 5:21 PM, Nowres Rafid 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 l
I propose to associate .bat and .com files with wine's cmd in GNOME, KDE
and others
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
> Alis
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
> http://testbot.wineh
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 android
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 android
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 android
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
Thi
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 android
1 - 100 of 267 matches
Mail list logo
