wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

RE: dlls/advapi32/crypt.c
by Patrik Stridvall 16 Sep '01

16 Sep '01

> On another note, however, I was re-reading the CryptoAPI > thread and I don't > think that Vladimir Vukicevic's questions were really > answered from September > 3rd. Can you be a little more specific? As far using GPL:ed libraries, that is a question that really can't be properly answered without a real court case. Regardless of this if you want any code using a GPL:ed library in the CVS you need to convince Alexandre to change his mind. What other questions are unanswered?

5 4

min/max and types
by eric pouech 15 Sep '01

15 Sep '01

just for fun, I tried compiling Wine with Linux latest min/max macros definitions Index: include/windef.h =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/include/windef.h,v retrieving revision 1.58 diff -u -r1.58 windef.h --- include/windef.h 2001/07/30 18:57:18 1.58 +++ include/windef.h 2001/09/14 18:06:53 @@ -133,6 +133,27 @@ #define min(a,b) (((a) < (b)) ? (a) : (b)) #endif #endif /* NOMINMAX */ +#if defined(__WINE__) && defined(__GNUC__) +#undef max +#undef min +#define min(x,y) \ + ({ const typeof(x) _x = x; \ + const typeof(y) _y = y; \ + \ + (void) (&_x == &_y); \ + \ + _x < _y ? _x : _y; \ + }) + +#define max(x,y) \ + ({ const typeof(x) _x = x; \ + const typeof(y) _y = y; \ + \ + (void) (&_x == &_y); \ + \ + _x > _y ? _x : _y; \ + }) +#endif #ifndef _MAX_PATH /* FIXME: These are supposed to be in stdlib.h only */ here's the output (the list of types mismatches in min/max calls...) to whomever feels like fixing them (if needed) registry.c:386: warning: comparison of distinct pointer types lacks a cast registry.c:1246: warning: comparison of distinct pointer types lacks a cast trace.c:69: warning: comparison of distinct pointer types lacks a cast trace.c:147: warning: comparison of distinct pointer types lacks a cast reg.c:177: warning: comparison of distinct pointer types lacks a cast reg.c:195: warning: comparison of distinct pointer types lacks a cast reg.c:209: warning: comparison of distinct pointer types lacks a cast reg.c:224: warning: comparison of distinct pointer types lacks a cast reg.c:232: warning: comparison of distinct pointer types lacks a cast reg.c:306: warning: comparison of distinct pointer types lacks a cast reg.c:318: warning: comparison of distinct pointer types lacks a cast reg.c:328: warning: comparison of distinct pointer types lacks a cast reg.c:379: warning: comparison of distinct pointer types lacks a cast reg.c:416: warning: comparison of distinct pointer types lacks a cast reg.c:496: warning: comparison of distinct pointer types lacks a cast dos_fs.c:2201: warning: comparison of distinct pointer types lacks a cast dos_fs.c:2202: warning: comparison of distinct pointer types lacks a cast drive.c:926: warning: comparison of distinct pointer types lacks a cast file.c:1884: warning: comparison of distinct pointer types lacks a cast profile.c:120: warning: comparison of distinct pointer types lacks a cast module.c:1644: warning: comparison of distinct pointer types lacks a cast module.c:1645: warning: comparison of distinct pointer types lacks a cast heap.c:645: warning: comparison of distinct pointer types lacks a cast local.c:401: warning: comparison of distinct pointer types lacks a cast local.c:891: warning: comparison of distinct pointer types lacks a cast registry.c:507: warning: comparison of distinct pointer types lacks a cast version.c:477: warning: comparison of distinct pointer types lacks a cast int21.c:857: warning: comparison of distinct pointer types lacks a cast int21.c:861: warning: comparison of distinct pointer types lacks a cast ole2nls.c:435: warning: comparison of distinct pointer types lacks a cast process.c:1251: warning: comparison of distinct pointer types lacks a cast process.c:1276: warning: comparison of distinct pointer types lacks a cast process.c:1312: warning: comparison of distinct pointer types lacks a cast process.c:1345: warning: comparison of distinct pointer types lacks a cast console.c:170: warning: comparison of distinct pointer types lacks a cast console.c:429: warning: comparison of distinct pointer types lacks a cast console.c:982: warning: comparison of distinct pointer types lacks a cast console.c:984: warning: comparison of distinct pointer types lacks a cast console.c:1294: warning: comparison of distinct pointer types lacks a cast console.c:1345: warning: comparison of distinct pointer types lacks a cast registry.c:785: warning: comparison of distinct pointer types lacks a cast registry.c:1001: warning: comparison of distinct pointer types lacks a cast registry.c:1082: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:203: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:229: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:230: warning: comparison of distinct pointer types lacks a cast enhmetafile.c:1702: warning: comparison of distinct pointer types lacks a cast dde/misc.c:1963: warning: comparison of distinct pointer types lacks a cast message.c:962: warning: comparison of distinct pointer types lacks a cast resource.c:320: warning: comparison of distinct pointer types lacks a cast resource.c:370: warning: comparison of distinct pointer types lacks a cast text.c:318: warning: comparison of distinct pointer types lacks a cast menu.c:847: warning: comparison of distinct pointer types lacks a cast menu.c:849: warning: comparison of distinct pointer types lacks a cast menu.c:917: warning: comparison of distinct pointer types lacks a cast menu.c:918: warning: comparison of distinct pointer types lacks a cast menu.c:931: warning: comparison of distinct pointer types lacks a cast cursoricon.c:519: warning: comparison of distinct pointer types lacks a cast timer.c:155: warning: comparison of distinct pointer types lacks a cast winpos.c:1811: warning: comparison of distinct pointer types lacks a cast winpos.c:1812: warning: comparison of distinct pointer types lacks a cast winproc.c:1755: warning: comparison of distinct pointer types lacks a cast winproc.c:1768: warning: comparison of distinct pointer types lacks a cast winproc.c:1901: warning: comparison of distinct pointer types lacks a cast winpos.c:1733: warning: comparison of distinct pointer types lacks a cast winpos.c:1734: warning: comparison of distinct pointer types lacks a cast winpos.c:1738: warning: comparison of distinct pointer types lacks a cast winpos.c:1739: warning: comparison of distinct pointer types lacks a cast winpos.c:1743: warning: comparison of distinct pointer types lacks a cast winpos.c:1744: warning: comparison of distinct pointer types lacks a cast winpos.c:1748: warning: comparison of distinct pointer types lacks a cast winpos.c:1749: warning: comparison of distinct pointer types lacks a cast winpos.c:1815: warning: comparison of distinct pointer types lacks a cast winpos.c:1816: warning: comparison of distinct pointer types lacks a cast winpos.c:1817: warning: comparison of distinct pointer types lacks a cast winpos.c:1818: warning: comparison of distinct pointer types lacks a cast xfont.c:3336: warning: comparison of distinct pointer types lacks a cast xfont.c:3339: warning: comparison of distinct pointer types lacks a cast lolvldrv.c:106: warning: comparison of distinct pointer types lacks a cast mmsystem.c:986: warning: comparison of distinct pointer types lacks a cast comboex.c:395: warning: comparison of distinct pointer types lacks a cast listview.c:723: warning: comparison of distinct pointer types lacks a cast listview.c:780: warning: comparison of distinct pointer types lacks a cast listview.c:3123: warning: comparison of distinct pointer types lacks a cast listview.c:7940: warning: comparison of distinct pointer types lacks a cast propsheet.c:145: warning: comparison of distinct pointer types lacks a cast propsheet.c:1998: warning: comparison of distinct pointer types lacks a cast rebar.c:1476: warning: comparison of distinct pointer types lacks a cast rebar.c:1490: warning: comparison of distinct pointer types lacks a cast tab.c:1080: warning: comparison of distinct pointer types lacks a cast toolbar.c:1086: warning: comparison of distinct pointer types lacks a cast treeview.c:1500: warning: comparison of distinct pointer types lacks a cast treeview.c:1594: warning: comparison of distinct pointer types lacks a cast treeview.c:2514: warning: comparison of distinct pointer types lacks a cast treeview.c:2516: warning: comparison of distinct pointer types lacks a cast treeview.c:4218: warning: comparison of distinct pointer types lacks a cast treeview.c:4351: warning: comparison of distinct pointer types lacks a cast treeview.c:4356: warning: comparison of distinct pointer types lacks a cast midi.c:117: warning: comparison of distinct pointer types lacks a cast audio.c:774: warning: comparison of distinct pointer types lacks a cast audio.c:1759: warning: comparison of distinct pointer types lacks a cast midi.c:618: warning: comparison of distinct pointer types lacks a cast midi.c:968: warning: comparison of distinct pointer types lacks a cast internet.c:489: warning: comparison of distinct pointer types lacks a cast -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 2

Winsock API
by Robert Lunnon 15 Sep '01

15 Sep '01

I have Converted WSAIOCTL to use SIOCGETIFCONF ioctl calls rather than parse /proc which is to linux-centric but I was asked by Francois Gouget to look at trying to make WsControl unix independent by implementing it using other windows APIs rather than by using unix calls directly. Unfortunately this API is a bit of a mess because WsControl can return the MAC Adress but WSAIoctl doesn't appear to implement that functionality. To get The MAC Address we then need to make an appropriate UNIX IOCTL call for which we need the interface name, which isn't available from WSAIoctl either. There are other ways in windows to getthe MAC address via an SNMP call but I'm not sure how that is implemented (Possibly with a call back to WSControl) I don't see then how WSControl can be implemented without the present hacks and duplicated code between WSAIoclt and WSControl helper functions. My proposal then would be... 1.) Separate out all the unix centric helper functions for WSControl and WSAIoctl into a common ancestor source file with no windows dependencies. This should remove the ugly socket hack in WSControl, both libraries still end up with private copies of the common helper functions but since they are all derived from the same common source file it will at least be encapsulated and easier to maintain. 2.) The doco for WSIoctl indicate the encoding for the Ioctl op-code allows for a "Standard" unix IOCTL to be passed to WSIoctl ostensibly for FIONREAD,FIONBIO et al, with predictable results. If I were to implement SIOCGETIFCONF in WsIoctl then this would allow a pass-through so I could get what I need from the host OS without disturbing current windows programs. Because windows doesn't define SIOCGETIFCONF whatever we choose for the value of the op-code might end up being used by Microsoft later, breaking Wine. (Possible but not very likely) Opinions ?

1 0

Information Request For Porting WINE
by Lucien LaCroix 15 Sep '01

15 Sep '01

I would like to find out if the development of WINE supports it being ported to Windows 16-Bit OS. Currently, I am developing a Windows Clone and would very much ike to work on Porting WINE to Win16. However, I am not 100% sure if the way WINE operates wether it would work. WINE will work if it is a complete re-written library system that merely interfaces with the host system. WINE won't work if it serves as a translater from host system system calls to the guest application. Any information on this plus a good compiler that is usefull for someone who knows a bit, but not everything, hopefully one with a good GUI. Thank-You. David Scherer, lacroixlucien(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1

Re: Bug: loss of mousepointer
by Alexandre Julliard 14 Sep '01

14 Sep '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > After last nights CVS commits, the Mousepointer appears not to be visible > in some applications in both managed and unmanaged mode. > > Reproducable for me with sol.exe and winmine.exe (16bit) for instance. This should fix it I think: Index: windows/nonclient.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/nonclient.c,v retrieving revision 1.84 diff -u -r1.84 nonclient.c --- windows/nonclient.c 2001/08/24 00:26:59 1.84 +++ windows/nonclient.c 2001/09/14 17:20:00 @@ -1729,7 +1729,8 @@ */ LONG NC_HandleSetCursor( HWND hwnd, WPARAM wParam, LPARAM lParam ) { - if (hwnd != (HWND)wParam) return 0; /* Don't set the cursor for child windows */ + if (hwnd != WIN_GetFullHandle( (HWND)wParam )) + return 0; /* Don't set the cursor for child windows */ switch(LOWORD(lParam)) { -- Alexandre Julliard julliard(a)winehq.com

1 0

IE 5.01
by Nick Hudson 14 Sep '01

14 Sep '01

Greetings, Well i know ill get flamed for this but has anyone got IE 5.01 installed on wine? Everytime I try it gives me an error that "Some programs hasnt finished and that I need to let it finish and restart my computer" Then it closes. So any ideo on getting any version of IE installed? Thanks Nick Hudson

2 1

GDI_CheckNotLock strikes again
by Dmitry Timoshkov 14 Sep '01

14 Sep '01

Hello. Decided to try sample program which uses GetGlyphOutline. Backtrace: =>0 0x400d2ae1 (_CheckNotSysLevel+0x51(lock=0x407bb6a4) [syslevel.c:153] in libntdll.so) (ebp=405b6734) 1 0x407a2667 (GDI_CheckNotLock+0x1b [gdiobj.c:446] in libgdi32.so) (ebp=405b6744) 2 0x40798a1c (DeleteDC+0x48(hdc=0x8bc) [dc.c:784] in libgdi32.so) (ebp=405b6764) 3 0x407983b9 (RestoreDC+0x13d(hdc=0x8a0, level=0x1) [dc.c:541] in libgdi32.so) (ebp=405b6790) 4 0x4078ba4b (PATH_StrokePath+0x28b(dc=0x403a1640, pPath=0x403a16a0) [path.c:1511] in libgdi32.so) (ebp=405b67b4) 5 0x4078baf0 (StrokeAndFillPath+0x64(hdc=0x8a0) [path.c:1547] in libgdi32.so) (ebp=405b67d4) 6 0x004016c6 (DrawPath+0xb6(hDC=0x8a0) [C:\DevStudio\Projects\Glyph\Glyph.c:434] in C:\Glyph.exe) (ebp=405b683c) 7 0x00401c77 (DrawTTOutline+0x527(hDC=0x8a0, lpHeader=0x403a1c10, size=0xffffffff) [C:\DevStudio\Projects\Glyph\Glyph.c:618] in C:\Glyph.exe) (ebp=405b68c8) 8 0x00402023 (OutputGlyph+0x243(hDC=0x8a0, letter=0x21, x=0x0, y=0x0, ascent=0x78) [C:\DevStudio\Projects\Glyph\Glyph.c:724] in C:\Glyph.exe) (ebp=405b6970) 9 0x0040225f (PaintIt+0x14f(hWnd=0x10021, hDC=0x8a0) [C:\DevStudio\Projects\Glyph\Glyph.c:806] in C:\Glyph.exe) (ebp=405b6a48) 10 0x00402701 (MainWndProc+0x351(hWnd=0x10021, message=0xf, wParam=0x0, lParam=0x0) [C:\DevStudio\Projects\Glyph\Glyph.c:958] in C:\Glyph.exe) (ebp=405b6b30) 11 0x406e8507 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b6b54) 12 0x406e85a0 (WINPROC_CallWndProc+0x8c(proc=0x401028, hwnd=0x10021, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:172] in libuser32.so) (ebp=405b6b84) 13 0x406edcfd (WINPROC_CallProc32WTo32A+0x8d(func=0x401028, hwnd=0x10021, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2434] in libuser32.so) (ebp=405b6bac) 14 0x406ee237 (CallWindowProcW+0x93(func=0x40f80871, hwnd=0x10021, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2685] in libuser32.so) (ebp=405b6bd4) 15 0x4068a6c9 (call_window_proc+0xb5(hwnd=0x10021, msg=0xf, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=405b6c24) 16 0x4068b23c (SendMessageTimeoutW+0xc4(hwnd=0x10021, msg=0xf, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x405b6ca8) [message.c:1508] in libuser32.so) (ebp=405b6c78) 17 0x4068b4b0 (SendMessageW+0x38(hwnd=0x10021, msg=0xf, wparam=0x0, lparam=0x0) [message.c:1577] in libuser32.so) (ebp=405b6cac) 18 0x406d6a03 (RDW_Paint+0xbf(wndPtr=0x4039f0cc, hrgn=0x0, flags=0x180, ex=0x0) [painting.c:780] in libuser32.so) (ebp=405b6ce0) 19 0x406d6f40 (RedrawWindow+0x398(hwnd=0x10021, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:974] in libuser32.so) (ebp=405b6d4c) 20 0x406d703d (UpdateWindow+0x21(hwnd=0x10021) [painting.c:1006] in libuser32.so) (ebp=405b6d68) 21 0x0040297e (InitInstance+0x6e(hInstance=0x400000, nCmdShow=0xa) [C:\DevStudio\Projects\Glyph\Glyph.c:1051] in C:\Glyph.exe) (ebp=405b6dc4) 22 0x004029e0 (WinMain+0x30(hInstance=0x400000, hPrevInstance=0x0, lpCmdLine=0x40360c45, nCmdShow=0xa) [C:\DevStudio\Projects\Glyph\Glyph.c:1087] in C:\Glyph.exe) (ebp=405b6e3c) 23 0x00402f53 (WinMainCRTStartup+0x113 [crt0.c:198] in C:\Glyph.exe) (ebp=405b6ecc) 24 0x400cec3d (start_process+0x195 [process.c:390] in libntdll.so) (ebp=405b6f30) 25 0x400d252c (SYSDEPS_DoCallOnStack+0x20(func=0x400ceaa8, arg=0x0) [sysdeps.c:183] in libntdll.so) (ebp=405b6ff0) 26 0x400d25d3 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffffa3c) 27 0x400d2680 (SYSDEPS_SwitchToThreadStack+0x94(func=0x400ceaa8) [sysdeps.c:238] in libntdll.so) (ebp=bffffa78) 28 0x400cefce (PROCESS_InitWine+0x1ca(argc=0x2, argv=0xbffffaf4, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:522] in libntdll.so) (ebp=bffffa90) 29 0x0804b1e6 (Letext [main.c] in wine) (ebp=bffffaa8) 30 0x402769cb (__libc_start_main+0xff(main=0x804b1cc, argc=0x2, argv=0xbffffaf4, init=0x80486d4, fini=0x804b224, rtld_fini=0x4000aea0, stack_end=0xbffffaec) [libc-start.c:92] in libc.so.6) (ebp=bffffac8) 31 0x08049021 (_start+0x21 in wine) (ebp=00000000) -- Dmitry.

2 3

Bug: loss of mousepointer
by Marcus Meissner 14 Sep '01

14 Sep '01

Hi, After last nights CVS commits, the Mousepointer appears not to be visible in some applications in both managed and unmanaged mode. Reproducable for me with sol.exe and winmine.exe (16bit) for instance. Ciao, Marcus

1 0

Re: unmanaged windows
by Alexandre Julliard 14 Sep '01

14 Sep '01

Bobby Bingham <uhmmmm(a)ameritech.net> writes: > I think there was a discussion a while back about possibly rewriting the > "unmanaged" mode (or adding a new mode, I don't recall which) to make it more > like XMMS, but I can't find it now. This would really help on my system, as > with KDE 2.2, wine windows are always on top and on every desktop and XMMS > fits in a little better. I was wondering what the result if any, of that > discussion was. I was planning to implement that as part of the new window management stuff. But this is on hold at the moment while I'm finishing the shared window handles. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Problem with specmaker
by Guy L. Albertelli 13 Sep '01

13 Sep '01

-----Original Message----- From: Patrik Stridvall <ps(a)leissner.se> To: 'eric pouech' <eric.pouech(a)wanadoo.fr>; Guy L. Albertelli <galberte(a)neo.lrun.com> Cc: Wine Devel <wine-devel(a)winehq.com> Date: Thursday, September 06, 2001 5:59 PM Subject: RE: Problem with specmaker > >Hmm. Thinking, modifying etc. > >What about this? > >Index: wine/tools/specmaker/function_grep.pl >=================================================================== >RCS file: /home/wine/wine/tools/specmaker/function_grep.pl,v >retrieving revision 1.1 >diff -u -u -r1.1 function_grep.pl >--- wine/tools/specmaker/function_grep.pl 2001/01/04 19:45:50 1.1 >+++ wine/tools/specmaker/function_grep.pl 2001/09/06 21:50:26 <snip> No the above patch merely resulted in an infinite loop. After much consultation with "Perl in a Nutshell", I came up with the following patch. The header file in question is "shlobj.h". The patch has two sections. First gets rid of the \n imbeded with the lookahead for preprocessor statements. The second gets rid of the ICOM_DEFINE statement (poorly I know) because it has no ";". This seems to make things work and generate correct headers. Thanks, Guy

1 0

dlls/advapi32/crypt.c
by Morten Welinder 13 Sep '01

13 Sep '01

Someone added code to CryptGenRandom so that it generates very bad random data (with <10 bits randomness in them). Don't do that. It's a known security risk. Read from /dev/urandom instead. If that does not succeed, just abort(). Linux and newer Solaris have /dev/urandom. I would guess the BSDs have it too. Morten

2 1

wcs* functions within Wine
by Huw D M Davies 13 Sep '01

13 Sep '01

Hi, I want to use wcsrchr and wcstrol in oleaut32.dll . If I just use them then we do indeed call the ntdll versions rather than libc which is all very nice. The question is, what include file am I supposed to use to get their protoypes? Huw.

1 0

unmanaged windows
by Bobby Bingham 13 Sep '01

13 Sep '01

I think there was a discussion a while back about possibly rewriting the "unmanaged" mode (or adding a new mode, I don't recall which) to make it more like XMMS, but I can't find it now. This would really help on my system, as with KDE 2.2, wine windows are always on top and on every desktop and XMMS fits in a little better. I was wondering what the result if any, of that discussion was. Bobby Bingham -- Microsoft Windows: Made for the internet The Internet: Made for UNIX

1 0

Re: negative listview column width in WinZip 8.0
by Malte Starostik 13 Sep '01

13 Sep '01

Am Thursday 13 September 2001 03:37 schrieben Sie: > WinZip 8.0 requests a negative column width for one of the columns in > the WinZip classic Zip file contents list. This stuffs up the list, > causing the other columns to be overwritten, and resulting in a blank > list. > > This patch prevents column widths from being negative. AFAIK, -1 and -2 and maybe others are special values that tell the list view to adjust the contents to the widest item and something else I cannot remember exactly (sorry, no Windows available ATM). -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] http://malte.homeip.net/justice-not-war.html M0ò0ò0

1 0

winedump prints a strange export table
by Francois Gouget 13 Sep '01

13 Sep '01

If I run 'winedump dump ws2_32.dll -j export' I get a strange result: ... 00000000 125 <by ordinal> 00000000 126 <by ordinal> 00000000 127 <by ordinal> 00000000 128 <by ordinal> ... Are these really significant? It seems like they go all the way up to the highest ordinal of a 'real' exported function, here 500, WEP. Also if I run 'winedump dump msvcrt.dll -j export -C' winedump seems to crash. It looks like it tries to interpret mangled names as glibc mangled names? Hmm, '-C' seems to have trouble even with other dlls. Christian Jiresjö expressed interest in working on winedump (see bug #91), maybe these would be good bugs for him to takle. Btw eric, thanks for the thread patch in winedbg. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

1 0

HAVE_IPX cleanup
by Francois Gouget 12 Sep '01

12 Sep '01

This patch attempts to clean up the ws_sockaddr_ipx to sockaddr_ipx conversions (and vice versa). I would really like if people could try this out: I don't have a working IPX network here. At least my very rudimentary tests indicate that this should still work for the TCP/IP case. More details on the patch: * all ws_sockaddr structures must be considered to have a potentially different layout from their Unix counterparts. Sure for now we just borrow the Unix structs anyway but even sockaddr_in does not have the exact same fields on FreeBSD and Linux (although the binary layout is the same). And hopefully we will not borrow the Unix structs for long anyway. FreeBSD testing is another aspect I would appreciate help with (sin_len worries me). * the ws_sockaddr_ipx fields did not match those used by windows. Also ws_sockaddr_ipx was declared in the wrong header. * all conversions are now done in two functions: ws_sockaddr_ws2u and ws_sockaddr_u2ws. If there is a conversion to do then these are the only two places that should be affected. SUPPORTED_PF returns whether a given protocol family is supported or not. * the sockaddr* pointers may point to structures that are more than 16 bytes, typically 28 bytes for IP v6. I tried to take this into account, I hope I did not mess up (but I'm not sure Wine would support TCP/IP v6 anyway). * I modified WSOCK32_accept to call WSOCK32_getpeername thus avoiding the conversion issue entirely in WSOCK32_accept. * all other functions that were doing such conversions were modified to use the above functions. I also tried to make the error handling code more consistent wrt. WSAENOTSOCK, WSAEAFNOSUPPORT, etc. * removed ugly casts in the traces -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

1 0

Russian keyboard layout
by Andriy Palamarchuk 12 Sep '01

12 Sep '01

Hello everybody, I want to fix message about not found keyboard layout for my configuration. The FIXME message is not shown after I add a phantom key definition to russian keyboard layout main_key_RU in file windows/x11drv/keyboard.c I need your advise how to do it correctly. Should I change existing layout - main_key_RU or it is better to add a separate one with phantom key - main_key_RU_phantom, like it is presently done for US layouts? I could not suppress the FIXME message by changing keyboard model in XF86Config from "pc102" to "pc101". My system: Wine release 20010824, installed without Windows, gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81) The layout, defined in XF86Config is "ru(winkeys)". Thank you, Andriy Palamarchuk

1 0

Solaris winsock support
by Robert Lunnon 12 Sep '01

12 Sep '01

Trying Eudora 4.3 on Solaris solicits this error err:winsock:WsControl Unable to open /proc filesystem to determine number of network interfaces! Looking about in the code WsControl grubs about in the /proc filesystem to get the names of, and count the number of network interfaces. Since /Proc only hosts processes on Solaris this constitutes a linux dependancy we don't need. Studying the ifconfig source gives another possibility instead which look like it may be more portable using ioctl SIOCGIFCONF on an arbitrary IP socket The return from this call is a structure containing the length of the reply buffer, which seems to contains an array of ifreq structures (one for each interface) which contains among other things the name of the interface. By dividing the size of the buffer by the size of the returned objects we know how many interfaces there are... Questions Anyone know if this is Is this workable ? Is this workable on linux, (I ask because I don't have linux and don't know linux ioctl implementation details)?

3 2

X output problem while displaying splash screen
by Andreas Schuldei 12 Sep '01

12 Sep '01

The part of the screen where the splash screen of the internet explorer should be displayed freezes, but the debug messages keep scrolling for some time. That is why I send the whole output. I used the command line wine -dll=ole2,ole2conv,ole2disp,ole2nls,ole32,oleaut32,olecli,olecli32,olecnv32,oledlg,olepro32,olesvr,olesvr32,olethk32,compobj,rpcrt4,shell,shell32,shfolder,shdocvw,commdlg,comdlg32,commctrl,comctl32,urlmon,SHLWAPI=n .wine/fake_windows/Program\ Files/Internet\ Explorer/IEXPLORE.EXE --debugmsg +relay,+x11

1 0

Re: Focus livelock
by Alexandre Julliard 11 Sep '01

11 Sep '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > Now, when after all this the X events are processed, Wine handles a X > focusin event for A, that is generating a WM_GETFOCUS, then a focusout > for A, generating other WM_KILLFOCUS and WM_ GETFOCUS, > focusin for B, etc..; the sequence of events when creating windows is > perfect, but there are extra events after. > > IMO what's wrong is that X focus events are not ignored when they are the > following of program action. IMO the right fix is to add support for the take focus window manager protocol, and avoid messing with the X focus ourselves. This is somewhere on my todo list... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Dialog painting
by Niclas Karlsson MATE 10 Sep '01

10 Sep '01

> Wine currently seems to have a problem painting splash dialogs properly > (or at all). I took a closer look at this. I just ripped out the interesting parts from Speak freely in order to find a simple program exhibiting the problems. What I ended up with was a program which does nothing interesting except to show a simple dialg using CreateDialog(). It still doesn't work under Wine. The source is attached. I'm somewhat at a loss about what to do now. I'm just not clear about what should happen and why it doesn't. Some browsing around in the source suggests that it may related to the focus problems Gerard has been talking about, but I'm far from sure. Any comments? Nicke -- -[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)

1 0

Developer offering to help.
by Marco Bizzarri 10 Sep '01

10 Sep '01

Hi all. I've seen in the recent past a task list for newbie developer for wine. I would like to know what are still open, how I could contribute. I've very few skills in Windows development. However, I've good knowledge of development under linux, and usage of gnu tools (autoconf). Bye Marco -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

2 1

Re: Focus livelock
by Gerard Patel 10 Sep '01

10 Sep '01

At 10:09 AM 09/09/2001 +0300, you wrote: >I posted a patch that would fix a focus related livelock. >However, I have to admit that the patch is quite hacky and likely >not to be included in Wine. Since I would like to get this bug fixed, >I thought to ask opinions about the correct way to fix the bug. > >The short description of the bug is that setting >active/foreground/focus window in Wine calls >X11DRV_SetFocus, which calls XSetInputFocus. >This makes Wine receive FocusIn event, the handler of >which calls SetForegroundWindow. Even though SetForegroundWindow >does nothing if its parameter matches current foreground window, >it can be easily seen that having more than one window can lead >into livelock. I think that the problem with focus is that when a window is shown by Wine, synthetic WM_GETFOCUS and WM_SETFOCUS events are generated, that are themselves generating X focus events. The X events are kept in the X queue until Wine finds time to handle them. Wine creates window A : WM_GETFOCUS for A Wine creates window B : WM_KILLFOCUS for A, WM_GETFOCUS for B Wine creates window C : WM_KILLFOCUS for B, WM_GETFOCUS for C Now, when after all this the X events are processed, Wine handles a X focusin event for A, that is generating a WM_GETFOCUS, then a focusout for A, generating other WM_KILLFOCUS and WM_ GETFOCUS, focusin for B, etc..; the sequence of events when creating windows is perfect, but there are extra events after. IMO what's wrong is that X focus events are not ignored when they are the following of program action. The following hack disables focus handling in this case. I have no clue on its value since I am currently struggling with other bugs. and I will not come to these problems until some time - maybe a lot of time if current Wine progress (aka regressions :-)) continues. --- event.c.orig Fri Aug 24 09:30:46 2001 +++ event.c Mon Sep 10 13:00:28 2001 @@ -534,6 +534,8 @@ if (!hWnd) return; + if (!event->send_event) return; + bIsDisabled = GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED; /* If the window has been disabled and we are in managed mode, HTH Gerard

1 0

Re: Monkey Island 3
by Gerard Patel 10 Sep '01

10 Sep '01

At 03:11 PM 09/09/2001 +0200, you wrote: >The installation of Curse of Monkey Island seems to be broken in latest >CVS. All I get is a dialog saying that setup requires a different version >of Windows. > >A trace is available on the web at >http://www.lysator.liu.se/~johane/monkey3.txt > >/Johan Gill, johane(a)lysator.liu.se > I have looked at your trace -the app is trying to use a Win32s function. Maybe the problem is that it succeeds. However, Win32s is present in Wine since years and has not been touched since a long time. I think unlikely that it could be a new problem - when was the last working Wine version before current Cvs ? You can find in documentation/cvs-regression a few tips on how to search for the exact date of a regression. FYI the Wine app database list this game as 'playing perfectly directly off the CD' :-) Gerard

1 0

Re: [PATCH] DestroyWindow16
by Gerard Patel 10 Sep '01

10 Sep '01

At 06:40 PM 30/08/2001 +0200, you wrote: >Gerard Patel wrote: >> >> As DestroyWindow does a lot of handle comparaisons, it is necessary >> to give it a real 32 bit handle. This avoids a systematic crash when >> ForteFreeAgent 16 bit exits. I have not looked for other places where >> this can be necessary - but it would not be surprising that this happens. >perhaps as an extension of the relay code ? >(it would mean typing >correctly >windows handles in spec files though) What do you mean by typing ? There is no hwnd type in the spec files, AFAICT. That's not a matter of typing GetWindow(hwnd word) instead of GetWindow(word word) - I think it is necessary to actually change winebuild to define a new type and write a bunch of code to support it. I have looked at the points where it current cvs crashes and it's necessary to fix 16 to 32 bits handles and I have found that 2 changes cure all my new crashes : the one in DestroyWindow16 and another in DefWindowProc16 The reason for these problems is the same : Wine is keeping window handles in several variables (active window, focus window) and Wine code does several comparisons between applications provided handles and these values. In the last case for example, the test /* activate hwndTop if needed. */ if (hwndTop != GetActiveWindow()) { in focus.c fails because of the high word part (and creates an infinite focus loop) I'd say that by adding also handle fixes in SetWindowPos16, SetFocus16 and SetActiveWindow16 as well as fixing the handles setters in queue.c, everything would be covered. IMO your solution is 1) somewhat complex for a fix to apps not widely used anymore 2) overkill because it's not necessary to convert window handles for each and every Api. OTOH your solution is more elegant. I don't know what to do. Gerard

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel