December 2006 - Wine-Devel - list.winehq.org

Re: d3d [2]: Optional callback infrastructure for implicit texture surface destruction.

by H. Verbeet

On 03/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > --- > dlls/wined3d/texture.c | 53 > +++++++++++++++++++++++--------------- > include/wine/wined3d_interface.h | 7 +++++ > 2 files changed, 39 insertions(+), 21 deletions(-) I think the callback should be non-optional.

Dec. 3, 2006

winedump: Cast-qual warnings fix (2 of 2)

by Andrew Talbot

Sorry, I made a mess of titling this patch, twice. Please find and use the version whose subject line and changelog entry refer to "winedump", not "winedbg". Thanks, -- Andy.

Dec. 3, 2006

[PATCH] overflow checking for MultiByteToWideChar/WideCharToMultiByte

by Marcus Meissner

Hi, This is more a FYI patch and GCC 4.0+ specific. This enhancement detects if the size of a known buffer is different than the specified size. Thie tests/sock.c adjustement is necessary due to stdlib.h inclusion. Ciao, Marcus --- dlls/kernel32/locale.c | 2 ++ dlls/ws2_32/tests/sock.c | 2 +- include/winnls.h | 45 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 1 deletions(-) d0e7840335b6bbe4990b1c043dcff9b298c7a5a8 diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c index bc7db75..1d4ceaf 100644 --- a/dlls/kernel32/locale.c +++ b/dlls/kernel32/locale.c @@ -1757,6 +1757,7 @@ BOOL WINAPI EnumSystemCodePagesW( CODEPA * is passed, and ERROR_NO_UNICODE_TRANSLATION if no translation is * possible for src. */ +#undef MultiByteToWideChar INT WINAPI MultiByteToWideChar( UINT page, DWORD flags, LPCSTR src, INT srclen, LPWSTR dst, INT dstlen ) { @@ -1850,6 +1851,7 @@ INT WINAPI MultiByteToWideChar( UINT pag * and dstlen != 0, and ERROR_INVALID_PARAMETER, if an invalid * parameter was given. */ +#undef WideCharToMultiByte INT WINAPI WideCharToMultiByte( UINT page, DWORD flags, LPCWSTR src, INT srclen, LPSTR dst, INT dstlen, LPCSTR defchar, BOOL *used ) { diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c index c8b9cc8..f5ed0c1 100644 --- a/dlls/ws2_32/tests/sock.c +++ b/dlls/ws2_32/tests/sock.c @@ -22,8 +22,8 @@ #include <stdarg.h> #include <windef.h> -#include <winbase.h> #include <winsock2.h> +#include <winbase.h> #include <mswsock.h> #include "wine/test.h" #include <winnt.h> diff --git a/include/winnls.h b/include/winnls.h index 8888171..c13c0bf 100644 --- a/include/winnls.h +++ b/include/winnls.h @@ -20,6 +20,10 @@ #define __WINE_WINNLS_H #ifndef NONLS +#ifndef RC_INVOKED +# include <stdlib.h> +#endif + #ifdef __cplusplus extern "C" { #endif @@ -768,6 +772,26 @@ INT WINAPI LCMapStringW(LCID,DWO #define LCMapString WINELIB_NAME_AW(LCMapString) LCID WINAPI LocaleNameToLCID(LPCWSTR,DWORD); INT WINAPI MultiByteToWideChar(UINT,DWORD,LPCSTR,INT,LPWSTR,INT); + +static inline INT +WINAPI MultiByteToWideChar_ichk( + UINT cp,DWORD flags, + LPCSTR src,INT srclen,INT srcbuflen, + LPWSTR dst,INT dstlen,INT dstbuflen +) { + if ((srclen != -1) && (srcbuflen != -1) && (srcbuflen < srclen)) + abort(); + if ((dstlen != -1) && (dstbuflen != -1) && (dstbuflen/2 < dstlen)) + abort(); + /* later add assertions regarding conversion lengths */ + return MultiByteToWideChar(cp,flags,src,srclen,dst,dstlen); +} +#define MultiByteToWideChar(cp,flags,src,srclen,dst,dstlen) \ + MultiByteToWideChar_ichk(cp,flags, \ + src,srclen,__builtin_object_size(src,0), \ + dst,dstlen,__builtin_object_size(dst,0) \ + ) + INT WINAPI SetCalendarInfoA(LCID,CALID,CALTYPE,LPCSTR); INT WINAPI SetCalendarInfoW(LCID,CALID,CALTYPE,LPCWSTR); #define SetCalendarInfo WINELIB_NAME_AW(SetCalendarInfo) @@ -778,6 +802,27 @@ BOOL WINAPI SetThreadLocale(LCID) BOOL WINAPI SetUserGeoID(GEOID); INT WINAPI WideCharToMultiByte(UINT,DWORD,LPCWSTR,INT,LPSTR,INT,LPCSTR,LPBOOL); +static inline INT +WINAPI WideCharToMultiByte_ichk( + UINT cp,DWORD flags, + LPCWSTR src,INT srclen,INT srcbuflen, + LPSTR dst,INT dstlen,INT dstbuflen, + LPCSTR xstr,LPBOOL b +) { + if ((srclen != -1) && (srcbuflen != -1) && (srcbuflen/2 < srclen)) + abort(); + if ((dstlen != -1) && (dstbuflen != -1) && (dstbuflen < dstlen)) + abort(); + /* later add assertions regarding conversion lengths */ + return WideCharToMultiByte(cp,flags,src,srclen,dst,dstlen,xstr,b); +} +#define WideCharToMultiByte(cp,flags,src,srclen,dst,dstlen,defchar,b) \ + WideCharToMultiByte_ichk(cp,flags, \ + src,srclen,__builtin_object_size(src,0), \ + dst,dstlen,__builtin_object_size(dst,0), \ + defchar,b \ + ) + #ifdef __cplusplus } #endif -- 1.2.4

Dec. 3, 2006

Re: [PATCH] check length in path canonicalize

by Dmitry Timoshkov

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > - MultiByteToWideChar(CP_ACP,0,lpszPath,-1,szPath,MAX_PATH); > + INT ret; > + > + ret = MultiByteToWideChar(CP_ACP,0,lpszPath,-1,NULL,0); > + if (ret > MAX_PATH) { > + FIXME("Too long path!\n"); > + return FALSE; > + } > + ret = MultiByteToWideChar(CP_ACP,0,lpszPath,-1,szPath,sizeof(szPath)/sizeof(WCHAR)); It should be sufficient to check return value of MultiByteToWideChar to detect an overflow, there is no need to call MultiByteToWideChar twice for that. -- Dmitry.

Dec. 3, 2006

Re: XEMBED Implementation

by Mike McCormack

Cloudor Pu wrote: > Now, how can I get X11 window id by HWND in my program? I saw a patch > GetX11WindowId at > http://www.mail-archive.com/wine-devel(a)winehq.com/msg05282.html > But this cannot be found in the latest wine. Can I get xwindow id by > HWND without patching wine? Only top level (managed) windows have an X window ID. You can see how Wine manages HWND -> X Window mappings in dlls/winex11.drv/window.c in the function X11DRV_get_whole_window(). This is likely subject to change... Mike

Dec. 3, 2006

Re: XEMBED Implementation

by Cloudor Pu

Hi, Thank you. I just found an example that can embed any X window into gtk by calling gtk_socket_add_id(). And I can embed that IE window if I use xwininfo to get it's X11 window id. Now, how can I get X11 window id by HWND in my program? I saw a patch GetX11WindowId at http://www.mail-archive.com/wine-devel(a)winehq.com/msg05282.html But this cannot be found in the latest wine. Can I get xwindow id by HWND without patching wine? regards, cloudor Roderick Colenbrander wrote: > Hi, > > The XEMBED stuff in Wine is different than what you need. This code is inside wine's x11 driver and has the purpose of integrating the Wine system tray with KDE/Gnome. It is for internal wine usage and can't be used for your purpose. > > You could search for the kde reaktivate project. It was designed for embedding windows activex controls through Wine in Konqueror. I'm not sure how they are embedding wine stuff, it might help. > > Regards, > Roderick > >> Hi, >> >> I find discussion about XEMBED implementation in this mailing list and >> that was 3 years ago. Is there now any usable implementation or examples >> for wine XEMBED plug? >> >> What I am doing is to embed IE into a GtkSocket. I wrote a standalone >> program compiled using winelib that can CreateWindow and embed IE. Can I >> CreateWindow using the XEMBED Id if there is already XEMBED >> implementation or can I just CreateWindow as a child of a GtkPlug which >> is a gtk-embeddee? >> >> Any advices or suggestions would be highly appreciated. Thank you! >> >> Regards, >> cloudor >> >> >

Dec. 3, 2006

Re: Wined3d State management again

by Stefan Dösinger

Amorphous made me aware that git can do a full diff against 2 branches, so I have a single big diff attached now :-) > Hi, > I've done some more work on my state management, and I uploaded an updated > patch to http://stud4.tuwien.ac.at/~e0526822/wined3d-statemgmt-2.tar.bz2 . > > Ok, so what's updated: > * Pixel shaders: Should work now > * GLSL shaders: Working too. Henris shader backend stuff is integrated in a > messy way. > * Offscreen rendering: Works with back buffer and pbuffer rendering, fbos > not yet. > * Stateblocks: Brute force integration by just scheduling all modified > states for a reset. No display list yet > * Blitting, render target unlocking: Enabled again, sets new gl states and > schedules a reapplication of the modified states. Not a nice solution yet > > What is still missing: > * Nv register combiners. I haven't found a way yet to build a texture stage > -> texture unit mapping which I like. All the ways I could think of could > potentially cause lots of unneccessary state changes. > > One nice thing I have noticed is that this changes give a huge performance > gain in Half-Life 2(dxlevel 80, and 90). Dxlevel 80 is accelerated to > approximately 150-200% of the former performance, and especially slow parts > are faster now. This makes a really huge playability difference :-) > > There are some regressions too, especially related to texture > loading(3Dmark2000), and some glsl crashes. The good part about this change > is that I can send it in in very small patches, making regression testing > much easier, contrary to the huge ddraw rewrite. > > Where to go from here? As long as nobody screams I'd start sending patches > now. Its easier to catch regressions while sending small patches instead of > hunting them on the blob I have here(and my messy patch history in my git > tree). I'm also afraid that I get too far away from the main wined3d > code(See the shader backend integration). We can discuss the code based on > the small changes I'll send. > > Stefan

Dec. 2, 2006

Re: One more go at fixing GetCursorPos()

by Stefan Dösinger

Am Mittwoch 29 November 2006 19:51 schrieb Vitaliy Margolen: I gave your patch and test apps a try, and it seems to work fine here :-) > test_msg.c - tests major problem that Alexandre pointed out about last > fix attempt. Application in question does not process messages while > calling GetCursorPos(). It still works properly with proposed patch. Seems to work. It writes out relative mouse movement on the console and terminates after a while(well, the while loop). It works too with the current wine git code, but as I understand it that is ok - You want to show that it still works after your change. > di_mouse_2th.c - 2 threads showing that there are no extra thread local > position involved (if there is such a thing). Cached cursor position is > global to all threads. (Last numbers should stay at dt(0 0) at all > times). Inside hook handler d(x y) should show relative mouse move > delta. Writes out a bunch of output like that: Hook: code=0 w=200 [(136 125) 0 0 0] cur(142 129) d(-6 -4) Th: (142 129) dt(0 0) Hook: code=0 w=200 [(128 121) 0 0 0] cur(136 125) d(-8 -4) Th: (136 125) dt(0 0) Hook: code=0 w=200 [(114 119) 0 0 0] cur(128 121) d(-14 -2) Th: (128 121) dt(0 0) Hook: code=0 w=200 [(100 119) 0 0 0] cur(114 119) d(-14 0) Th: (114 119) dt(0 0) Hook: code=0 w=200 [(88 119) 0 0 0] cur(100 119) d(-12 0) Th: (100 119) dt(0 0) Hook: code=0 w=200 [(78 119) 0 0 0] cur(88 119) d(-10 0) Th: (88 119) dt(0 0) Hook: code=0 w=200 [(77 120) 0 0 0] cur(78 119) d(-1 1) Th: (78 119) dt(0 0) Hook: code=0 w=200 [(81 116) 0 0 0] cur(77 120) d(4 -4) Th: (77 120) dt(0 0) Hook: code=0 w=200 [(85 110) 0 0 0] cur(81 116) d(4 -6) Th: (81 116) dt(0 0) Hook: code=0 w=200 [(86 108) 0 0 0] cur(85 110) d(1 -2) Th: (85 110) dt(0 0) Hook: code=0 w=200 [(86 106) 0 0 0] cur(86 108) d(0 -2) Th: (86 108) dt(0 0) Hook: code=0 w=200 [(82 102) 0 0 0] cur(86 106) d(-4 -4) Th: (86 106) dt(0 0) Hook: code=0 w=200 [(81 101) 0 0 0] cur(82 102) d(-1 -1) Th: (82 102) dt(0 0) Hook: code=0 w=200 [(73 97) 0 0 0] cur(81 101) d(-8 -4) Th: (81 101) dt(0 0) Hook: code=0 w=200 [(65 97) 0 0 0] cur(73 97) d(-8 0) Th: (73 97) dt(0 0) Hook: code=0 w=200 [(57 97) 0 0 0] cur(65 97) d(-8 0) Th: (65 97) dt(0 0) Hook: code=0 w=200 [(47 99) 0 0 0] cur(57 97) d(-10 2) Th: (57 97) dt(0 0) Hook: code=0 w=200 [(43 103) 0 0 0] cur(47 99) d(-4 4) Th: (47 99) dt(0 0) Hook: code=0 w=200 [(43 105) 0 0 0] cur(43 103) d(0 2) Th: (43 103) dt(0 0) I will run both apps on windows(xp sp2) and compare the output. > If anyone has any objections, comment, suggestions, please do send them. Not really, my knowledge about the input code is too limited to give a qualified comment:-( Stefan

Dec. 2, 2006

Re: make check_no_exec() work reliable

by Peter Beutner

Alexandre Julliard wrote: > Peter Beutner <p.beutner(a)gmx.net> writes: > >> Why should this exception be visible to the application? >> Plus if you make it visible, you can just forget this whole workaround idea, >> because it won't work reliable anyways. > > Well, yes, the workaround is really a hack that should be replaced by > a proper fix; I was hoping it would encourage someone to look into it > and fix it properly, I can't do it because my box doesn't have noexec > support. > >> Certainly some more testing on windows is needed, but this >> check_no_exec() workaround was regardless introduced a long time ago. >> This patch just fixes this workaround. >> Otherwise it could as well be removed at all. > > Well, yes, it could certainly be removed; I added it mostly to make > sure that we generated the exception properly, and to demonstrate how > the exception can be handled. The proper fix is clearly more complex > than that, but moving that hack into the exception code isn't a step > in the right direction IMO. > hm, at least for that message box that was talked about, I don't see another choice than to put it into the exception code. But that probably should then only be the message box (and maybe a possibility to change the noexecute configuration for this app) and no code for trying to workaround the protection. I also took a closer look on the windows behaviour. There is no (at least application visible) difference in how the memory areas(heap, stack,valloc,image) are mapped between NX disabled/enabled mode. (Apart from the mysterious fact that a bunch of more dlls are loaded when it is disabled.) The only difference is whether code runs from non-executable memory or not. I'll attach the output of a small testcase I've written which shows the memory layout for both cases. There is however one exception. If the noexecute policy is set to OptOut[1] and windows loads a PE file where the AddressEntryPoint is in a non-executable section, NX protection is automatically switched off for this process. According to some paper[2] there are even more specific compatibility checks, e.g. for the safedisc driver. Sadly MS just speaks of "System compatibility fixes" without further detailed explanation :/ But as linux can't just switch on/off the protection for specific processes, wine has to emulate it by marking all readable memory as executable as well. And as all this happens behind the application's back, I would still go with my first proposal to just pair every PROT_READ with a PROT_EXEC in dlls/ntdll/virtual.c:VIRTUAL_GetUnixProt(). Does that sound acceptable? 1) means: apply protection for all apps, but allow to disable it for specific apps 2) http://www.uninformed.org/?v=2&a=4 run tests: execute on stack: failed execute on .rodata: failed execute on .data: failed execute on heap: failed execute on valloc: failed ----------------------------------------------- dump memory info: 0x00010000 - 0x00011fff -rw- private 0x00020000 - 0x00020fff -rw- private 0x0022d000 - 0x0022dfff grw- private 0x0022e000 - 0x0022ffff -rw- private (stack) 0x00230000 - 0x00232fff -r-- mapped 0x00240000 - 0x00243fff -rw- private (heap) 0x00340000 - 0x00345fff -rw- private 0x00350000 - 0x00352fff -rw- mapped 0x00360000 - 0x00375fff -r-- mapped 0x00380000 - 0x003bcfff -r-- mapped 0x003c0000 - 0x003c5fff -r-- mapped 0x003d0000 - 0x003d5fff -rw- private 0x003e0000 - 0x003e2fff -r-- mapped 0x003f0000 - 0x003f0fff -rwe private 0x00400000 - 0x00400fff -r-- image file: test_mem.exe (400000 - 408000) 0x00401000 - 0x00403fff -r-e image section: .text flags: r-x CODE 0x00404000 - 0x00404fff -rw- image section: .data flags: rw- DATA 0x00405000 - 0x00405fff -r-- image section: .rdata flags: r-- DATA 0x00406000 - 0x00407fff -rw- image section: .bss flags: rw- BSS 0x00410000 - 0x00450fff -r-- mapped 0x00460000 - 0x00460fff -rw- private (valloc) 0x77be0000 - 0x77be0fff -r-- image file: msvcrt.dll (77be0000 - 77c38000) 0x77be1000 - 0x77c2cfff -r-e image section: .text flags: r-x CODE 0x77c2d000 - 0x77c2efff -rw- image section: .data flags: rw- DATA 0x77c2f000 - 0x77c2ffff -rw- image section: .data flags: rw- DATA 0x77c30000 - 0x77c30fff -rw- image section: .data flags: rw- DATA 0x77c31000 - 0x77c33fff -rw- image section: .data flags: rw- DATA 0x77c34000 - 0x77c37fff -r-- image section: .rsrc flags: r-- DATA 0x7c800000 - 0x7c800fff -r-- image file: kernel32.dll (7c800000 - 7c906000) 0x7c801000 - 0x7c882fff -r-e image section: .text flags: r-x CODE 0x7c883000 - 0x7c885fff -rw- image section: .data flags: rw- DATA 0x7c886000 - 0x7c887fff -rw- image section: .data flags: rw- DATA 0x7c888000 - 0x7c905fff -r-- image section: .rsrc flags: r-- DATA 0x7c910000 - 0x7c910fff -r-- image file: ntdll.dll (7c910000 - 7c9c7000) 0x7c911000 - 0x7c98bfff -r-e image section: .text flags: r-x CODE 0x7c98c000 - 0x7c98efff -rw- image section: .data flags: rw- DATA 0x7c98f000 - 0x7c990fff -rw- image section: .data flags: rw- DATA 0x7c991000 - 0x7c9c6fff -r-- image section: .rsrc flags: r-- DATA 0x7f6f0000 - 0x7f6f6fff -r-e mapped 0x7ffb0000 - 0x7ffd3fff -r-- mapped 0x7ffdc000 - 0x7ffdcfff -rw- private 0x7ffdf000 - 0x7ffdffff -rw- private 0x7ffe0000 - 0x7ffe0fff -r-- private run tests: execute on stack: succeeded execute on .rodata: succeeded execute on .data: succeeded execute on heap: succeeded execute on valloc: succeeded ----------------------------------------------- dump memory info: 0x00010000 - 0x00011fff -rw- private 0x00020000 - 0x00020fff -rw- private 0x00030000 - 0x00036fff -rw- private 0x0023c000 - 0x0023cfff grw- private 0x0023d000 - 0x0023ffff -rw- private (stack) 0x00240000 - 0x00242fff -r-- mapped 0x00250000 - 0x00259fff -rw- private (heap) 0x00350000 - 0x00355fff -rw- private 0x00360000 - 0x00362fff -rw- mapped 0x00370000 - 0x00385fff -r-- mapped 0x00390000 - 0x003ccfff -r-- mapped 0x003d0000 - 0x003d5fff -r-- mapped 0x003e0000 - 0x003e7fff -rw- private 0x003f0000 - 0x003f3fff -rw- private 0x00400000 - 0x00400fff -r-- image file: test_mem.exe (400000 - 408000) 0x00401000 - 0x00403fff -r-e image section: .text flags: r-x CODE 0x00404000 - 0x00404fff -rw- image section: .data flags: rw- DATA 0x00405000 - 0x00405fff -r-- image section: .rdata flags: r-- DATA 0x00406000 - 0x00407fff -rw- image section: .bss flags: rw- BSS 0x00410000 - 0x00450fff -r-- mapped 0x00460000 - 0x00461fff -r-e mapped 0x00520000 - 0x00521fff -r-e mapped 0x00530000 - 0x00530fff -rw- private 0x00540000 - 0x00540fff -rw- private 0x00550000 - 0x00551fff -r-- mapped 0x00560000 - 0x00563fff -rw- private 0x00570000 - 0x00571fff -r-- mapped 0x00580000 - 0x00580fff -rwe private 0x00590000 - 0x00592fff -r-- mapped 0x005a0000 - 0x005a2fff -rw- private 0x005e0000 - 0x006e2fff -r-- mapped 0x006f0000 - 0x0073cfff -r-e mapped 0x009f0000 - 0x009f0fff -rw- private 0x00a70000 - 0x00a70fff -rw- private (valloc) 0x5b0f0000 - 0x5b0f0fff -r-- image file: UxTheme.dll (5b0f0000 - 5b128000) 0x5b0f1000 - 0x5b120fff -r-e image section: .text flags: r-x CODE 0x5b121000 - 0x5b121fff -rw- image section: .data flags: rw- DATA 0x5b122000 - 0x5b127fff -r-- image section: .rsrc flags: r-- DATA 0x5cf00000 - 0x5cf00fff -r-- image file: ShimEng.dll (5cf00000 - 5cf26000) 0x5cf01000 - 0x5cf0efff -r-e image section: .text flags: r-x CODE 0x5cf0f000 - 0x5cf11fff -rw- image section: .data flags: rw- DATA 0x5cf12000 - 0x5cf21fff -rw- image section: .data flags: rw- DATA 0x5cf22000 - 0x5cf22fff -rw- image section: .data flags: rw- DATA 0x5cf23000 - 0x5cf25fff -r-- image section: .rsrc flags: r-- DATA 0x5d450000 - 0x5d450fff -r-- image file: comctl32.dll (5d450000 - 5d4e7000) 0x5d451000 - 0x5d4c0fff -r-e image section: .text flags: r-x CODE 0x5d4c1000 - 0x5d4c2fff -rw- image section: .data flags: rw- DATA 0x5d4c3000 - 0x5d4c3fff -rw- image section: .data flags: rw- DATA 0x5d4c4000 - 0x5d4e6fff -r-- image section: .rsrc flags: r-- DATA 0x6fd90000 - 0x6fd90fff -r-- image file: AcGenral.DLL (6fd90000 - 6ff5a000) 0x6fd91000 - 0x6fdc2fff -r-e image section: .text flags: r-x CODE 0x6fdc3000 - 0x6fdc3fff -rw- image section: .data flags: rw- DATA 0x6fdc4000 - 0x6fdc7fff -rw- image section: .data flags: rw- DATA 0x6fdc8000 - 0x6fdc8fff -rw- image section: .data flags: rw- DATA 0x6fdc9000 - 0x6fdc9fff -rw- image section: .data flags: rw- DATA 0x6fdca000 - 0x6fdcbfff -rw- image section: .data flags: rw- DATA 0x6fdcc000 - 0x6ff59fff -r-- image section: .rsrc flags: r-- DATA 0x76620000 - 0x76620fff -r-- image file: USERENV.dll (76620000 - 766d5000) 0x76621000 - 0x766bffff -r-e image section: .text flags: r-x CODE 0x766c0000 - 0x766c1fff -rw- image section: .data flags: rw- DATA 0x766c2000 - 0x766d4fff -r-- image section: .rsrc flags: r-- DATA 0x76af0000 - 0x76af0fff -r-- image file: WINMM.dll (76af0000 - 76b1e000) 0x76af1000 - 0x76b0ffff -r-e image section: .text flags: r-x CODE 0x76b10000 - 0x76b10fff -rw- image section: .data flags: rw- DATA 0x76b11000 - 0x76b11fff -rw- image section: .data flags: rw- DATA 0x76b12000 - 0x76b1dfff -r-- image section: .rsrc flags: r-- DATA 0x770f0000 - 0x770f0fff -r-- image file: OLEAUT32.dll (770f0000 - 7717c000) 0x770f1000 - 0x77171fff -r-e image section: .text flags: r-x CODE 0x77172000 - 0x77172fff -rw- image section: .data flags: rw- DATA 0x77173000 - 0x77174fff -rw- image section: .data flags: rw- DATA 0x77175000 - 0x7717bfff -r-- image section: .rsrc flags: r-- DATA 0x773a0000 - 0x773a0fff -r-- image file: comctl32.dll (773a0000 - 774a2000) 0x773a1000 - 0x77430fff -r-e image section: .text flags: r-x CODE 0x77431000 - 0x77431fff -rw- image section: .data flags: rw- DATA 0x77432000 - 0x774a1fff -r-- image section: .rsrc flags: r-- DATA 0x774b0000 - 0x774b0fff -r-- image file: ole32.dll (774b0000 - 775ed000) 0x774b1000 - 0x775d5fff -r-e image section: .text flags: r-x CODE 0x775d6000 - 0x775d6fff -rw- image section: .data flags: rw- DATA 0x775d7000 - 0x775dcfff -rw- image section: .data flags: rw- DATA 0x775dd000 - 0x775ecfff -r-- image section: .rsrc flags: r-- DATA 0x77bb0000 - 0x77bb0fff -r-- image file: MSACM32.dll (77bb0000 - 77bc5000) 0x77bb1000 - 0x77bc0fff -r-e image section: .text flags: r-x CODE 0x77bc1000 - 0x77bc1fff -rw- image section: .data flags: rw- DATA 0x77bc2000 - 0x77bc4fff -r-- image section: .rsrc flags: r-- DATA 0x77bd0000 - 0x77bd0fff -r-- image file: VERSION.dll (77bd0000 - 77bd8000) 0x77bd1000 - 0x77bd4fff -r-e image section: .text flags: r-x CODE 0x77bd5000 - 0x77bd5fff -rw- image section: .data flags: rw- DATA 0x77bd6000 - 0x77bd7fff -r-- image section: .rsrc flags: r-- DATA 0x77be0000 - 0x77be0fff -r-- image file: msvcrt.dll (77be0000 - 77c38000) 0x77be1000 - 0x77c2cfff -r-e image section: .text flags: r-x CODE 0x77c2d000 - 0x77c2efff -rw- image section: .data flags: rw- DATA 0x77c2f000 - 0x77c2ffff -rw- image section: .data flags: rw- DATA 0x77c30000 - 0x77c30fff -rw- image section: .data flags: rw- DATA 0x77c31000 - 0x77c33fff -rw- image section: .data flags: rw- DATA 0x77c34000 - 0x77c37fff -r-- image section: .rsrc flags: r-- DATA 0x77d10000 - 0x77d10fff -r-- image file: USER32.dll (77d10000 - 77da0000) 0x77d11000 - 0x77d6ffff -r-e image section: .text flags: r-x CODE 0x77d70000 - 0x77d70fff -rw- image section: .data flags: rw- DATA 0x77d71000 - 0x77d71fff -rw- image section: .data flags: rw- DATA 0x77d72000 - 0x77d9ffff -r-- image section: .rsrc flags: r-- DATA 0x77da0000 - 0x77da0fff -r-- image file: ADVAPI32.dll (77da0000 - 77e4a000) 0x77da1000 - 0x77e15fff -r-e image section: .text flags: r-x CODE 0x77e16000 - 0x77e16fff -rw- image section: .data flags: rw- DATA 0x77e17000 - 0x77e1afff -rw- image section: .data flags: rw- DATA 0x77e1b000 - 0x77e49fff -r-- image section: .rsrc flags: r-- DATA 0x77e50000 - 0x77e50fff -r-- image file: RPCRT4.dll (77e50000 - 77ee1000) 0x77e51000 - 0x77ed9fff -r-e image section: .text flags: r-x CODE 0x77eda000 - 0x77edafff -rw- image section: .data flags: rw- DATA 0x77edb000 - 0x77ee0fff -r-- image section: .rsrc flags: r-- DATA 0x77ef0000 - 0x77ef0fff -r-- image file: GDI32.dll (77ef0000 - 77f36000) 0x77ef1000 - 0x77f31fff -r-e image section: .text flags: r-x CODE 0x77f32000 - 0x77f32fff -rw- image section: .data flags: rw- DATA 0x77f33000 - 0x77f35fff -r-- image section: .rsrc flags: r-- DATA 0x77f40000 - 0x77f40fff -r-- image file: SHLWAPI.dll (77f40000 - 77fb6000) 0x77f41000 - 0x77facfff -r-e image section: .text flags: r-x CODE 0x77fad000 - 0x77fadfff -rw- image section: .data flags: rw- DATA 0x77fae000 - 0x77fb5fff -r-- image section: .rsrc flags: r-- DATA 0x7c800000 - 0x7c800fff -r-- image file: kernel32.dll (7c800000 - 7c906000) 0x7c801000 - 0x7c882fff -r-e image section: .text flags: r-x CODE 0x7c883000 - 0x7c885fff -rw- image section: .data flags: rw- DATA 0x7c886000 - 0x7c887fff -rw- image section: .data flags: rw- DATA 0x7c888000 - 0x7c905fff -r-- image section: .rsrc flags: r-- DATA 0x7c910000 - 0x7c910fff -r-- image file: ntdll.dll (7c910000 - 7c9c7000) 0x7c911000 - 0x7c98bfff -r-e image section: .text flags: r-x CODE 0x7c98c000 - 0x7c98efff -rw- image section: .data flags: rw- DATA 0x7c98f000 - 0x7c990fff -rw- image section: .data flags: rw- DATA 0x7c991000 - 0x7c9c6fff -r-- image section: .rsrc flags: r-- DATA 0x7c9d0000 - 0x7c9d0fff -r-- image file: SHELL32.dll (7c9d0000 - 7d1ee000) 0x7c9d1000 - 0x7cbcbfff -r-e image section: .text flags: r-x CODE 0x7cbcc000 - 0x7cbdbfff -rw- image section: .data flags: rw- DATA 0x7cbdc000 - 0x7cbe1fff -rw- image section: .data flags: rw- DATA 0x7cbe2000 - 0x7cbe8fff -rw- image section: .data flags: rw- DATA 0x7cbe9000 - 0x7d1edfff -r-- image section: .rsrc flags: r-- DATA 0x7f6f0000 - 0x7f6f6fff -r-e mapped 0x7ffb0000 - 0x7ffd3fff -r-- mapped 0x7ffdc000 - 0x7ffdcfff -rw- private 0x7ffdf000 - 0x7ffdffff -rw- private 0x7ffe0000 - 0x7ffe0fff -r-- private

Dec. 2, 2006

Re: XEMBED Implementation

by Roderick Colenbrander

Hi, The XEMBED stuff in Wine is different than what you need. This code is inside wine's x11 driver and has the purpose of integrating the Wine system tray with KDE/Gnome. It is for internal wine usage and can't be used for your purpose. You could search for the kde reaktivate project. It was designed for embedding windows activex controls through Wine in Konqueror. I'm not sure how they are embedding wine stuff, it might help. Regards, Roderick > Hi, > > I find discussion about XEMBED implementation in this mailing list and > that was 3 years ago. Is there now any usable implementation or examples > for wine XEMBED plug? > > What I am doing is to embed IE into a GtkSocket. I wrote a standalone > program compiled using winelib that can CreateWindow and embed IE. Can I > CreateWindow using the XEMBED Id if there is already XEMBED > implementation or can I just CreateWindow as a child of a GtkPlug which > is a gtk-embeddee? > > Any advices or suggestions would be highly appreciated. Thank you! > > Regards, > cloudor > > -- "Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

Dec. 2, 2006