October 2008 - Wine-Devel - list.winehq.org

Wineg++ and structured exception handling
by Michael Ost Oct. 15, 2008

Oct. 15, 2008

Hi, Is there a way for wineg++ to catch windows exceptions and handle them as g++ does --- cleaning up stack variables, etc? My C++ winelib app, built with wineg++, is loading Windows DLLs. I want to catch windows exceptions from functions that I call from those DLLs. I need to do some cleanup if there are exceptions, and tried creating some stack variables to manage that. I found __TRY and __CATCH in wine/exception.h. Wrapping the DLL function calls with __TRY and __CATCH does indeed catch exceptions, but there is no stack cleanup. There is some deep code in exception.h that implements __TRY/__CATCH (which I sure could be misreading) but they look more C like than C++ like... just taking care to jump to the right location without trying to do any cleanup. Window's c++ compiler evidently does that now, per this page: http://msdn.microsoft.com/en-us/library/7w0chfbk(VS.80).aspx I'm guessing I am out of luck here, but am hoping I'm just missing something. Thanks... mo

2 1

Re: advapi32: Fall back to /dev/random if /dev/urandom can't be opened, and add warnings if opening either fails
by Austin English Oct. 15, 2008

Oct. 15, 2008

On Wed, Oct 15, 2008 at 1:13 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Let me know if you think the fallback is a bad idea, or if a FIXME is > more appropriate than a WARN here. > --Juan > > > > FWIW: http://en.wikipedia.org/wiki/Urandom "/dev/random and /dev/urandom are also available on Solaris, Mac OS X, NetBSD, OpenBSD, Tru64 UNIX 5.1B, AIX 5.2, and HP-UX 11i v2, however as with FreeBSD, AIX implements its own Yarrow-based design which uses considerably less entropy sources than the standard /dev/random implementation and stops refilling the pool when it thinks it contains enough entropy.[2]" "A software program called EGD (entropy gathering daemon) is a common alternative for Unix systems which do not support the /dev/random device. It is a user space daemon which provides high quality cryptographic random data. Some cryptographic software such as OpenSSL, GNU Privacy Guard, and the Apache HTTP Server support using EGD when a /dev/random device is not available." -- -Austin

2 1

Re: wininet: quiet a noisy fixme
by Maarten Lankhorst Oct. 15, 2008

Oct. 15, 2008

I think this one can be better removed entirely, wine will never get support for dialup programs or other fancy ways to connect to the internet, so this fixme is useless.

1 0

Re: winex11.drv: Prevent XCreateIC from returning NULL when input style isn't "root". (try 3)
by Alexandre Julliard Oct. 15, 2008

Oct. 15, 2008

"Muneyuki Noguchi" <nogu.dev(a)gmail.com> writes: > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index e5a40aa..f58342b 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -701,6 +701,7 @@ struct x11drv_win_data > RECT whole_rect; /* X window rectangle for the whole window relative to parent */ > RECT client_rect; /* client area relative to parent */ > XIC xic; /* X input context */ > + XFontSet font_set; /* international text drawing font set */ > XWMHints *wm_hints; /* window manager hints */ > BOOL managed : 1; /* is window managed? */ > BOOL mapped : 1; /* is window mapped? (in either normal or iconic state) */ You shouldn't need to create a font set for each window, once per display should be enough. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: [user32: 2/2] Testcase for font size = 0x7fff
by Dan Kegel Oct. 15, 2008

Oct. 15, 2008

Koro wrote: > That is an *excellent* explanation. Everything becomes > clear now, and indeed this should be documented somewhere > (except I can't find how to edit the wiki without making an account). That's because you need an account. (Otherwise there's too much spam. Accounts are free.) > Maybe somebody could wikify it for me? Done: http://wiki.winehq.org/Developers-Hints#head-8494fa344a35867c68b6bdd5e6256e… > if somebody wants to take up the project, I guess I > could release parts of the source (namely, the API > emulation and the layout / reflow code) under a very > specific can't-distribute-but-can-be-used-for-WINE > license. ... [That is,} > I'd give the necessary raw code for integration into > WINE (it'd have to be modified a lot), but once it gets > into WINE, it's WINE code and goes by the WINE license. > And therefore, if somebody wants to take that BACK > from WINE, and make their own TDEmu.dll, or anything > else for that matter, I don't care at all. I think we could live with that. It would be more convenient if you could right away place the code you send us under the LGPL, but either way is ok. Just send me the code along with either "I hereby release this code under the LGPL" or "I hereby release this code, as it is when it is finally merged into Wine, under the LGPL." - Dan

1 0

SourceForge community awards ... we won ... ;)
by Marcus Meissner Oct. 15, 2008

Oct. 15, 2008

Hi, We won in the SourceForge.net2008 Community Choice Awards https://sourceforge.net/community/cca08/ in the Category: "Most Likely to Be Ambiguously and Baselessly Accused of Patent Violation" :) Ciao, Marcus

3 2

Patchwatcher is watching lostwages patches
by Scott Ritchie Oct. 15, 2008

Oct. 15, 2008

Just a small bug, but patchwatcher is complaining about my lostwages patch not applying. Thanks, Scott Ritchie

2 1

Re: rpcrt4(2/2): Use pseudo-random numbers to generate UUIDs rather than using the (old, deprecated) MAC-address-and-time generation algorithm
by Alexandre Julliard Oct. 15, 2008

Oct. 15, 2008

"Juan Lang" <juan.lang(a)gmail.com> writes: > This unfortunately causes test failures in quartz. I strongly suspect > the failures are spurious, because I'm pretty confident my tests show > that this change is correct, but I don't know enough about quartz to > know the cause. > --Juan > > From cf9fc613c3cff0cd258e42123cb7eb5dc66c1610 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Mon, 13 Oct 2008 13:08:17 -0700 > Subject: [PATCH] Use pseudo-random numbers to generate UUIDs rather than using the (old, > deprecated) MAC-address-and-time generation algorithm The change is OK but you'll want to flesh out RtlGenRandom first, currently it will fail pretty badly if /dev/urandom isn't available. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Kernel32: 3GB UserSpace boot option
by Dmitry Timoshkov Oct. 15, 2008

Oct. 15, 2008

You still need to prove the second part of your claims. Please don't omit wine-devel from the cc: list. [I'm intentionally top posting so that you caould see why it's bad] "Stefan Reimer" <lists(a)startux.de> wrote: > Yeap I did, see: > > quark(a)quarks ~ $ winedump .wine/drive_c/Program\ Files/Sony/EverQuest\ > II/EverQuest2.exe > Contents of .wine/drive_c/Program Files/Sony/EverQuest II/EverQuest2.exe: > 12918784 bytes > > File Header > Machine: 014C (i386) > Number of Sections: 6 > TimeDateStamp: 48EF93D1 (Fri Oct 10 19:41:37 2008) offset > 336 > PointerToSymbolTable: 00000000 > NumberOfSymbols: 00000000 > SizeOfOptionalHeader: 00E0 > Characteristics: 012E > EXECUTABLE_IMAGE > LINE_NUMS_STRIPPED > LOCAL_SYMS_STRIPPED > LARGE_ADDRESS_AWARE > 32BIT_MACHINE > > .... > > Done dumping .wine/drive_c/Program Files/Sony/EverQuest II/EverQuest2.exe > > > "Stefan Reimer" <lists(a)startux.de> wrote: > > > >> The EQ2 binary is large address aware. > >> > >> Windows changes it upper most user space address from 0x7FFEFFFF to > >> 0xBFFEFFFF booting with /3GB and this is not possible in wine right now > >> as > >> I think. > > > > Did you really check that? -- Dmitry.

1 0

Re: [user32: 2/2] Testcase for font size = 0x7fff
by Dmitry Timoshkov Oct. 15, 2008

Oct. 15, 2008

"Koro" <webmaster(a)korosoft.net> wrote: > +static INT_PTR CALLBACK messageBoxFontDlgWinProc (HWND hDlg, UINT uiMsg, WPARAM wParam, > + LPARAM lParam) > +{ > + return (uiMsg == WM_INITDIALOG); > +} > + > +static void test_MessageBoxFontTest(void) > +{ > + /* Define a dialog that sets 0x7fff as font, and define one control. If the > + * dialog is created correctly, it means the 0x7fff was skipped correctly. */ > + > + static unsigned char test[] = > + { > + /* Dialog header */ > + 0x01,0x00, /* Version */ > + 0xff,0xff, /* Extended template marker */ > + 0x00,0x00,0x00,0x00, /* Context Help ID */ > + 0x00,0x00,0x00,0x00, /* Extended style */ > + 0xc0,0x00,0xc8,0x80, /* Style (WS_SYSMENU|WS_CAPTION|WS_POPUP|DS_SETFONT|DS_MODALFRAME) */ > + 0x01,0x00, /* Control count */ > + 0x00,0x00, /* X */ > + 0x00,0x00, /* Y */ > + 0x80,0x00, /* Width */ > + 0x80,0x00, /* Height */ > + 0x00,0x00, /* Menu name */ > + 0x00,0x00, /* Class name */ > + 'T',0x00,'e',0x00, /* Caption (unicode) */ > + 's',0x00,'t',0x00, > + 0x00,0x00, > + 0xff,0x7f, /* Font height (0x7fff = message box font) */ > + > + /* Control #1 */ > + 0x00,0x00, /* Align to DWORD (header is 42 bytes) */ > + 0x00,0x00,0x00,0x00, /* Context Help ID */ > + 0x00,0x00,0x00,0x00, /* Extended style */ > + 0x00,0x00,0x00,0x50, /* Style (WS_CHILD|WS_VISIBLE) */ > + 0x00,0x00, /* X */ > + 0x00,0x00, /* Y */ > + 0x80,0x00, /* Width */ > + 0x80,0x00, /* Height */ > + 0xff,0xff,0xff,0xff, /* Control ID */ > + 0xff,0xff,0x82,0x00, /* Class (Static) */ > + 'W',0x00,'I',0x00, /* Caption (unicode) */ > + 'N',0x00,'E',0x00, > + ' ',0x00,'d',0x00, > + 'i',0x00,'a',0x00, > + 'l',0x00,'o',0x00, > + 'g',0x00,' ',0x00, > + 't',0x00,'e',0x00, > + 's',0x00,'t',0x00, > + '.',0x00,0x00,0x00, > + 0x00,0x00, /* Size of extended data */ > + > + 0x00,0x00 /* Align to DWORD */ > + }; > + > + /* Now check if it can be created */ > + HWND hdlg = CreateDialogIndirectParam(g_hinst, (LPCDLGTEMPLATE)test, NULL, messageBoxFontDlgWinProc, 0); > + > + broken(hdlg == NULL); Is there a Windows version where CreateDialogIndirectParam fails? > + if (hdlg) > + ok(IsWindow(hdlg), "dialog with message box font was successfully created"); What exactly this code is supposed to test? So far it doesn't test anything related to the font size. -- Dmitry.

9 18