January 2004 - Wine-Devel - list.winehq.org

RE: Will DCOM98 be pulled?

by Ove Kaaven

tor, 08.01.2004 kl. 12.52 skrev Mike Hearn: > On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote: > > Well, I've done about as much as I dared do without knowing exactly what > > plans you have. After all, widl can *not* link to oleaut32 since widl is > > not a Winelib app (and wasn't meant to be since someday we may want widl > > to generate some of the .c and .h files used by Wine DLLs such as > > oleaut32 at build time, instead of putting the generated files into > > CVS). My original plan was to use stdio to write typelibs straight from > > widl, not to use ICreateTypeLib. > > OK, I thought I'd CC this to Alexander so he realises this, I must admit > I had just assumed widl was a winelib app like all the others. Huh? None of the other programs in tools/ are Winelib either AFAIK. > To be honest, as we might one day have to implement ICreateTypeLib > anyway (and i think Alexander mentioned he wanted these for his own > project anyway), it seems like a lot of extra work to do this once in > widl and again in oleaut32. Is being able take generated files out of > CVS really that big a gain? We already ship quite a few (wineserver, > build system, idl->h) and it doesn't really cause problems. I'm just saying that wasn't what it was supposed to be. But nothing a little rewriting can't change if we don't care about circular dependencies I guess, though the common typelib library (which Robert Shearman mentioned) would also be a solution.

Jan. 8, 2004

Re: reading relay log

by Ferenc Wagner

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >>>>>> "Ferenc" == Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > > ... > Ferenc> kernel32.WaitForSingleObject(0000003c,ffffffff) ret=40593e4c [5 > > Somewhere before an CreateEvent Call with a return value > of 0000003c must happen. Look at that event and why it > doesn't trigger. You are right, there is. I create the event before forking off the dialog thread, which calls CreateDialog then SetEvent, which I didn't show you in the source snippets, only the Wait which you quoted. But I think it was not this Wait which timed out, but the tsx11_lock in CreateDialog. For me it seems XCreateDC does not return (the one I quoted from the Wine source). I mean, sometimes. Because the same program works now... I did not even recompile it, honest. I am going mad. Yesterday night it was 100% reproducible. Instead of this: 000a:Ret gdi32.GetObjectType() retval=00000003 ret=409ee125 000a:Call ntdll.RtlEnterCriticalSection(40a20700) ret=409fe8b0 000a:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=409fe8b0 trace:x11drv:X11DRV_CreateDC physDev=[I lost the number] err:ntdll:RtlpWaitForCriticalSection section 0x40334040 "?" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) now I get 000a:Ret gdi32.GetObjectType() retval=00000003 ret=409ee125 000a:Call ntdll.RtlEnterCriticalSection(40a20700) ret=409fe910 000a:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=409fe910 trace:x11drv:X11DRV_CreateDC physDev=0x40347ab8 trace:x11drv:X11DRV_CreateDC XCreateGC returned 0x101322a8 000a:Call ntdll.RtlLeaveCriticalSection(40a20700) ret=409fe934 000a:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=409fe934 000a:Ret x11drv.CreateDC() retval=00000001 ret=40899405 I've got the impression, that my network connection (remote X) is slower now, but not sure... Will see if it break again. Feri.

Jan. 8, 2004

Serial port under wine

by Paul Sheer

I am trying to write a simple serial port library that has the same lowest-common-denominator interface under both Windows and Linux. I developed it under wine using mingw32 - i want my apps that use it to work under both windows and linux (these are command-line apps only). i noticed that wine does not seem to report errors from GetOverLapped.. and Wait..Object in a way that makes sense. By ignoring errors, and just looking at the dwRead result, i got it to work. my attempt at a posix-like read function is below (the linux version follows further down) best wishes -paul --------- int serial_port_read (struct serial_port *p, unsigned char *buf, int buf_len, int milli_timeout) { static int c = 0; DWORD dwStart, dwRead, r; int l, total = 0; dwStart = GetTickCount (); while (buf_len > 0) { l = serial_port_chars_avail (p); if (l < 0) return total > 0 ? total : SERIAL_PORT_ERROR; if (l == 0 && GetTickCount () - dwStart >= milli_timeout) return total > 0 ? total : SERIAL_PORT_TIMEOUT; /* Like POSIX read(), we return without blocking if we have read at least one character: */ if (l == 0 && total >= 1) return total; /* Read minimum of one character, and a maximum of buf_len characters: */ CLIP (l, 1, buf_len); dwRead = 0; if (!ReadFile (p->hComm, buf, l, &dwRead, &p->osRead)) { if ((r = GetLastError ()) == ERROR_IO_PENDING) { dwRead = 0; GetOverlappedResult (p->hComm, &p->osRead, &dwRead, TRUE); } } total += dwRead; buf_len -= dwRead; buf += dwRead; } return total; } ------------ int serial_port_read (struct serial_port *p, unsigned char *buf, int buf_len, int milli_timeout) { int c; struct timeval tv; fd_set rd; if (!buf_len) return 0; FD_ZERO (&rd); FD_SET (p->fd, &rd); switch (select (p->fd + 1, &rd, NULL, NULL, milli_timeout < 0 ? NULL : (tv.tv_sec = milli_timeout / 1000, tv.tv_usec = milli_timeout % 1000, &tv))) { case 1: c = read (p->fd, buf, buf_len); if (!c) { p->error = 0; return SERIAL_PORT_HANGUP; } if (c < 0) { p->error = errno; return SERIAL_PORT_ERROR; } return c; case 0: return SERIAL_PORT_TIMEOUT; default: p->error = errno; return SERIAL_PORT_ERROR; } }

Jan. 8, 2004

RE: Will DCOM98 be pulled?

by Mike Hearn

On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote: > Well, I've done about as much as I dared do without knowing exactly what > plans you have. After all, widl can *not* link to oleaut32 since widl is > not a Winelib app (and wasn't meant to be since someday we may want widl > to generate some of the .c and .h files used by Wine DLLs such as > oleaut32 at build time, instead of putting the generated files into > CVS). My original plan was to use stdio to write typelibs straight from > widl, not to use ICreateTypeLib. OK, I thought I'd CC this to Alexander so he realises this, I must admit I had just assumed widl was a winelib app like all the others. To be honest, as we might one day have to implement ICreateTypeLib anyway (and i think Alexander mentioned he wanted these for his own project anyway), it seems like a lot of extra work to do this once in widl and again in oleaut32. Is being able take generated files out of CVS really that big a gain? We already ship quite a few (wineserver, build system, idl->h) and it doesn't really cause problems. thanks -mike

Jan. 8, 2004

Re: reading relay log

by Ferenc Wagner

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On January 7, 2004 09:19 pm, Ferenc Wagner wrote: > [...] > Sorry, it's almost 3:15am here, Not 9:19pm? We seem to be in sync then! From my post: >> Date: Thu, 08 Jan 2004 03:19:56 +0100 > why do you bother with multithread stuff? Is it really > necessary? I would be glad to drop it, but how can I keep serving messages while running the tests? Sorry for being dumb. Feri.

Jan. 8, 2004

Re: Mouse up vs Mouse click

by Rein Klazes

On Thu, 08 Jan 2004 11:23:56 +0100, you wrote: > Could somebody explain me (or direct me to info) how this should work > in general? I mean even on Windows, when is something a click and > when a down/up or down/click? I know that a too slow double-click will > be two separate clicks, but I'm uncertain about the down/up events. This is what I know of it: the translations happen in the PeekMessage/GetMessage calls. If you follow the logic in windows/message.c, you see that the raw hardware messages are processed several times, and that a simple hardware message like mouse button up or down can lead to several others. Not only clicks/double clicks but also WM_SETCURSOR, WM_PARENTNORIFY, WM_ACTIVATE* and other (especially hooks) message that may come with a mouse click are generated there. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 8, 2004

Re: Mouse up vs Mouse click

by Fabian Cenedese

At 14:15 19.12.2003 +0000, Mike Hearn wrote: >On Fri, 2003-12-19 at 14:01, Fabian Cenedese wrote: >> The control is a bit quirky with moving focus around and handling events >> specially. But still it works on Windows :) Now I'm a bit lost how I can >> debug this. +mouse didn't show anything usefull. I guess the >> generating and sending of the events is done in the wineserver. > >+event,+message is useful, look in dlls/x11drv/event.c for the >translation from X events to Win32 messages. The log messages were not that helpful, I know try to have a look at the source, but I need more knowledge. >I think I might have a similar bug to this in AVImark. Basically the bug >is to do with mouse events on context menus - in normal context menus >you get RMB down, RMB up, context menu appears. In this RichEdit >derivative, it goes: RMB down, context menu appears, user picks an >option, context menu disappears, RMB up, context menu appears again. Could somebody explain me (or direct me to info) how this should work in general? I mean even on Windows, when is something a click and when a down/up or down/click? I know that a too slow double-click will be two separate clicks, but I'm uncertain about the down/up events. Thanks bye Fabi

Jan. 8, 2004

www.winehq.org down?

by Michael Stefaniuc

Hello, is the www.winehq.org website down? The host is pingable and port 80 is open but i get no data after the initial tcp connect. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 8, 2004

Re: Problem with Access-mdb/DAO

by Fabian Cenedese

>>If you have a string like "Nodes", then the BSTR DWORD value should be >>5*sizeof(WCHAR) == 5*2 == 10, *NOT* 5. >> >>In other words, we don't have an even/odd division problem, but rather a >>problem with the string length, since it should have been twice as much. >> >>Please try to find out which function created that BSTR with this wrong >>length calculation and try to fix it. > >Actually that's a normal WINAPI function called SysAllocStringByteLen. >It's used in the DAO stuff from MFC. A COleVariant is created with >explicit type VT_BSTRT. This happens in the constructor: > >COleVariant::COleVariant(LPCTSTR lpszSrc, VARTYPE vtSrc) >{ > USES_CONVERSION; > ASSERT(vtSrc == VT_BSTR || vtSrc == VT_BSTRT); > UNUSED(vtSrc); > > vt = VT_BSTR; > bstrVal = NULL; > > if (lpszSrc != NULL) > { >#ifndef _UNICODE > if (vtSrc == VT_BSTRT) > { > int nLen = lstrlen(lpszSrc); > bstrVal = ::SysAllocStringByteLen(lpszSrc, nLen); > } > else >#endif > { > bstrVal = ::SysAllocString(T2COLE(lpszSrc)); > } > > if (bstrVal == NULL) > AfxThrowMemoryException(); > } >} > >So not every BSTR is really a wide char string. That's why MSDN says >that SysStringLen has to give back the allocated length if the BSTR >was created with SysAllocStringByteLen. > >I made a short test program: > >COleVariant v1; >VariantInit(&v1); >v1=COleVariant("Nodes", VT_BSTRT); >cout << SysStringLen(v1.bstrVal) << " " << (char*)v1.bstrVal << endl; > >Output on Windows: >2 Nodes > >Output on wine: >2 Node > >(And you're right, the SysStringLen is ok, reports also 2 on Windows). > >The SysAllocStringByteLen is ok, but the variant assignment is done >with VariantCopy which is definitely wrong. The source string is still >ok but the dest string is only "Node". But this function is above my >knowledge. I don't know if the allocation/copy is wrong or if it needs >a new case for these special non-WCHAR BSTRs. > >(Another interesting test: What happens with one-char-strings...?) Ok, I just tried and changed the code a bit. This now works with normal wide char strings as well as binary data (may as well be an ASCII string) with type BSTR. Though it works for me it may not be the right solution. bye Fabi Index: wine/dlls/oleaut32/variant.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/variant.c,v retrieving revision 1.83 diff -u -r1.83 variant.c --- wine/dlls/oleaut32/variant.c 6 Jan 2004 22:08:34 -0000 1.83 +++ wine/dlls/oleaut32/variant.c 8 Jan 2004 10:05:25 -0000 @@ -727,7 +727,7 @@ { if (V_BSTR(pvargSrc)) { - V_BSTR(pvargDest) = SysAllocStringLen(V_BSTR(pvargSrc), SysStringLen(V_BSTR(pvargSrc))); + V_BSTR(pvargDest) = SysAllocStringByteLen((char*)V_BSTR(pvargSrc), SysStringByteLen(V_BSTR(pvargSrc))); if (!V_BSTR(pvargDest)) hres = E_OUTOFMEMORY; }

Jan. 8, 2004

Re[2]: no keyboard events in ddraw application.

by Oleg Prokhorov

Hello Mike, Wednesday, January 7, 2004, 12:15:28 AM, you wrote: MH> I think the reason we make these windows unmanaged is because they don't MH> have window borders - if you can figure out a patch to allow them to be MH> managed that would go some way towards fixing this issue I think (though MH> fullscreened apps would still require some more work). Where could I look at to find how (unmanaged) window was created ? Specifically in my case i've got 2 Ddraw applications (games): one allows keyboard input but another fails. And no idea why does this happen. -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

Jan. 8, 2004

Re: reading relay log

by Uwe Bonnes

>>>>> "Ferenc" == Ferenc Wagner <wferi(a)afavant.elte.hu> writes: ... Ferenc> kernel32.WaitForSingleObject(0000003c,ffffffff) ret=40593e4c [5 Somewhere before an CreateEvent Call with a return value of 0000003c must happen. Look at that event and why it doesn't trigger. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 8, 2004

Re: reading relay log

by Dimitrie O. Paun

On January 7, 2004 09:19 pm, Ferenc Wagner wrote: > This multithread business is rather new for me, I would be > grateful for any insights. The cross-compiled version runs > on XP all right. Sorry, it's almost 3:15am here, I don't have time to look into it, but why do you bother with multithread stuff? Is it really necessary? -- Dimi.

Jan. 8, 2004

Re: Wineconf update, RFC re remote participation

by Dimitrie O. Paun

On January 7, 2004 08:46 pm, Jeremy White wrote: > p.s. If someone out there is thinking: of course you could do that, > if would be trivial if you just did 'X', please feel free to share X > with me. Otherwise, we'll have to investigate the open pbx project > and the possibility of getting some Quicknet cards... I remember getting all sorts of spam about very cheap conference calling. It can't be that expensive, we just set up a US number, the caller pays the long distance charges (which are very small right now)... -- Dimi.

Jan. 8, 2004

Re: MinGW cross compilation enviroment setup

by Dimitrie O. Paun

On January 7, 2004 08:05 pm, Michael Stefaniuc wrote: > The only thing i can imagine is that you have something different in > /usr/lib/rpm/. You can check that with: > (for i in /usr/lib/rpm/*; do rpm -qf $i; done) | sort | uniq > I get following output: > redhat-rpm-config-8.0.21-1 > rpm-4.2-0.69 > rpm-build-4.2-0.69 > rpm-devel-4.2-0.69 I'm getting this: [dimi(a)dimi lostwages]$ (for i in /usr/lib/rpm/*; do rpm -qf $i; done) | sort | uniq file /usr/lib/rpm/athlon-redhat-linux is not owned by any package file /usr/lib/rpm/i386-redhat-linux is not owned by any package file /usr/lib/rpm/i486-redhat-linux is not owned by any package file /usr/lib/rpm/i586-redhat-linux is not owned by any package file /usr/lib/rpm/i686-redhat-linux is not owned by any package rpm-4.2-0.69 rpm-build-4.2-0.69 rpm-devel-4.2-0.69 > By appending a " | xargs rpm -V" to the above command you can check if > files from the above rpms are unmodified. No output is good (that's what > i'm getting). I get this: ....L... /usr/lib/rpm/athlon-linux ....L... /usr/lib/rpm/i386-linux S.5..... /usr/lib/rpm/i386-linux/macros ....L... /usr/lib/rpm/i486-linux ....L... /usr/lib/rpm/i586-linux ....L... /usr/lib/rpm/i686-linux ....L... /usr/lib/rpm/noarch-linux -- Dimi.

Jan. 8, 2004

Re: Solaris compile time fixes for CVS wine

by Dimitrie O. Paun

On January 8, 2004 01:22 am, Robert Lunnon wrote: > Here are a buch of Solais compatibility patches for wine (Some but not all > of them). Within the enclosed tarball the diffs are structured according to > the wine cvs tree. There is a readme file accompanying each diff to explain > what the change is. Please break the archive into one patch per message, not compressed (preferably inlined). Here are a few pointers on how to send patches: http://www.winehq.org/site/sending_patches BTW, what's the status of building Wine under Solaris? What architecture (i386, etc) are you using? -- Dimi.

Jan. 8, 2004

More on "no keyboard events in ddraw application"

by Robert Glowczynski

Hello, I had the same problem as Oleg Prokhorov (no keyboard input in fullscreen games) and following patch fixed it (just a single line in Randr and XVid drivers). I do not know if something gets broken by it; I have tested it with Railroad Tycoon II demo. --- wine-20031212/dlls/x11drv/xvidmode.c.orig 2003-11-26 19:59:36.000000000 -0500 +++ wine-20031212/dlls/x11drv/xvidmode.c 2004-01-06 15:57:58.000000000 -0500 @@ -143,6 +143,7 @@ #else XWarpPointer(gdi_display, None, DefaultRootWindow(gdi_display), 0, 0, 0, 0, 0, 0); #endif + XSetInputFocus(gdi_display, DefaultRootWindow(gdi_display), RevertToPointerRoot, CurrentTime); XSync(gdi_display, False); wine_tsx11_unlock(); } --- wine-20031212/dlls/x11drv/xrandr.c.orig 2004-01-06 16:00:30.000000000 -0500 +++ wine-20031212/dlls/x11drv/xrandr.c 2004-01-06 16:00:10.000000000 -0500 @@ -174,6 +174,8 @@ { ERR("Resolution change not successful -- perhaps display has chaned?"); } + XSetInputFocus(gdi_display, DefaultRootWindow(gdi_display), RevertToPointerRoot, CurrentTime); + XRRFreeScreenConfigInfo(sc); wine_tsx11_unlock(); } Thank you for great work, wine developers! -- ::Robert Glowczynski ::email: robertg(a)aurox.org ::Aurox Core Team http://www.aurox.org ::http://www.distrowatch.com/table.php?distribution=aurox

Jan. 8, 2004

Re: reading relay log

by Ferenc Wagner

Mike, Uwe, thanks for the quick reply! Now I got to the end of X11DRV_CreateDC (TRACEs added by me): wine_tsx11_lock(); TRACE("physDev=%p\n", physDev); physDev->gc = XCreateGC( gdi_display, physDev->drawable, 0, NULL ); TRACE("XCreateGC returned %p\n", physDev->gc); XSetGraphicsExposures( gdi_display, physDev->gc, False ); XSetSubwindowMode( gdi_display, physDev->gc, IncludeInferiors ); XFlush( gdi_display ); wine_tsx11_unlock(); and --debugmsg +winetest,+dialog,+dc,+x11drv,+relay shows trace:dc:CreateDCW (driver=L"DISPLAY", device=(null), output=(null)): returning 0x7c 000a:Call x11drv.CreateDC(40347978,40347990,40def154 L"DISPLAY",00000000,00000000,00000000) ret=40899405 000a:Call ntdll.RtlAllocateHeap(40300000,00000008,0000008c) ret=409ee0e1 000a:Ret ntdll.RtlAllocateHeap() retval=40347ab8 ret=409ee0e1 000a:Call gdi32.GetObjectType(0000007c) ret=409ee125 000a:Call kernel32._EnterSysLevel(408cf340) ret=408a5547 000a:Ret kernel32._EnterSysLevel() retval=0000000c ret=408a5547 000a:Call kernel32._LeaveSysLevel(408cf340) ret=408a56e3 000a:Ret kernel32._LeaveSysLevel() retval=00000000 ret=408a56e3 000a:Ret gdi32.GetObjectType() retval=00000003 ret=409ee125 000a:Call ntdll.RtlEnterCriticalSection(40a20700) ret=409fe910 000a:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=409fe910 trace:x11drv:X11DRV_CreateDC physDev=0x40347ab8 0009:Ret kernel32.CreateThread() retval=00000040 ret=40593e07 trace:winetest:report thread 0x40 created 0009:Call kernel32.WaitForSingleObject(0000003c,ffffffff) ret=40593e4c [5 seconds of pause here] err:ntdll:RtlpWaitForCriticalSection section 0x40333ff8 "?" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) I am going to bed now, but can somebody advice me where to look further? To provide some context, the app goes like: DWORD WINAPI DlgThreadProc () { InitCommonControls (); dialog = CreateDialog (GetModuleHandle (NULL), MAKEINTRESOURCE (IDD_STATUS), NULL, DlgProc); [thread 000a is executing this CrateDialog call above] [...] } [and here is the main thread (0009)] DlgThread = CreateThread (NULL, 0, DlgThreadProc, NULL, 0, &DlgThreadID); WINE_TRACE ("thread %p created\n", DlgThread); ret = WaitForSingleObject (initEvent, INFINITE); This multithread business is rather new for me, I would be grateful for any insights. The cross-compiled version runs on XP all right. Feri.

Jan. 8, 2004

Re: Wineconf update, RFC re remote participation

by Jeremy White

> Telephone conversations are quite cheap nowadays (from Europe, they > cost are <$3/h!), what about a big conference call. You can break in, > ask questions, etc... That will work quite nicely with any sort of > telecast from the conference, me thinks. That's an interesting idea; it's conceivable that we could arrange such a service for a fairly limited number of callers, presuming those callers were willing to foot the bill for the call. I'm curious how many folks would really want to do that, though. Could I get a private show from folks that would want to do that? Thanks, Jer p.s. If someone out there is thinking: of course you could do that, if would be trivial if you just did 'X', please feel free to share X with me. Otherwise, we'll have to investigate the open pbx project and the possibility of getting some Quicknet cards...

Jan. 8, 2004

Re: MinGW cross compilation enviroment setup

by Michael Stefaniuc

On Wed, Jan 07, 2004 at 06:23:13PM -0500, Dimitrie O. Paun wrote: > On Wed, 7 Jan 2004, Michael Stefaniuc wrote: > > Here is my .rpmmacros file to be able to build rpms as normal user. You > > need to adapt the paths: > > %_topdir /home/mstefani/rpm > > %_tmppath /home/mstefani/rpm/INSTALL > > Thanks! > > > You need also to setup the %_topdir directory. Do following as user you > > want to build the rpms: > > mkdir -p $_topdir $_tmppath > > mkdir $_topdir/{BUILD,RPMS,SOURCES,SPECS,SRPMS} > > mkdir $_topdir/RPMS/{i386,i486,i586,i686,noarch,athlon} > > > > That should be all. > > Done, works like a charm, but I keep getting the same failure. Did you upgraded your box to RHL 9 or have you done a fresh install? Mine is a fresh install. The only thing i can imagine is that you have something different in /usr/lib/rpm/. You can check that with: (for i in /usr/lib/rpm/*; do rpm -qf $i; done) | sort | uniq I get following output: redhat-rpm-config-8.0.21-1 rpm-4.2-0.69 rpm-build-4.2-0.69 rpm-devel-4.2-0.69 By appending a " | xargs rpm -V" to the above command you can check if files from the above rpms are unmodified. No output is good (that's what i'm getting). > > If you can't build mingw as user too i can put the rpm (compiled for > > i386 or i686, i don't mind) on my people.redhat.com page. > > Yes, I'll take you up on the offer, for the mingw-3.0-1.src.rpm > package, if you can. ftp://people.redhat.com/mstefani/mingw-3.0-1.noarch.rpm MD5SUM: 6298f5cb4e8a1cac2701273db233dcfb bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 8, 2004

RE: Will DCOM98 be pulled?

by Ove Kaaven

man, 05.01.2004 kl. 14.34 skrev Mike Hearn: > On Mon, 05 Jan 2004 14:17:28 +0100, Ove Kaaven wrote: > > Nobody has yet added typelib stuff to widl, eh... I guess I could whip > > up a framework or something to help with that, since nobody else has yet > > done it... > > Actually, in the last 4 days I recruited somebody to hack on this from > IRC. He seems pretty competent and is currently implementing the > ICreateTypeLib[2] interfaces I think. Alexander (nyef), are you tracking > wine-devel yet? > > If you could work on the widl backend of course that'd be fantastic. I'm > still hoping to get back to properly submitting your DCOM/apartments work > soon, but I have 3 or 4 higher priority things on my todo list currently. Well, I've done about as much as I dared do without knowing exactly what plans you have. After all, widl can *not* link to oleaut32 since widl is not a Winelib app (and wasn't meant to be since someday we may want widl to generate some of the .c and .h files used by Wine DLLs such as oleaut32 at build time, instead of putting the generated files into CVS). My original plan was to use stdio to write typelibs straight from widl, not to use ICreateTypeLib.

Jan. 7, 2004

Re: MinGW cross compilation enviroment setup

by Dimitrie O. Paun

On Wed, 7 Jan 2004, Michael Stefaniuc wrote: > Here is my .rpmmacros file to be able to build rpms as normal user. You > need to adapt the paths: > %_topdir /home/mstefani/rpm > %_tmppath /home/mstefani/rpm/INSTALL Thanks! > You need also to setup the %_topdir directory. Do following as user you > want to build the rpms: > mkdir -p $_topdir $_tmppath > mkdir $_topdir/{BUILD,RPMS,SOURCES,SPECS,SRPMS} > mkdir $_topdir/RPMS/{i386,i486,i586,i686,noarch,athlon} > > That should be all. Done, works like a charm, but I keep getting the same failure. > hmm ... strange. My .rpmmacros is no more than what i pasted above and > my .rpmrc has only directives to build and optimize every package for > athlon. > If you can't build mingw as user too i can put the rpm (compiled for > i386 or i686, i don't mind) on my people.redhat.com page. Yes, I'll take you up on the offer, for the mingw-3.0-1.src.rpm package, if you can. > I hope you at least upgrade the box to the latest erratas ;) Hey, I'm not _that_ lazy! :) -- Dimi.

Jan. 7, 2004

Re: Wineconf update, RFC re remote participation

by Dimitrie O. Paun

On Wed, 7 Jan 2004, Eric Pouech wrote: > One of the things which improved was to have a couple of folks present > chatting on IRC at the same time (even, if it was not satisfactory to > break in and ask questions) Telephone conversations are quite cheap nowadays (from Europe, they cost are <$3/h!), what about a big conference call. You can break in, ask questions, etc... That will work quite nicely with any sort of telecast from the conference, me thinks. -- Dimi.

Jan. 7, 2004

RE: PATCH: Editing DLL overrides in winecfg

by Robert Shearman

> Let me get this straight: dll overrides specificy whether you want to > use the windows dll or wine dll, right? So, when you put it on "", this > is essentially the same as leaving the dll override out? No. Leaving the DLL override out will make Wine use the default override policy. Specifying "" means that Wine shouldn't load that library. In other words, a disable option. It is occasionally useful for setup programs, like the DCOM one that won't install if one of the Wine DLLs is present. > And how is "native" different from "native, builtin"? Will Wine refuse > to load the dll at all, when it's configured to use a native dll and it > cannot find one? Yes. > And do you really think the user should be troubled by having these 5 > options? After all, we wanted to keep winecfg simple, not complete, right? I think you could make it quite simple. Just have six options: o Use default override setting o Use Wine built-in always o Try loading Wine built-in first, then if not present, Windows native o Try Windows native first, then if not present Wine built-in o Use Windows native always o Disable this DLL Rob

Jan. 7, 2004

Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > In other words, by now most people have upgraded from 2.95.x. > Apparently Dave Miller claims 2.95.x is still desirable on > Sparc, but that's not that interesting for us. On the other > hand, being able to compile Wine with the PSDK brings real > value. I frankly think that being portable to various Unix compilers is of more value than building with the PSDK headers. I have nothing against adding hacks to enable both, but killing our Unix portability to support MSVC headers is not a good idea. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2004

Re: Task Manager for WINE and ReactOS

by Steven Edwards

--- Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: > I can send it again as stated before ;-))) > but why are you using a hosed mail box ? > A+ If you can resend I will merge the C++ -> C changes. Yahoo SPAM filtering used to suck and I think I might have clicked a delete rather than a "This is not pr0n, Viagra, Cheap Tickets, etc, Spam" button. It really has gotten quite better. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 7, 2004