Re: Implement StdMarshal::ReleaseMarshalData
Mike Hearn wrote: Mike Hearn <[EMAIL PROTECTED]> Rob Shearman <[EMAIL PROTECTED]> Implement StdMarshal::ReleaseMarshalData + res = IRpcStubBuffer_Release(stub); I'm not sure but, is there a hypothical race condition here when a thread switch takes place and someone tries to reuse the stub while valid is not set to TRUE yet (but the stub has already been released)? + stubs[i].valid = FALSE; --- Jeroen Janssen
building COM client/server with proxy using winelib & widl?
Hello, I was wondering whether there is a wine COM client/server application that makes use of winelib & widl (to generate a proxy/stub dll). Apparently I'm missing some #defines in wine's rpcproxy.h in order to be able build the proxy/stub dll? For instance: PROXYFILE_LIST_START PROXYFILE_LIST_END REFERENCE_PROXY_FILE It seems that these defines are present in the rpcproxy.h included with MinGW? I googled for it and found http://www.cs.up.ac.za/courses/EPE210/software/MinGW-1.1/include/rpcproxy.h On a side note can widl generate proxy/stub code yet? --- Jeroen Janssen
Re: dinput.dll: mouse didn't work
Hi, On Thu, Jul 22, 2004 at 07:38:26PM +0200, Michael Schlüter wrote: > Hi, > > I've a small problem with wine (cvs from today) when trying to play a > game that uses dinput.dll. The game starts fine, keyboard inputs works > but the mouse cursor didn't move. I had a look at the source code of > dinput/mouse.c and the trace messages of dinput. But there is one thing > I don't understand. The callback function for the mouse > (dinput_mouse_hook) is never called. The initialising look good: The question is: Did it work right before? Someone recently did some dinput mouse changes; these might be responsible here. > But then there is no other dinput message. Shouldn't there be a call of > the mouse callback function? No idea, sorry. Please keep investigating that, and keep reading dinput docs. Would be very nice to see that fixed! Andreas Mohr
Re: Check Server Version From Client Dlls
Robert Shearman <[EMAIL PROTECTED]> writes: > DLL separation is not going to help when a function in user32 calls > the server and fails due to mismatched server interfaces. Yes it will, because part of that task is also to ensure that the server protocol is backwards compatible. This isn't fully the case yet but it should be soon. And really I don't think upgrading a single dll is a case common enough to justify exporting new APIs for a check that will need to be removed later anyway. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Check Server Version From Client Dlls
Alexandre Julliard wrote: Robert Shearman <[EMAIL PROTECTED]> writes: DLL separation is not going to help when a function in user32 calls the server and fails due to mismatched server interfaces. Yes it will, because part of that task is also to ensure that the server protocol is backwards compatible. This isn't fully the case yet but it should be soon. And really I don't think upgrading a single dll is a case common enough to justify exporting new APIs for a check that will need to be removed later anyway. Fair enough. Rob
Re: Check Server Version From Client Dlls
Alexandre Julliard wrote: Robert Shearman <[EMAIL PROTECTED]> writes: if (ver != SERVER_PROTOCOL_VERSION) MESSAGE( "Error: server version mismatch.\n" "Your %s binary was not upgraded correctly\n" "or the wrong wineserver is still running.\n", dll_name ); return (ver == SERVER_PROTOCOL_VERSION); Ok, I'll send an updated patch. Actually I don't think we want to add this kind of check at all. The whole point of dll separation is to make sure we don't need that sort of thing; while we are not 100% there yet, adding more version checks is going in the wrong direction. DLL separation is not going to help when a function in user32 calls the server and fails due to mismatched server interfaces. You just get a very cryptic error message: err:msg:QUEUE_CreateMsgQueue Cannot get thread queue Note that I only added it to the DLLs that will always need server calls (i.e. not advapi32), but I was very surprised that gdi32 didn't call the server. Rob
Re: Check Server Version From Client Dlls
Robert Shearman <[EMAIL PROTECTED]> writes: >> if (ver != SERVER_PROTOCOL_VERSION) >> MESSAGE( "Error: server version mismatch.\n" >> "Your %s binary was not upgraded correctly\n" >> "or the wrong wineserver is still running.\n", dll_name ); >> return (ver == SERVER_PROTOCOL_VERSION); >> > > Ok, I'll send an updated patch. Actually I don't think we want to add this kind of check at all. The whole point of dll separation is to make sure we don't need that sort of thing; while we are not 100% there yet, adding more version checks is going in the wrong direction. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Check Server Version From Client Dlls
Andreas Mohr wrote: Hi, On Thu, Jul 22, 2004 at 02:59:47PM +0100, Robert Shearman wrote: Changelog: Check server version from x11drv, kernel32 and user32 to prevent mismatches of installed dlls. Slight overkill, I'd say. Why not do: if (!wine_server_check_version( "x11drv", SERVER_PROTOCOL_VERSION )) ... if (ver != SERVER_PROTOCOL_VERSION) MESSAGE( "Error: server version mismatch.\n" "Your %s binary was not upgraded correctly\n" "or the wrong wineserver is still running.\n", dll_name ); return (ver == SERVER_PROTOCOL_VERSION); Ok, I'll send an updated patch. Rob
Re: PATCH: controls/menu.c case ranges
On Thu, Jul 22, 2004 at 02:34:20PM -0700, Alexandre Julliard wrote: > Marcus Meissner <[EMAIL PROTECTED]> writes: > > > Another try on fixing the case range problems (WORD is unsigned, > > HBMMENU_CALLBACK is -1, so out of range of the switch). > > I think this is revealing a deeper problem with that code, the magic > value check should be done against the whole handle, not just the low > word. Hmm. It just special cases those specific handle values. But yes, casting to (WORD) is wrong here if normal handles can appear too. Ciao, marcus
Re: PATCH: controls/menu.c case ranges
Marcus Meissner <[EMAIL PROTECTED]> writes: > Another try on fixing the case range problems (WORD is unsigned, > HBMMENU_CALLBACK is -1, so out of range of the switch). I think this is revealing a deeper problem with that code, the magic value check should be done against the whole handle, not just the low word. -- Alexandre Julliard [EMAIL PROTECTED]
Re: daily wine cvs source snapshots?
FYI: We also tar up the entire CVS on our main ftp server here: ftp://ftp.winehq.org/pub/wine/full-cvs-2004-07-21.tar.gz On Thu, 2004-07-22 at 05:35, Jeroen Janssen wrote: > > SSH tunneling not possible either? > > Nope, unfortunately not. > > >> Would it be possible to have daily cvs snapshots (cvs export) of the > >> wine HEAD tree? > > Err... we've already been having that for a VERY long time ;-) > > http://lisas.de/~andi/wine_files/wine-cvs-hopefully-current.tar.bz2 > > (I thought that was mentioned at WineHQ? Not sure, though, especially with > > all those changes in the meantime...) > > Thanks a lot!! > > I was not aware of this being available (and it's not on the > http://www.winehq.com/site/download page either). > --- > Jeroen Janssen -- _ _ WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_ __ ___ __ __ _ _ _-= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:[EMAIL PROTECTED] |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1711553 Yahoo: laxdragon
Re: too many functions in msvcrt20.dll?
Chipzz <[EMAIL PROTECTED]> writes: > Much to my surprise, the wine implementation has more(!!) functions than > the native dll. So, I was wondering, this screws up the index of these > functions in the list, right? Does that index actually matter? No, the index doesn't matter, the functions are looked up by name, so it's mostly a cosmetic issue; but it should probably still be fixed. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Add a WINEVER environment variable
Mike Hearn <[EMAIL PROTECTED]> writes: > Yeah I thought about that, but to be honest the only reason to have this > is pure convenience - the more typing required the less convenient it is. > I never, ever set the DOS version. It's always either win9x vs win2k for > me, so saving a few characters seemed worth it. > > But, I can change it if really wanted. Alexandre? Frankly I don't think we want yet another environment variable, we have already way too many of them. -- Alexandre Julliard [EMAIL PROTECTED]
about wine dsound
HI My name are Magnus Olsen (call GreatLord at reactos channel) I am one of reactos devlooper I we are now trying get the sound working in reactos. I did start to port over wine dsound and find out it did have it own api layer, to get dsound guid, and other stuff. I did rewrite to thuse part to get it working under windows. Yes wine dsound with some modifaction are now working in windows. we need now do some modifaction to wine winmm get it windows / reactos compatible. the GetDeviceID in Dsound get the value from the windows / reactos system register now. and it works under windows 2k / XP write a api layer betwin dsound api call to WaveInMessage and WaveOutMessage DRV_QUERYDSOUNDGUID 100% support for windows and reactos) DRV_QUERYDSOUNDDESC 80% support for windows and reactos need to figut how to get some data from windows api)DRV_QUERYDSOUNDIFACE 0% force dsound to software emulation mode until I or some else fix it for windows or reactos
dinput.dll: mouse didn't work
Hi, I've a small problem with wine (cvs from today) when trying to play a game that uses dinput.dll. The game starts fine, keyboard inputs works but the mouse cursor didn't move. I had a look at the source code of dinput/mouse.c and the trace messages of dinput. But there is one thing I don't understand. The callback function for the mouse (dinput_mouse_hook) is never called. The initialising look good: trace:dinput:SysMouseAImpl_Acquire (this=0x40269480) trace:hook:set_windows_hook WH_MOUSE_LL 0x40dd64e0 0 -> 0x20028 trace:dinput:SysMouseAImpl_Acquire Warping mouse to 512 - 384 trace:dinput:SysKeyboardAImpl_Unacquire (this=0x40269db8) trace:dinput:SysKeyboardAImpl_SetEventNotification (this=0x40269db8,0x0124) trace:dinput:SysKeyboardAImpl_Acquire (this=0x40269db8) trace:dinput:SysKeyboardAImpl_Acquire (this=0x40269db8) trace:dinput:SysMouseAImpl_Acquire (this=0x40269480) ... And later when pressing a mouse button: trace:hook:HOOK_CallHooks calling hook in thread 0013 WH_MOUSE_LL code 0 wp 200 lp 4071d074 But then there is no other dinput message. Shouldn't there be a call of the mouse callback function? Bye, Michael
Re: tests: safe MAPI init
Hi, > Windows XP Professional, in a network with roaming profiles > served by Samba. I don't know what is relevant. Strange, I'd have assumed you'd have an extended mapi client installed by deault. What is your default mail client? > OK, sending you off-list. Thanks. I'll have a look at this. > Well, test_PropCopyMore() has four direct references IIRC. > You may or may not want to "fix" it (like the IMPORTS). That should prbably be fixed eventually, yes. > The long for loop in test_ScCountProps(void) is probably an > overkill, too: if it happens to produce output in every > iteration, it gets too big. Yes, it should probably bail at the first error; that should be easy to change. I'm rather busy with work ATM but when I get a day off I'll look at fixing these (and digging out the rest of the mapi code I haven't submitted yet). Regards, Jon = "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live [EMAIL PROTECTED] __ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/
too many functions in msvcrt20.dll?
I was looking at porting a small subset of msvcrt80.dll, and so I took a look at msvcrt20.dll. I first used a disassembler to get a list of the functions in the native windows dll, ran a script over that, and then ran another script over msvcrt20.spec. Much to my surprise, the wine implementation has more(!!) functions than the native dll. So, I was wondering, this screws up the index of these functions in the list, right? Does that index actually matter? The diff between the 2 files is attached. With kr, Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."--- msvcrt20.wine.noline2004-07-22 08:36:26.0 +0200 +++ msvcrt20.exports.noline 2004-07-22 08:21:31.0 +0200 @@ -524,7 +524,6 @@ _amsg_exit _assert _atodbl -_atoi64 _atoldbl _beep _beginthread @@ -622,8 +621,6 @@ _heapused _heapwalk _hypot -_i64toa -_i64tow _initterm _iob _isatty @@ -766,7 +763,7 @@ _safe_fprem1 _scalb _searchenv -__seh_longjmp_unwind [EMAIL PROTECTED] _seterrormode _setjmp _setjmp3 @@ -846,8 +843,6 @@ _toupper _tzname _tzset -_ui64toa -_ui64tow _ultoa _ultow _umask @@ -928,7 +923,6 @@ _wtempnam _wtmpnam _wtoi -_wtoi64 _wtol _wunlink _wutime
Re: COM outproc & CFProxy unhandled interface for IRunnableObject
Jeroen Janssen wrote: I am not sure, but there seems to be a difference in the outproc handling of the CoCreateInstance call? This goes ok: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, IID_IX, (void**)&pIX) ; However this seems to go wrong?: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, __uuidof(IUnknown), (void**)&pIUnknown); hr = pIUnknown->QueryInterface(IID_IX, (void **)&pIX); Summary: If you perform a CoCreateInstance for IUnknown (outproc), you get back the classfactory instead of the proxy to the object itself? If you look at the code for CoCreateInstance you will see that it is completely agnostic to the context it is being used for. If what you say were true then every COM program on Wine would be broken (and that isn't true). Maybe you can check this behaviour? (I don't know exactly if this is indeed what seems to wrong or that I might have made a mistake with the simple test program). Sure. If you let me know what program this is then it would be even better. Me and Rob are starting to scrape together a plan, I think, and as part of working on other apps we're fixing bits as we go, but it's a long long road we have ahead of us. Any help would certainly be welcome. Well, I'm trying get this application running with wine, I don't know what else I might walk into, but I surely hope to do some contributions to wine in the process. Unfortunately, you have stumbled into one of the most confusing areas of the Win32 API that I think only one person in the world fully understands (Don Box in case you are wondering). I do hope that you will make some contributions to Wine in the future. Rob
Re: tests: safe MAPI init
Hi, > the mapi32 tests call scInitMapiUtil, which pops up an alert > box saying something like (translating it) "Your default > mailer application isn't capable of this operation, please > ensure that Outlook is configured as the default mailer." This probably means that you don't have a mapi client installed, I guess that the default win32 stub mapi implementation just falls back into 'advertise ms software' mode when this happens. Is this an early Windows version by any chance? if you can, please run 'winedump spec mapi32.dll' and 'winedump spec mapistub.dll' (if the latter exists) and send me the resulting .spec file, It should be possible to skip the tests unless there is a mapi client installed. > As a side note, most of the mapi tests are very careful > about calling every function through a pointer acquired by > GetProcAddr(), Thats just precautionary, I could only test on xp and some entrypoints are sure to not be present in earlier native versions. Cheers, Jon = "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Re: COM outproc & CFProxy unhandled interface for IRunnableObject
> From: Mike Hearn <[EMAIL PROTECTED]> >> Maybe my 'real' problem is that based upon the logging, I also see a >> CFProxy Unhandled interface for the first interface that the client is >> trying to access (but I need to know more about how COM/wine deals with >> this). > > Are you sure you're using COM right? I have also written an outproc > server test and it works OK - at least I've been able to marshal a Hello > World RPC across. Well, it seems to work ok on Windows, so there must be something 'ok' about it. Also, I did not write the application myself. I'm just trying to get it run under wine. I am not sure, but there seems to be a difference in the outproc handling of the CoCreateInstance call? This goes ok: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, IID_IX, (void**)&pIX) ; However this seems to go wrong?: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, __uuidof(IUnknown), (void**)&pIUnknown); hr = pIUnknown->QueryInterface(IID_IX, (void **)&pIX); Summary: If you perform a CoCreateInstance for IUnknown (outproc), you get back the classfactory instead of the proxy to the object itself? Maybe you can check this behaviour? (I don't know exactly if this is indeed what seems to wrong or that I might have made a mistake with the simple test program). > Me and Rob are starting to scrape together a plan, I think, and as part of > working on other apps we're fixing bits as we go, but it's a long long > road we have ahead of us. Any help would certainly be welcome. Well, I'm trying get this application running with wine, I don't know what else I might walk into, but I surely hope to do some contributions to wine in the process. --- Jeroen Janssen
Re: devenum
Ivan Leo Puoti wrote: English resources moved to En.rc, language neutral resources moved to Xx.rc, and italian resources added in It.rc Licence: LGPL Ivan. Ivan, Why you do not leave the neutral resources in the main archive? Greetings, Marcelo
Re: Check Server Version From Client Dlls
Hi, On Thu, Jul 22, 2004 at 02:59:47PM +0100, Robert Shearman wrote: > > Changelog: > Check server version from x11drv, kernel32 and user32 to prevent > mismatches of installed dlls. Slight overkill, I'd say. Why not do: if (!wine_server_check_version( "x11drv", SERVER_PROTOCOL_VERSION )) ... if (ver != SERVER_PROTOCOL_VERSION) MESSAGE( "Error: server version mismatch.\n" "Your %s binary was not upgraded correctly\n" "or the wrong wineserver is still running.\n", dll_name ); return (ver == SERVER_PROTOCOL_VERSION); Greetings, Andreas Mohr
Re: COM outproc & CFProxy unhandled interface for IRunnableObject
On Thu, 22 Jul 2004 14:45:31 +0200, Jeroen Janssen wrote: > Maybe my 'real' problem is that based upon the logging, I also see a > CFProxy Unhandled interface for the first interface that the client is > trying to access (but I need to know more about how COM/wine deals with > this). Are you sure you're using COM right? I have also written an outproc server test and it works OK - at least I've been able to marshal a Hello World RPC across. The class factory that is marshalled back across only supports IClassFactory as far as I know, IRunnableObject may well be implemented on the instances it creates but not the factory itself. >> Ove from Transgaming has donated their COM implementation to wine >> (several years ago), and Mike Hearn and I are trying to find a way to >> merge it that: >> 1) Improves our (D)COM implementation 2) Doesn't introduce any >> regressions >> 3) Has the right architecture to build upon for future features > > Ok, is the code that Ove released available somewhere? How far in the > process are you with merging? Is there a TODO list or something like > that? I'm trying to understand if I can help the wine project by getting > this application working, so that's why I'm asking. Jeroen Janssen It's not really possible (or a good idea) to merge all of it. Try googling for "world-of-dcom" and that should show you the patch I got last time I did a quick merge. Me and Rob are starting to scrape together a plan, I think, and as part of working on other apps we're fixing bits as we go, but it's a long long road we have ahead of us. Any help would certainly be welcome. thanks -mike
Re: Add a WINEVER environment variable
On Thu, 22 Jul 2004 09:05:47 +0200, Andreas Mohr wrote: > I'm afraid I don't like the naming, since it's potentially confusing > (plus, it somewhat goes against established rules, "WINE + function"). > What about WINEWINVER instead? I for one like it much more. > Also, this doesn't take into account that we're also able to set the > DOS version. So what would that be called then? WINEVER, too? ;-) > WINEWINVER and WINEDOSVER is a much better choice, IMHO. Yeah I thought about that, but to be honest the only reason to have this is pure convenience - the more typing required the less convenient it is. I never, ever set the DOS version. It's always either win9x vs win2k for me, so saving a few characters seemed worth it. But, I can change it if really wanted. Alexandre?
Re: COM outproc & CFProxy unhandled interface for IRunnableObject
> IRunnableObject does not have anything to do with COM marshalling; it is > an OLE thing. MSDN says this about it: "The *IRunnableObject *interface > enables a container to control the running of its embedded objects". So > basically, I don't see any reason why CFProxy (IClassFactory proxy) > should implement it. Therefore, I suspect this message is just > distracting you from the real source of the problem (and you don't state > what the problem is). Well MSDN also states "In the case of an object implemented with a local server, calling IRunnableObject::Run launches the server's .EXE file. In the case of an object implemented with an in-process server, calling the Run method causes the object .DLL file to transition into the running state". So I'm wondering now if there is a relation with 'outproc' behaviour. As far as the problem that I'm seeing, I indeed forget to mention that. It seems that my client program can not access a COM object from the server using outproc. Maybe my 'real' problem is that based upon the logging, I also see a CFProxy Unhandled interface for the first interface that the client is trying to access (but I need to know more about how COM/wine deals with this). >>Can someone provide more information on how wine deals with Outproc COM? > > Mike Hearn posted a really good outline of COM to wine-devel a week or > two ago. I suggest that you read that first, but feel free to ask any > specific questions. Ok, I'll read that first. Thanks for pointing this out. >>On a side note, what are the main differences in COM implementation >>between wine and winex (if I understand correctly, Transgaming rewrote >> the >>COM implemenation for winex in order to better support the InstallShield >>installer?). > > Ove from Transgaming has donated their COM implementation to wine > (several years ago), and Mike Hearn and I are trying to find a way to > merge it that: > 1) Improves our (D)COM implementation > 2) Doesn't introduce any regressions > 3) Has the right architecture to build upon for future features Ok, is the code that Ove released available somewhere? How far in the process are you with merging? Is there a TODO list or something like that? I'm trying to understand if I can help the wine project by getting this application working, so that's why I'm asking. Jeroen Janssen
Re: COM outproc & CFProxy unhandled interface for IRunnableObject
Jeroen Janssen wrote:
Hello,
I'm trying to run 2 programs:
1) is a COM server program
2) is a COM client program
Now, program 2) tries to access a COM component from 1) (outproc).
It seems some marshalling is being done, but eventually I get:
fixme:ole:CFProxy_QueryInterface Unhandled interface:
{0126---c000-0046}
This interface seems to be IRunnableObject.
Now I'm not exactly sure how this is supposed to work, or even if this is
the reason why my test currently fails. I can provide more logging/info if
I know what exactly to provide.
IRunnableObject does not have anything to do with COM marshalling; it is
an OLE thing. MSDN says this about it: "The *IRunnableObject *interface
enables a container to control the running of its embedded objects". So
basically, I don't see any reason why CFProxy (IClassFactory proxy)
should implement it. Therefore, I suspect this message is just
distracting you from the real source of the problem (and you don't state
what the problem is).
Note that I tried a small outproc client/server test that seems to go ok
without this error, so the 'basic' outproc mechanism seems to work ok.
Good.
Can someone provide more information on how wine deals with Outproc COM?
Mike Hearn posted a really good outline of COM to wine-devel a week or
two ago. I suggest that you read that first, but feel free to ask any
specific questions.
On a side note, what are the main differences in COM implementation
between wine and winex (if I understand correctly, Transgaming rewrote the
COM implemenation for winex in order to better support the InstallShield
installer?).
Ove from Transgaming has donated their COM implementation to wine
(several years ago), and Mike Hearn and I are trying to find a way to
merge it that:
1) Improves our (D)COM implementation
2) Doesn't introduce any regressions
3) Has the right architecture to build upon for future features
Rob
Re: daily wine cvs source snapshots?
> SSH tunneling not possible either? Nope, unfortunately not. >> Would it be possible to have daily cvs snapshots (cvs export) of the >> wine HEAD tree? > Err... we've already been having that for a VERY long time ;-) > http://lisas.de/~andi/wine_files/wine-cvs-hopefully-current.tar.bz2 > (I thought that was mentioned at WineHQ? Not sure, though, especially with > all those changes in the meantime...) Thanks a lot!! I was not aware of this being available (and it's not on the http://www.winehq.com/site/download page either). --- Jeroen Janssen
COM outproc & CFProxy unhandled interface for IRunnableObject
Hello,
I'm trying to run 2 programs:
1) is a COM server program
2) is a COM client program
Now, program 2) tries to access a COM component from 1) (outproc).
It seems some marshalling is being done, but eventually I get:
fixme:ole:CFProxy_QueryInterface Unhandled interface:
{0126---c000-0046}
This interface seems to be IRunnableObject.
Now I'm not exactly sure how this is supposed to work, or even if this is
the reason why my test currently fails. I can provide more logging/info if
I know what exactly to provide.
Note that I tried a small outproc client/server test that seems to go ok
without this error, so the 'basic' outproc mechanism seems to work ok.
Can someone provide more information on how wine deals with Outproc COM?
On a side note, what are the main differences in COM implementation
between wine and winex (if I understand correctly, Transgaming rewrote the
COM implemenation for winex in order to better support the InstallShield
installer?).
Best regards,
Jeroen Janssen
Re: Fix crash in dsound test
Paul Millar <[EMAIL PROTECTED]> writes: > On Monday 19 July 2004 12:50, Ferenc Wagner wrote: > >> Can you (cross)build the directsound tests? > > FWIW, yes: > > http://www.astro.gla.ac.uk/users/paulm/wine/dsound_test-20040721.10-00.exe Fine, that works, even. :) What an interesting experience it is to hear variously-pitched 440 Hz sounds! The wonders of Doppler effect, I guess. Why not make the velocity such that the audible tones form a minor second for example? That way it really could be an interactive *test*... :] Back to the build: Paul, I can't see your winetest builds being used (allowing for the present outage). Do you know what the problem is? Those of Kevin are used for all the reports I checked, but he hasn't responded yet. I'll send a patch to include dsound in winetest, and we will see if he publishes anything... -- Thanks, Feri.
Re: tests: safe MAPI init
Jon Griffiths <[EMAIL PROTECTED]> writes: >> Windows XP Professional, in a network with roaming profiles >> served by Samba. I don't know what is relevant. > > Strange, I'd have assumed you'd have an extended mapi client > installed by deault. What is your default mail client? If it's Control Panel/Internet Options/Programs/E-mail, then Microsoft Outlook. I don't use this machine of Windows in particular, so only guessing. > Yes, it should probably bail at the first error; that should > be easy to change. I'm rather busy with work ATM but when > I get a day off I'll look at fixing these (and digging out > the rest of the mapi code I haven't submitted yet). Great! -- Cheers, Feri.
Re: tests: safe MAPI init
Jon Griffiths <[EMAIL PROTECTED]> writes: >> the mapi32 tests call scInitMapiUtil, which pops up an alert >> box saying something like (translating it) "Your default >> mailer application isn't capable of this operation, please >> ensure that Outlook is configured as the default mailer." > > This probably means that you don't have a mapi client installed, I > guess that the default win32 stub mapi implementation just falls back > into 'advertise ms software' mode when this happens. Is this an early > Windows version by any chance? Windows XP Professional, in a network with roaming profiles served by Samba. I don't know what is relevant. > if you can, please run 'winedump spec mapi32.dll' and 'winedump spec > mapistub.dll' (if the latter exists) and send me the resulting .spec > file, It should be possible to skip the tests unless there is a mapi > client installed. OK, sending you off-list. >> As a side note, most of the mapi tests are very careful >> about calling every function through a pointer acquired by >> GetProcAddr(), > > Thats just precautionary, I could only test on xp and some > entrypoints are sure to not be present in earlier native versions. Well, test_PropCopyMore() has four direct references IIRC. You may or may not want to "fix" it (like the IMPORTS). The long for loop in test_ScCountProps(void) is probably an overkill, too: if it happens to produce output in every iteration, it gets too big. Currently there is a 1 MB limit on the report submission to test.winehq.org. -- Best wishes, Feri.
Re: Fix crash in dsound test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 19 July 2004 12:50, Ferenc Wagner wrote: > Can you (cross)build the directsound tests? Yes. http://www.astro.gla.ac.uk/users/paulm/wine/dsound_test-20040721.10-00.exe with md5sum of: 9ca9562675eb87f18f25a56c6c5a1341 dsound_test-20040721.10-00.exe HTH, Paul. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/4lC/9JwS78PA+kRAqKxAKC8xSKUkKE7tE5wQdbWDjmgEOQMuwCfVgLy PsBk0HWCIgJ3kJxxAlaA0MU= =egCL -END PGP SIGNATURE-
Re: daily wine cvs source snapshots?
Hi, On Thu, Jul 22, 2004 at 09:46:44AM +0200, Jeroen Janssen wrote: > Hello, > > I was wondering since: > > 1) wine uses CVS (and not svn with httpwebdav) and > 2) CVS doesn't go through the firewall at my work (and possible also not > for other people) SSH tunneling not possible either? > Would it be possible to have daily cvs snapshots (cvs export) of the wine > HEAD tree? Err... we've already been having that for a VERY long time ;-) http://lisas.de/~andi/wine_files/wine-cvs-hopefully-current.tar.bz2 (I thought that was mentioned at WineHQ? Not sure, though, especially with all those changes in the meantime...) Greetings, Andreas Mohr
tests: safe MAPI init
Hi (and sorry for the broken post), the mapi32 tests call scInitMapiUtil, which pops up an alert box saying something like (translating it) "Your default mailer application isn't capable of this operation, please ensure that Outlook is configured as the default mailer." This brings the tests to a halt, and even after clicking OK one gets 65536 failures bumping the logs above 5 MB. As a side note, most of the mapi tests are very careful about calling every function through a pointer acquired by GetProcAddr(), still the test executable is linked with -lmapi32. Does it make any sense? From winetest's perspective it isn't worth much, if a test can't run it's skipped altogether. Does it take care about different mapi versions? There are no recent reports on test.winehq.org/data, so something is obviously wrong. I'd be interested in hearing about people running Chris' winrash service. What happens if you run winetest directly? Don't forget to supply you tag with the -t option! Basically, winetest's own message boxes are OK, system message boxes are a problem. Thanks, Feri.
tests: safe MAPI init
Hi, the mapi32 tests call scInitMapiUtil, which pops up an alert box
daily wine cvs source snapshots?
Hello, I was wondering since: 1) wine uses CVS (and not svn with httpwebdav) and 2) CVS doesn't go through the firewall at my work (and possible also not for other people) Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree? This makes tracking the latest HEAD possible for people that can't use CVS to access the repository. I know that the CVS repository itself is available, but that sounds a bit overkill to me. best regards, Jeroen Janssen
Re: Add a WINEVER environment variable
Hi, I'm afraid I don't like the naming, since it's potentially confusing (plus, it somewhat goes against established rules, "WINE + function"). What about WINEWINVER instead? I for one like it much more. Also, this doesn't take into account that we're also able to set the DOS version. So what would that be called then? WINEVER, too? ;-) WINEWINVER and WINEDOSVER is a much better choice, IMHO. Greetings, Andreas
