September 2001 - Wine-Devel

InstallShield 6 again (debuggers requested)
by Ove Kaaven Oct. 1, 2001

Oct. 1, 2001

Here are some kludgy patches (against the current WineHQ CVS) that's supposed to make InstallShield 6 with its stupid interprocess COM sort of work, but it doesn't for some reason, probably because of something else in Wine that's broken... and because of a lack of time, I think I really need some debugging assistance. Most of these patches are too ugly to be submitted to the official wine as-is, I'll clean these parts up later, but probably not before InstallShield has been debugged and actually works with these hacks. To make this run, you need to copy stdole32.tlb from a real windows and put into c:\windows\system. Then run your favorite InstallShield 6 setup.exe and wait for it to crash. --debugmsg +ole is recommended. It crashes for me after about 25 remote method calls. If you find out why, let me know. Please.

3 7

DdeConnect errors while running setup.exe
by Ian D . Stewart Oct. 1, 2001

Oct. 1, 2001

Dear Wine Developers, Due to resource constraints (75 MHz processor, 1.2 GB hard drive, 16 MB RAM), we recently replaced Windows98 on our daughter's PC with Linux Mandrake, using the IceWM window manager. It isn't quite as flashy as Windows, but it boots beyond the startup screen, which is more than can be said for Win98. Well, to make a long story short, I've installed and configured Wine following the instructions in the Wine User's Guide. Everything seems to be working properly, but when I attempted to run the setup.exe for 'Jim Henson Muppets Letters: Capital & Small', I received the following errors: err:ddeml:DdeConnect .. but no Server window available err:ddeml:DdeClientTransaction Invalid conversation handle err:ddeml:DdeClientTransaction Invalid conversation handle err:ddeml:DdeClientTransaction Invalid conversation handle fixme:ddeml:DdeUninitialize16 stub calling DdeUninitialize Following the recomendations in the Wine User's Guide, section 3.2 (Installing Wine Without Windows), I re-ran wine with --debug msg +module,+file. I didn't see anything in the trace that jumped out at me, but I've attached it here, just in case it means something to someone else. One last thing. The setup.exe appears to be a 16-bit app, originally designed for Windows 3.1. Not sure if that makes any difference or not. Any help in resolving this would be greatly appreciated. Regards, Ian D. Stewart -- "God may have mercy. We will not." --Senator John S. McCain (R-AZ)

2 1

Bug in CreateWindowEx
by Luke Stras Sept. 29, 2001

Sept. 29, 2001

I'm trying to get Civ2 to run under wine (checked out via CVS today), and I've run into a particular problem. The installation is totally stand-alone -- all DLLs are built-in. I get an invalid page fault in X11DRV_GetDC [winpos.c:441], at the line which says: drawable = data->client_window Some debugger work shows that data is NULL. Now, the backtrace shows that we get *here* from a call to WIN_GetMinMaxInfo from CreateWindowEx [win.c:885]. The problem, as I see it, is that USER_Driver.pCreateWindow doesn't get called until [win.c:922] -- in other words, when the callback inside Civ2 receives the WM_GETMINMAXINFO, it tries acquiring a DC for some reason, and this causes the crash. Now, I don't know enough about how wine works internall to fix this. Can anyone provide any suggestions? -- Luke Stras <stras(a)utias.toronto.edu> "The meek can have the Earth; the rest of us have other plans" --Henry Spencer

1 0

installshield 6
by Daniel Walker Sept. 29, 2001

Sept. 29, 2001

Is there a specific application that I should be attempting to install ? Or is there a specific version of stdole32.tlb that I need ? Daniel Walker

1 0

Re: InstallShield 6 again (debuggers requested)
by Gerard Patel Sept. 29, 2001

Sept. 29, 2001

At 03:11 AM 29/09/2001 -0700, you wrote: >> Probably only that there's a problem with your setup. For example, perhaps >> you forgot to copy stdole32.tlb from real windows, as instructed? > > > No , I did that.. Well, did you import all the registry entries in winedefault.reg then ? Gerard

3 3

Re: fixme:pthread_kill_other_threads
by Eric Pouech Sept. 28, 2001

Sept. 28, 2001

> 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) if it's the case, it means that the started program rely on some messages order to do some stuff the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

4 4

fixme:pthread_kill_other_threads
by Uwe Bonnes Sept. 28, 2001

Sept. 28, 2001

Hallo, I don't understand why pthread_kill_other_threads ist called when a programm creates a new process. With the pthread_kill_other_threads call, the starting process dies. This is a +relay,+server,+... log: trace:dosfs:DOSFS_GetFullName returning /home/dosd/cae/ql82/scs/TKWDOG.EXE = D:\CAE\QL82\SCS\TKWDOG.EXE 08068938: new_process( inherit_all=0, create_flags=67108864, start_flags=257, exe_file=200, hstdin=4, hstdout=8, hstderr=12, cmd_show=1, filename="D:\cae\ql82\scs\TKWDOG.EXE" ) 08068938: new_process() = 0 { info=204 } fixme:pthread_kill_other_threads_np 08068938: select( flags=12, cookie=0x405c5778, sec=1001624181, usec=913175, handles={204} ) 08068938: select() = PENDING 00000000: *fd* 0 -> 46 08625a70: *fd* 6 <- 46 08625a70: *fd* 8 <- 47 08625a70: init_thread( unix_pid=2070, teb=0x40127ce0, entry=(nil), reply_fd=6, wait_fd=8 ) 08625a70: init_thread() = 0 { pid=0x86259a0, tid=0x8625a70, boot=0, version=53 } This is an strace of that part: 1898 close(28) = 0 1898 chdir("/home/dosd/cae/ql82/scs") = 0 1898 write(2, "fixme:pthread_kill_other_threads"..., 36) = 36 1898 execve("/usr/local/bin/wine", ["/usr/local/bin/wine", "--", "tkwdog.exe"], [/* 57 vars */] <unfinished ...> and I think this relates to scheduler/process.c:fork_and_exec if (newdir) chdir(newdir); if (argv && envp) { if (!filename) { argv[1] = "--"; exec_wine_binary( argv, envp ); } else execve( filename, argv, envp ); } What can happen between chdir() and execve() to trigger the pthread_kill_other_threads() call? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

3 3

Re: _NET_WM_NAME support patch
by Dmitry Timoshkov Sept. 27, 2001

Sept. 27, 2001

"Ilya Konstantinov" <wine-patches(a)future.shiny.co.il> wrote: > This patch adds a _NET_WM_NAME(UTF8_STRING) property to every window, > storing it's title in non-ambigous UTF8 encoding. This is a part of the > NET_WM standard. The UTF8 title feature is currently implemented only > by KWin (KDE's window manager), but is adopted by both GNOME and KDE > camps. @@ -746,12 +748,32 @@ BOOL X11DRV_SetWindowText( HWND hwnd, LP return FALSE; } WideCharToMultiByte(text_cp, 0, text, -1, buffer, count, NULL, NULL); + + count = utf8_wcstombs(text, strlenW(text), utf8_buffer, 0); Why didn't you use win32 call instead of a purely internal one? count = WideCharToMultiByte( CP_UTF8, 0, text, -1, NULL, 0, NULL, NULL ); utf8_buffer = HeapAlloc( GetProcessHeap(), 0, count ); count = WideCharToMultiByte( CP_UTF8, 0, text, -1, utf8_buffer, count, NULL, NULL ); -- Dmitry.

1 0

Problem in installation of Wine on SPARC Solaris 8.0
by Mrugan Bhorkar Sept. 26, 2001

Sept. 26, 2001

I am trying to install Wine on UltraSPARC Solaris 8.0 using tools/wineinstall. The installation script fails at following point...... gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -D__WINE__ -D_REENTRANT -I/usr/openwin/include -o lex.ppl.o lex.ppl.c In file included from ./ppl.l:141: ../../include/config.h:486: warning: `_FILE_OFFSET_BITS' redefined /usr/include/sys/feature_tests.h:96: warning: this is the location of the previous definition ./ppl.l: In function `pplex': ./ppl.l:336: `pplval' undeclared (first use in this function) ./ppl.l:336: (Each undeclared identifier is reported only once ./ppl.l:336: for each function it appears in.) make: *** [lex.ppl.o] Error 1 Can anybody suggest how to fix this?? Thanks Mrugan __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com

1 0

pthread_atfork and PTHREAD_FORK
by Bill Medland Sept. 26, 2001

Sept. 26, 2001

Can someone tell me what we should have here? (It might be interesting to know how it's supposed to work too but that's beside the point). I had a case where pthread_atfork was being called with two null pointers, so it all blew up when PTHREAD_FORK tried to execute the code they pointed to. Is it legal for pthread_atfork to be called with null parameters (in which case I will correct PTHREAD_FORK, otherwise I'll assert the pointers). Bill

2 1

pthread_atfork problems
by Bill Medland Sept. 26, 2001

Sept. 26, 2001

Any chance of a hand with this please? I have just traced a problem to the fact that __pthread_atfork is passed a couple of null pointers, which I presume is an illegal thing to do. Can anyone point me at the code that results in __pthread_atfork being called and/or explain why it would be called with null pointers? TIA Bill

1 0

Re: GetMessageTime
by Alexandre Julliard Sept. 26, 2001

Sept. 26, 2001

"David Hammerton" <david(a)transgaming.com> writes: > BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, > GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the > game Alice seems to make it return 0) - so the value sent to XSetInputFocus for > the time is too small, and hence X refuses to give the window focus. The real fix is that XSetInputFocus should not use GetMessageTime at all, this is only a temporary hack. To conform to the ICCCM the focus time should be based on the timestamp of a previous X event, and the focus should never be changed if we didn't receive an event. To do this right probably requires supporting the take focus protocol, as was discussed some time ago. -- Alexandre Julliard julliard(a)winehq.com

1 0

Getting Routing tables
by Robert Lunnon Sept. 26, 2001

Sept. 26, 2001

In my pitiful attempt to hack on WINE I have come to an impasse. I have managed to find portable equivalents to get the interface name and the number of interfaces in winsock/wsock32 but I can't seem to find a portable way to get to the routing table. In Solaris (why I'm doing the hacking) there is a vague mention in the man pages of being able to get this info by reading /dev/ip but no information about how to actually do it. Can anyone provide a hint on how this can be done portably or to a multi-os implementation of netstat that might serve as an example. (Only netstat sources I have found are OS specific) Hurry because in desperation I am actually thinking of piping the output of netstat -r Thanks Bob

2 1

BeginPaint not called on WM_PAINT...
by Andreas Mohr Sept. 25, 2001

Sept. 25, 2001

Hi all, the game Undying emits lots and lots of err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 20029! errors. This is because it simply does: 0806d2c8:Call user32.DispatchMessageA(406c29b0) ret=1090e313 0806d2c8:Call window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) 0806d2c8:Call user32.ValidateRect(00020029,00000000) ret=11107b57 0806d2c8:Ret user32.ValidateRect() retval=00000001 ret=11107b57 0806d2c8:Ret window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) retval=00000000 This seems to be perfectly legal in order to validate the whole window update rect (NULL) and thus prevent further WM_PAINTs. (as http://www.intrepidhero.com/articles/wgpfd_errata/part2.html hints) In short: the wine error message is erroneous in this case. The Wine check is: if (painting && wndPtr && (wndPtr->flags & WIN_NEEDS_BEGINPAINT) && wndPtr->hrgnUpdate) { ERR("BeginPaint not called on WM_PAINT for hwnd %04x!\n", msg->hwnd); So I assume that either a) some flag or so doesn't get updated properly by that ValidateRect() or b) the error message check condition is (slightly) wrong. Could someone please fix this ? This happened to #WineHQ nick Thunderbird with latest version of winex (20010824). -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

GetMessageTime
by David Hammerton Sept. 25, 2001

Sept. 25, 2001

Hey, Durings my hunting down for why SetFocus wasnt always working, I have traced it back to a problem with GetMessageTime(). (which I have made a temporary fix for, haven't sent it to wine-patches because its not the 'right' way of fixing it) GetMessageTime() is supposed to return the time of the last message received by GetMessage(). But there are two cases where the time set (req->time) is 0 - and I can't fix it. If you turn your eyes to server/queue.c, around line 910 and 926 you will see the two times this value gets set to 0. Statically. I believe the only way to fix this is some sort of restructuring, since GetCurrentTime() (used by all other functions that set req->time) relies on a variable thats not available to the wine server. Anyone else have any suggestions? BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the game Alice seems to make it return 0) - so the value sent to XSetInputFocus for the time is too small, and hence X refuses to give the window focus. As I said i've written a small patch for this, I may send it to wine-patches if its worth it, but I really think that the source of the problem should be addressed more urgently. David. -- David Hammerton, web programmer TransGaming Technologies Inc. http://www.transgaming.com david(a)transgaming.com

1 0

NG: Wine and cyrillic input and output ?
by Dmitry Timoshkov Sept. 25, 2001

Sept. 25, 2001

Hello all. This patch fixes a couple of problems with keyboard group switching reported in the news group: 1. Group switch had never worked before, if the keyboard has been switched outside of Wine. 2. I was clearly stated that Group switch is active if event->state & 0x2000, not event->state & 0x6000. Please test it on your local configurations and report back. If there will be no objections, I'll send it to wine-patches. Thanks. -- Dmitry.

2 3

GetClipboardData
by Dominik Strasser Sept. 25, 2001

Sept. 25, 2001

Hello, with MS WinWord I am encountering the following problem: If there's something selected, GetClipboardData is called. In GetClipboardData, there is the line: HWND hWnd = (hWndClipWindow) ? hWndClipWindow : GetActiveWindow(); hWndClipWindow is 0, so GetActiveWindow() is called which also returns 0. I tracked this down to PERQDATA_GetActiveWnd returning 0. This leads later to "w" bening 0 which results in an X error calling XConvertSelection. It happens in all modes, desktop managed, non managed. Does anybody have any clues ? Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser(a)mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

1 0

Callwave doesn't run
by Steven Walter Sept. 23, 2001

Sept. 23, 2001

Is this a known problem? When I try to run the callwave install program, or the callwave program itself, I merely get: fixme:win32:PE_CreateModule Security directory ignored err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640112 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Is this a configuration error on my part? Either way, is there some information I need to give to get this fixed? I appreciate it. Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell

2 5

Re: wsprintf
by Alexandre Julliard Sept. 21, 2001

Sept. 21, 2001

Jeremy White <jwhite(a)codeweavers.com> writes: > Okay, so it's a slow news day, and I feel like stirring up trouble. Bad boy... > I would argue that it is, in fact, counterintuitive, to have this > sort of comment solely in the change log. The only time I ever think > to look at a diff (or even the change log) is when something has broken > recently. Well, because *you* don't look at it doesn't mean it's not the right place, does it? <g> I look at the CVS history quite often, and I find that in many cases it's the best way to find out why things are done a certain way. I don't see any reason to duplicate this info inside the code itself; since we are using a source control system we might as well take advantage of it. Plus it guarantees the info is stored permanently, unlike a comment that may get moved or lost next time the code is changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wsprintf
by Alexandre Julliard Sept. 21, 2001

Sept. 21, 2001

Aric Stewart <aric(a)codeweavers.com> writes: > I think this is part of what the change log is for. > > Alexandre has committed the patch, i will ask him if he wants me to > document something further and submit another patch. I added a comment in wsprintf16 to make Andreas happy. But I agree that the change log (and cvs diff) is the best way to store this kind of information. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: re-implementing real mode interrupts
by Alexandre Julliard Sept. 21, 2001

Sept. 21, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 > on the VWIN32 device calls to the real mode interrupt INT 13. It could > be re-implemented so that INT_Int13Handler does a DeviceIoControl and > the low level disk access code moved into the VWIN32 device > implemetation. VWIN32_DIOC_DOS_INT_13 is not really different from int 13, so it wouldn't make much difference either way. Much better would be to implement the higher level calls that are needed to reimplement the DOS interrupts; for instance int 13 should use the IOCTL_DISK calls of DeviceIoControl, int 25/26 should be replaced by Win32 device access (CreateFile("\\.\PHYSICALDRIVEx")+Read/WriteFile), etc. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wsprintf
by Andreas Mohr Sept. 21, 2001

Sept. 21, 2001

On Thu, Sep 20, 2001 at 01:38:11PM -0500, Aric Stewart wrote: > The behavior for wsprintfA is different that for wsprintf16 in how it > handles NULLs being passed as character parameters. This patch fixes > that. Hmm, can't you add a small comment inside the code that actually mentions this remarkable difference ? I think we should make every effort possible to ensure that important differences between architectures are being preserved as well as possible. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

2 1

Re: Better font charset handling
by Huw D M Davies Sept. 21, 2001

Sept. 21, 2001

On Fri, Sep 21, 2001 at 03:46:29PM +0200, Nerijus Baliunas wrote: > On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > > HDMD> Huw D M Davies <hdavies(a)codeweavers.com> > HDMD> Use the font charset to obtain a codepage for A->W conversion in the > HDMD> text functions. > > HDMD> Index: objects/text.c > > HDMD> + case VISCII_CHARSET: > HDMD> + case TCVN_CHARSET: > HDMD> + case KOI8_CHARSET: > HDMD> + case ISO3_CHARSET: > HDMD> + case ISO4_CHARSET: > HDMD> + case ISO10_CHARSET: > HDMD> + case CELTIC_CHARSET: > HDMD> + /* FIXME: These have no place here, but becasue x11drv > HDMD> + enumerates fonts with these (made up) charsets some apps > HDMD> + might use them and then the FIXME below would become > HDMD> + annoying. Now we could pick the intended codepage for > HDMD> + each of these, but since it's broken anyway we'll just > HDMD> + use CP_ACP and hope it'll go away... > HDMD> + */ > HDMD> + cp = CP_ACP; > HDMD> + break; > > Why these are here? Because they do not have windows equivalents? > If so, at least KOI8 shouldn't be there (IMHO). AFAIK they're not Windows charsets, somebody has made up some numbers and added them to wingdi.h . The reason they're here at all is because the x11drv enumerates fonts with these charsets and I'm claiming that this is a bug, since no application can be expected to know that these numbers mean. Now there is a RUSSIAN_CHARSET and this gets handled by the TranslateCharsetInfo before the switch. Huw.

1 0

Re: Better font charset handling
by Nerijus Baliunas Sept. 21, 2001

Sept. 21, 2001

On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: HDMD> Huw D M Davies <hdavies(a)codeweavers.com> HDMD> Use the font charset to obtain a codepage for A->W conversion in the HDMD> text functions. HDMD> Index: objects/text.c HDMD> + case VISCII_CHARSET: HDMD> + case TCVN_CHARSET: HDMD> + case KOI8_CHARSET: HDMD> + case ISO3_CHARSET: HDMD> + case ISO4_CHARSET: HDMD> + case ISO10_CHARSET: HDMD> + case CELTIC_CHARSET: HDMD> + /* FIXME: These have no place here, but becasue x11drv HDMD> + enumerates fonts with these (made up) charsets some apps HDMD> + might use them and then the FIXME below would become HDMD> + annoying. Now we could pick the intended codepage for HDMD> + each of these, but since it's broken anyway we'll just HDMD> + use CP_ACP and hope it'll go away... HDMD> + */ HDMD> + cp = CP_ACP; HDMD> + break; Why these are here? Because they do not have windows equivalents? If so, at least KOI8 shouldn't be there (IMHO). HDMD> + default: HDMD> + FIXME("Can't find codepage for charset %d\n", lf.lfCharSet); HDMD> + break; Regards, Nerijus

1 0

Re: winsock socket.c patch fixes issues with halflife's multicasting
by Francois Gouget Sept. 21, 2001

Sept. 21, 2001

On 21 Sep 2001, David Hammerton wrote: > it seems there we're a few (bugs/typos) in dlls/winsock/socket.c which > prevented binding of ports when using multicast, or something along those > lines. > heres a small patch which fixes it. Please, user -u when you do a diff: * it makes it easier to see what the patch changes * it makes it easier to find the location you changed in the file. None of my copies of socket.c match yours so all the line offsets are off * it is more robust if you want to apply the patch to a modified version of the file (translation Unified diff formats actually have a chance to apply properly, yours does not) So I suggest you put the following line in your .cvsrc: diff -u All this is also explained there: Wine Developper's Guide: "Submitting Patches" http://wine.codeweavers.com/docs/wine-devel/patches.shtml#PATCH-FORMAT That said I must appologize: I am the one who broke this piece of code. A very bad case of copy/paste. Sincere appologies. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

re-implementing real mode interrupts
by Mike McCormack Sept. 21, 2001

Sept. 21, 2001

Hi, I was wondering if it would be a Good Thing to start re-implementing real mode interrupts using Win32 calls. For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 on the VWIN32 device calls to the real mode interrupt INT 13. It could be re-implemented so that INT_Int13Handler does a DeviceIoControl and the low level disk access code moved into the VWIN32 device implemetation. This would better seperate the DOS and Win32 implementations. Any thoughts? Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Implementation of SPI_GETSHOWSOUNDS action in SystemParametersInfo
by Gerard Patel Sept. 20, 2001

Sept. 20, 2001

At 02:34 PM 20/09/2001 -0400, you (Andriy Palamarchuk <apa3a(a)yahoo.com>) wrote: >File: windows/sysparams.c <snip> use diff -u See: http://www.winehq.com/dev.shtml (section : patches) Gerard

1 0

Re: min/max and types
by Francois Gouget Sept. 20, 2001

Sept. 20, 2001

On Tue, 18 Sep 2001, eric pouech wrote: [...] > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > provide lots of errors. integral promotions are straightforward, and > behave as expected by any programmer. so it would be rather ugly IMO > to write something like min((int)s, i) (s being short and i int) But in this last example, wouldn't it be better to declare s as an int or i as a short? Then we would not need a cast. I believe we would rarely be forced to really compare integers of different sizes. Of course the only way to be sure is to really look at the actual warnings... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

3 2

GetSystemMetrics / SetSystemMetrics ?
by Andriy Palamarchuk Sept. 20, 2001

Sept. 20, 2001

Question: How to update metrics data returned by GetSystemMetrics function? Problem: Currently I'm implementing some easiest FIXMEs (e.g. SPI_GETSHOWSOUNDS) in function SystemParametersInfo. GetSystemMetrics is used to return information for a few types of SPI_GETxxx actions from this function, including the action I'm working on. Logic for corresponding SPI_SETxxx actions is not implemented and contains commented out calls to SetSystemMetrics. As I understand this comment is a mark that corresponding GetSystemMetrics data should be updated in this place. GetSystemMetrics returns data from array sysMetrics. I did not find any function which provides update access to the array. Can you advise how to deal with this problem? Regards, Andriy Palamarchuk

1 0

Quicktime 5.0.x / XVideo usage
by Matthias Dahl Sept. 20, 2001

Sept. 20, 2001

Hey there... ]) powered by Linux 2.4.8 ([ I have discovered some strange behavior with WINE and Quicktime 5.0.x. As long as the "time slider" and the "audio bars" are being updated the video runs quite sluggish. But if you open a menu or a dialog box both the "time slider" and the "audio bars" stop updating - which is normal. BUT the video itself runs at full speed as long as both are not being updated. Which is kinda strange I guess. Even those animation content which is included with some movs doesn't slow the playback down, so it cannot be a performance issue. (on PIII with 500 Mhz, 256 MB ram and X 4.1.x (G400MAX)) Also if you maximize the video to full screen or anything that is not its original size, the playback also becomes very sluggish. Doesn't WINE use the XVideo protocol for such operations? By the way. I am using yesterday's CVS checkout without any windows DLLs. I'll happily provide more informations - just let me know what you need. Last but not least. All you guys are doing a great job -- and I wanted to take the opportunity to say THANK YOU to you all. :-) -- So long, Matt ]) matthew2k(a)web.de, GPG key available at public keyservers ([

3 4

[Problem report] SetWindowWord creates infinite loop
by Gerard Patel Sept. 19, 2001

Sept. 19, 2001

The following change in SetWindowWord + + WIN_ReleaseWndPtr(wndPtr); + switch(offset) { - case GWW_ID: ptr = (WORD *)&wndPtr->wIDmenu; break; - case GWW_HINSTANCE: ptr = (WORD *)&wndPtr->hInstance; break; - case GWW_HWNDPARENT: retval = SetParent( hwnd, newval ); - goto end; - default: - WARN("Invalid offset %d\n", offset ); - retval = 0; - goto end; + case GWL_ID: + case GWL_HINSTANCE: + case GWL_HWNDPARENT: + return SetWindowLongW( hwnd, offset, (UINT)newval ); + default: + WARN("Invalid offset %d\n", offset ); + return 0; } creates an infinite loop as SetWindowLong calls WIN_SetWindowLong, that calls SetWindowWord for the GWL_HINSTANCE case. Gerard

1 0

Re: [Problem report] SetWindowWord creates infinite loop
by Alexandre Julliard Sept. 19, 2001

Sept. 19, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > The following change in SetWindowWord > [...] > creates an infinite loop as SetWindowLong calls WIN_SetWindowLong, > that calls SetWindowWord for the GWL_HINSTANCE case. Oops, sorry about that. It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: min/max and types
by Eric Pouech Sept. 19, 2001

Sept. 19, 2001

> > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > > provide lots of errors. integral promotions are straightforward, and > > behave as expected by any programmer. so it would be rather ugly IMO > > to write something like min((int)s, i) (s being short and i int) > > But in this last example, wouldn't it be better to declare s as an > int or i as a short? Then we would not need a cast. > I believe we would rarely be forced to really compare integers of > different sizes. Of course the only way to be sure is to really look at > the actual warnings... well, the warnings I looked at come of three kinds (for that's for from being exhaustive): - comparing the dwSize of a struct with the sizeof of the struct. The first being a DWORD, the second of type size_t. Using the macro means using a cast here, which I find rather ugly - comparing an unsigned int with an explicit integer : min(4, u). This could be rewritten easily into min(4u, u) for example - real potential problems with comparing unsigned char with signed short for example. IMO, the first two ones shouldn't require type casts. last but not least, I think that the basic issue here is that gcc should report a sign mismatch in the comparison... and it doesn't. If it did, we wouldn't be arguing on the matter... A+ > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly. > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

Re: DDE and postmessage
by eric pouech Sept. 18, 2001

Sept. 18, 2001

Alexandre Julliard wrote: > > eric pouech <eric.pouech(a)wanadoo.fr> writes: > > > I've started looking at the inter-process DDE message management > > as of today, PostMessage doesn't use the packing strategy used by > > SendMessage (rightfully because of possible dangling pointer issue > > if pointers are used in message parameters) > > > > however, some DDE messages need to send additional information > > even when posting (copying all data), and DDE protocol requires > > posting messages (SendMessage is banned) > > > > do you have any plan to handle this ? > > I don't really have any plan yet. We clearly need to do a special case > for posted DDE messages; a possibility would be to use an internal > message with SendMessage to send the data across before posting the > actual DDE message. There is an undocumented message similar to > WM_COPYDATA that can be used to transfer a global memory block across > processes, which is used for stuff like WM_DROPFILES; it doesn't work > right now but I'm planning to implement it soon. This would add a > synchronisation point that may defeat the purpose of the PostMessage > though. If this is a problem we can probably add a DDE-specific server > call to transfer the data what I had in mind was somehow reusing the message packing capabilities of SendMessage for PostMessage. Moreover, we need to handle large memory chunks to be exchanged in SendMessage, so we could kill two birds with one stone. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Dialog painting
by Gerard Patel Sept. 18, 2001

Sept. 18, 2001

At 12:35 AM 11/09/2001 +0300, you wrote: > >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 have looked at your source. With current Wine, expose X events are retrieved from the X server when Wine has nothing else to do. These events are setting the update region. CreateWindow does not set the update region in current Wine, even if the window is visible. This is the point that matters for your problem I think. hSplash = CreateDialog (hInstance, MAKEINTRESOURCE(IDD_SPLASH), NULL, Splash_DlgProc); SetForegroundWindow(hSplash); // here the update region is nil (Wine problem !) UpdateWindow(hSplash); // --> nothing is displayed. Sleep(5000); // events are retrieved from the X server queue. printf("Removing splash.\n"); DestroyWindow(hSplash); Your code does not display anything because no message is retrieved from the message queue. After the Sleep call, WM_PAINT messages are available, but as you don't retrieve them by calling PeekMessage or something like that, nothing is shown. I don't want to say that your app code is wrong, of course. There is a problem in Wine, but I don't know what to do about it. My first thought would be to scan the X queue and retrieve the expose events as was done before the great changes of this summer, but this may be somewhat difficult to do right. I prefer to waste my time searching for other problems, because I have no doubt that Alexandre Julliard is aware of this one and it's clear that he is not finished yet with X code reorganization. Gerard

2 1

RE: dlls/advapi32/crypt.c
by Patrik Stridvall Sept. 17, 2001

Sept. 17, 2001

> Vladimir Vukicevic <vladimir(a)ximian.com> writes: > > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > > necessary -- there's no reason why two implementations of CryptoAPI > > can't be done, one using the gcrypt backend, one using OpenSSL. > > Granted, this is a duplication of effort, but I think there > is enough > > interest that it shouldn't be too difficult to do both. > Also, it's easy > > enough to ship two different advapi32.so's, or even create an > > intermediate cryptoapi layer that supports plugins, so that > the option > > always remains with the distributor or user whether to go with a GPL > > implementation, a BSD implementation, or even a commercial > > implementation. > > As far as the main tree is concerned, everything has to be under the > Wine license (or compatible). It's not acceptable to depend on a > library that would impose extra conditions on the Wine/Winelib > user. The problem is what constitutes extra conditions is extremly vague. If you have a Winelib application that don't for example use say any crypto functions, you really can't be said either to use or to derive a new work from a completely unused and/or unnessary library. If you do use any crypto function, well, whether that imposes any extra conditions is an extremely difficult legal issue that really can't be answered without a real court case. It might depend on whether the use is optional but it might not. That is what I have been trying to point out in my recent messages. So just saying that "I don't want any libraries that imposed extra conditions on the Wine/Winelib user" is not really a very informative answer. What you mean is (I guess): 1. No use of libraries under the GPL or other viral licenses 2. No use of commersial libraries (end user and/or developer must pay for it) Or do you mean something else? Anyway see below. > And this is not solved by having a choice between two different > sets of extra conditions. Note that you always have the choice of NOT using crypto. If Wine didn't include a working crypto implementation that would be the only choice wouldn't it? As long as it doesn't effect the performance or maintainabillity of Wine in negative way more choices are always better than less IMHO.

1 0

Monkey Island 3 install
by Johan Gill Sept. 17, 2001

Sept. 17, 2001

After some testing, I've found that the installation of Curse of Monkey Island works fine if winver=win98 is specified. What made the win95 install break was this: --- /opt/cvs-commit/wine/misc/version.c 2001/07/02 19:59:49 1.43 +++ /opt/cvs-commit/wine/misc/version.c 2001/07/27 23:57:38 1.44 @@ -75,7 +75,7 @@ }, /* WIN95 */ { - 0x07005F03, + 0x07000304, 0xC0000004, { sizeof(OSVERSIONINFOA), 4, 0, 0x40003B6, If that is a correct fix, the real problem is to be found somewhere else. /Johan Gill, johane(a)lysator.liu.se

1 0

RE: dlls/advapi32/crypt.c
by Patrik Stridvall Sept. 17, 2001

Sept. 17, 2001

> On Sat, 2001-09-15 at 02:12, Patrik Stridvall wrote: > > In short. GPL:ed Winelib applications is not our concern > > and we shouldn't IMHO make it one beyond making sure > > that all linking to non GPL compatible libraries is optional. > > > > GPL:ed libraries is, as said above, a different story, that > > from a legal point of view is an unresolved issue. The "answer" > > of that question regardless of what it will be, will, be very > > important since it might, unless it is too vague, define the > > boundaries of copyright in a more definite way. > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > necessary -- there's no reason why two implementations of CryptoAPI > can't be done, one using the gcrypt backend, one using OpenSSL. > Granted, this is a duplication of effort, but I think there is enough > interest that it shouldn't be too difficult to do both. > Also, it's easy > enough to ship two different advapi32.so's, or even create an > intermediate cryptoapi layer that supports plugins, so that the option > always remains with the distributor or user whether to go with a GPL > implementation, a BSD implementation, or even a commercial > implementation. It is not the effort that is the real problem. The problem is that since ADVAPI32 might use libgcrypt (that is GPL:ed library) it possible to for a non-GPL:ed Winelib application to indirectly via the ADVAPI to "link" to libgrypt. This would violate the GPL:ed in some meaning. Of course the authors of the Winelib application might be entirely unaware of this fact but it is still teoretical violation. This is, of course, in some meaning absurd, but ask yourself this: What meaning have the GPL for libraries if you can just wrap a intermediate library with a GPL compatible license (like Winelib:s ADVAPI "library") around it and circumvent the GPL? Of course a distinct possibility exists that a court of law will find that the GPL (as applied to libraries) is meaningless or at least meaningless in the case of Wine. But are you willing to be the defendent in a test case? Alexandre is not. Still IMHO even in the worst case what will likely happend is that. 1. Richard Stallman (or somebody else) sends a GPL violation notice. 2. Slashdot debate the case and possibly hang us out. :-) 3. We will discuss on the list what to do and possible remove the offending code. 4. If we do not the debate on Slashdot and elsewhere will continue 5. If we still persist the chances that we will be sued is still quite small since A) The cases of winning is close to zero B) There is little or no chance to profit even regardless of this. Of course there is moral aspect of this but ask yourself this: "Is it immoral to shatter somebodies unrealistic expectations?" In short there is no legal risk at all IMHO but Alexandre has said earlier that he doesn't want code using GPL:ed libraries if not to protect himself or the Wine project, so to protect possible users of Wine if not from legal issues so from bad PR. > There's also something to be said for following Microsoft's API for > crypto back-ends, so that proprietary back-ends (i.e. those > dealing with > hardware keys, etc.) could function within the wine cryptoapi > framework. > In this case, each individual provider (RSA, DSS, etc.) would then be > implemented either in terms of gcrypt, or OpenSSL, or libcrypt, or any > other. That is probably a good idea. But you can't use libgcrypt at least not without asking the libgcrypt authors if it is OK that Wine(lib) uses libgcrypt despite the fact that it makes it possible for non-GPL:ed Winelib applications to indirectly use libgcrypt. And you better ask Alexandre whether is OK with him to include the code under such circumstances.

1 0

RE: dlls/advapi32/crypt.c
by Patrik Stridvall Sept. 17, 2001

Sept. 17, 2001

> Patrik Stridvall wrote: > > > > > 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. > > I think that Vladimir's suggestion that OpenSSL could be > used as an alternative back end did not recieve sufficient > attention. He wasn't sure that that was a good approach > given the fact that it would arguably cause difficulty for > people who wanted to run GPLed apps on top of Wine+OpenSSL. Well. If we only permit linking with libraries that have GPL compatible licenses, we will seriously limit our choices. Sure I, since GPL is a dominant license, fully agree that all linking to non-GPL:ed libraries should be optional. Of course the question of what is optional is vague too. See below. Also note that this is an entirely different issue than the issues concerning GPL:ed libraries. In the case above it is 100% clear that only the distributor of the GPL:ed application can have any legal liabillities for possible violation of the GPL. It is not out immediate concern. Beside since they, because of the GPL, must have the source code they can always disable things like crypto that might not have a 100% GPL compatible Winelib implementation. In short. GPL:ed Winelib applications is not our concern and we shouldn't IMHO make it one beyond making sure that all linking to non GPL compatible libraries is optional. GPL:ed libraries is, as said above, a different story, that from a legal point of view is an unresolved issue. The "answer" of that question regardless of what it will be, will, be very important since it might, unless it is too vague, define the boundaries of copyright in a more definite way. However, I'm a little afraid of that for the GPL to be truely meaningful, especially in the case of Wine, you will have define the boundaries of copyright a little to strict for my liking. > Since the number of GPLed Windows apps that do not have Linux > counterparts is vanishingly small, the OpenSSL option seems to > me more appropriate than using a libgcrypt back end. The > OpenSSL license does not have the viral properties that the > GPL has (it's an old-style BSD-type license, complete with the > advertising clause), and therefore we should be able to weak-link > Wine with libOpenSSL without any license contamination. Agreed. > Packagers > who distribute libOpenSSL with Wine would then be responsible > for meeting the OpenSSL license requirements for advertising > and attribution. Of course but that is not our immediate concern, the same would be if we link with any proprietary library. Any distributor of such libraries whether in conjuction with Wine(lib) or seperately must of course fullfull the licensing requirements of such libraries (including but not limited to pay any license fees). Actually in some meaning we already do, since proprietary implemenatations of both X Windows and OpenGL exists and Wine(lib) will happily dynamically link with them and use them if they exists. Wine(lib):s use of them obviously do not gives any license to distribute them, but that is not our concern. This of course raises they question if we mandatorily link to libraries, like X Windows or OpenGL, that both have GPL and non-GPL compatible implemtations: Do we optionally or mandatorily link to a non GPL compatible library? Does this matter from a legal perspetive as concerning whether a Winelib user violate the GPL or not? In addition does it matter whether the GPL compatible library is: 1. Complete 2. Close to complete 3. Has only basic functionallity 4. Unusably buggy 5. Unimplemented stubs 6. In the planing state 7. A theoretical construction In that case why?

2 1

DDE and postmessage
by eric pouech Sept. 16, 2001

Sept. 16, 2001

(mainly for Alexandre) I've started looking at the inter-process DDE message management as of today, PostMessage doesn't use the packing strategy used by SendMessage (rightfully because of possible dangling pointer issue if pointers are used in message parameters) however, some DDE messages need to send additional information even when posting (copying all data), and DDE protocol requires posting messages (SendMessage is banned) do you have any plan to handle this ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

RE: dlls/advapi32/crypt.c
by Patrik Stridvall Sept. 15, 2001

Sept. 15, 2001

> 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 Sept. 15, 2001

Sept. 15, 2001

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 Sept. 14, 2001

Sept. 14, 2001

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 Sept. 14, 2001

Sept. 14, 2001

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 Sept. 14, 2001

Sept. 14, 2001

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 Sept. 14, 2001

Sept. 14, 2001

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 Sept. 14, 2001

Sept. 14, 2001

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 Sept. 14, 2001

Sept. 14, 2001

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 Sept. 13, 2001

Sept. 13, 2001

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 Sept. 13, 2001

Sept. 13, 2001

-----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 Sept. 13, 2001

Sept. 13, 2001

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 Sept. 13, 2001

Sept. 13, 2001

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 Sept. 13, 2001

Sept. 13, 2001

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 Sept. 12, 2001

Sept. 12, 2001

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 Sept. 12, 2001

Sept. 12, 2001

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 Sept. 12, 2001

Sept. 12, 2001

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 Sept. 12, 2001

Sept. 12, 2001

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 Sept. 12, 2001

Sept. 12, 2001

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 Sept. 12, 2001

Sept. 12, 2001

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 Sept. 11, 2001

Sept. 11, 2001

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 Sept. 10, 2001

Sept. 10, 2001

> 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 Sept. 10, 2001

Sept. 10, 2001

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 Sept. 10, 2001

Sept. 10, 2001

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 Sept. 10, 2001

Sept. 10, 2001

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 Sept. 10, 2001

Sept. 10, 2001

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

Dialog painting
by Niclas Karlsson MATE Sept. 10, 2001

Sept. 10, 2001

Hello! Wine currently seems to have a problem painting splash dialogs properly (or at all). Is this a known problem (with a known cause)? An open source program exhibiting problems of this kind would be Speak Freely (http://www.fourmilab.ch/speakfree/windows/) I will try to single out the cause of the problem when I get a little spare time, unless the cause is already known that is. Also, I haven't used Wine for some time so I don't know if this is a long-standing problem. The version I used was a cvs snapshot from last friday before the commits. Cheers, Nicke -- -[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)

1 0

Monkey Island 3
by Johan Gill Sept. 9, 2001

Sept. 9, 2001

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

1 0

what if MS is forced to publish all API's?
by Scott Bradford Sept. 9, 2001

Sept. 9, 2001

with all the discussion going on in the press about what to do with Microsoft to remove their Monopoly power or at least see to it that they don't abuse their power, how to folks here feel about forcing them to release all their API's? I'm not a programmer myself, but it's my understanding that not having access to the API's is what makes wine such a challenge. If this is the case, would getting access to the MS API's allow Wine to be completed? I feel that a MS breakup wouldn't have done much to change things because they can still give information only to whom they choose, leaving MS to decide who can play and who can't. Having other ways to run the application base of windows software would remove the need to run windows itself, and in my mind, this is the easiest way to remove monopoly power of MS. What do you folks, the Wine developers, think should be done to MS?

1 0

Focus livelock
by Jukka Heinonen Sept. 9, 2001

Sept. 9, 2001

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. This happens repeatably every time you start Colonization for Windows. I'm currently thinking about calling directly some WINPOS_* routine from X11 FocusIn handler instead of SetForegroundWindow. If the routine acted exactly like SetForegroundWindow except it made sure that it causes no calls to X11DRV_SetFocus, focus problem would be fixed. Unfortunately I have not figured any good way to pass an extra flag to default handler for WM_ACTIVATE, so that the routine would call something like SetFocus_DontCallDriver instead of regular SetFocus... -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: Option to disable XVidMode
by Ove Kaaven Sept. 8, 2001

Sept. 8, 2001

On Fri, 7 Sep 2001, François Gouget wrote: > > I had a report of a crash and it turned out to happen during the > XVidMode initialization. > What happened is that for some unknown reason XF86VidModeGetAllModeLines > returned a single mode with a width and/or height of zero > (htotal/vtotal). This caused a division by zero in convert_modeline. Last time this happened, we considered this a bug in the X server, as under these circumstances, xvidtune also crashes. > Then will come the work of trying to reproduce the problem and see > how best to deal with this server (XFree86-SVGA 4.1.0 apparently). I don't think such a server exists. There's either XFree86 4.x with loadable driver modules, or there's XFree86-SVGA 3.x. The latter sounds more likely to have this kind of bug.

2 2

Re: ukrainian layout
by Dmitry Timoshkov Sept. 8, 2001

Sept. 8, 2001

"Andy Rysin" <arysin(a)yahoo.com> wrote: > Also I had to modify unicode/cp20866.c (KOI8-R) to allow conversion > of additional 4 pair of letters in Ukrainian language (KOI8-U, > RFC2319) as well as one additional pair of letters for Belorussian > language (AKA KOI8-RU, which does not have RFC though). > Strictly speaking KOI8-R is a subset (if not to take to account > pseudographics) of KOI8-U wich is a subset of KOI8-RU. > That's why I applied it to cp20866.c instead of creating smth new. > (I took it from my patches for linux kernel nls system) You can't modify cp*.c files, they are auto generated from the unicode.org file set. You need to send your patch to the unicode.org maintainers and hopefully it will be included in the next Unicode Standard release. > Another problem is that I could not test it practiacally because for > some reason Win32 programs under wine does not input cyrillic > letters, but if I swicth to X program and then back it stops input at > all if layout is cyrillic. If I swicth back to latin everything's ok. It's a known problem, that Wine's x11 keyboard driver does not work with "non-sticky" switches. I have tested cyrillic input with XFree86 3.3.6, 4.0.3 and 4.1.0 with KDE and KiKbd, all works fine for me. Proper support for non-sticky modifiers, dead-keys and the real keyboard layout support requires almost complete keyboard driver rewrite. > BTW, why not to take layouts from X system itself? > Those wich are under /etc/X11/xkb/symbols Because XFree86 is not the only X11 implementation out there. -- Dmitry.

2 2

Re: Make cmdline writable (cmdline4)
by Alexandre Julliard Sept. 8, 2001

Sept. 8, 2001

Francois Gouget <fgouget(a)free.fr> writes: > In the case below. Works on Win98 but not in Wine. I believe the > reason is that Windows does not need to modify the command line anyway. In some cases it does; for instance your test program should fail under NT when using Unicode. Do you have a real app that requires this? -- Alexandre Julliard julliard(a)winehq.com

3 2

WM_[LR]BUTTON{DOWN,DBLCLK} in menus
by Bobby Bingham Sept. 7, 2001

Sept. 7, 2001

I was writing a stupid app to help my friend learn to use menus in windows apps. It would call TrackPopupMenu on a WM_LBUTTONDOWN message. After some experimentation, I found that if I leftclicked in the client are, the menu would appear, as it should. But if, while the menu was still active, I leftclicked in the window's nonclient area (titlebar), the menu would appear elsewhere. By clicking the menu receives a WM_LBUTTONDOWN message, and determines that it should close the menu as it's not inside the menu, and it doesn't remove the message. This is normally fine, but if the click falls on the nonclient area of a window, the message should not be passed through. I believe this also applies to WM_LBUTTONDBLCLK, and the right button equivalents. Is there an easy way to determine what window the click would be passed through to, so we can check if it'll be in the client area or not? Bobby Bingham -- Microsoft Windows: Made for the internet The Internet: Made for UNIX

1 0

Re: Problems with WM_PAINT and threads
by Alexandre Julliard Sept. 7, 2001

Sept. 7, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > After Wine dispatches this WM_PAINT message from the wrong thread, > 3DMark2000 fails to locate its thread-local data, gets confused, and > crashes. Does this help? Index: windows/win.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/win.c,v retrieving revision 1.147 diff -u -r1.147 win.c --- windows/win.c 2001/08/29 00:16:00 1.147 +++ windows/win.c 2001/09/07 19:34:24 @@ -387,15 +387,17 @@ hwndRet = pWnd->hwndSelf; /* look among siblings if we got a transparent window */ - while (pWnd && ((pWnd->dwExStyle & WS_EX_TRANSPARENT) || - !(pWnd->hrgnUpdate || (pWnd->flags & WIN_INTERNAL_PAINT)))) + while (pWnd) { + if (!(pWnd->dwExStyle & WS_EX_TRANSPARENT) && + (pWnd->hrgnUpdate || (pWnd->flags & WIN_INTERNAL_PAINT)) && + GetWindowThreadProcessId( pWnd->hwndSelf, NULL ) == GetCurrentThreadId()) + { + hwndRet = pWnd->hwndSelf; + WIN_ReleaseWndPtr(pWnd); + break; + } WIN_UpdateWndPtr(&pWnd,pWnd->next); - } - if (pWnd) - { - hwndRet = pWnd->hwndSelf; - WIN_ReleaseWndPtr(pWnd); } TRACE("found %04x\n",hwndRet); return hwndRet; -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Bugs involving returning strings from API functions
by Alexandre Julliard Sept. 7, 2001

Sept. 7, 2001

"Justin Santa Barbara" <justinsb(a)hotmail.com> writes: > As I see it, the advantage of a helper function is that for about the same > amount of work of fixing GetSystemDirectory and GetCurrentDirectory, all the > functions should work the same way meaning any bugs would quickly be found. > It might also be possible to optimize the case where buflen=0, while this > isn't practical per-function. Should I offer a patch only for wine/files/* > ? I'm afraid there are too many variations to make this useful. It would be nice if all APIs that return strings behaved the same way, but unfortunately this is not the case: some count the terminating null, some don't, some copy partial strings when the buffer is too small, some don't copy anything, etc. We would need about as many helpers as there are API functions. Also be aware that the MSDN doc cannot be trusted at all on this matter, the correct behavior needs to be verified for each function. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Make cmdline writable (cmdline4)
by Alexandre Julliard Sept. 7, 2001

Sept. 7, 2001

Francois Gouget <fgouget(a)free.fr> writes: > No I don't have a 'real world' exemple where this is a problem. I > became aware of the issue because of warnings when I was working on > dlls/msvcrt/process.c: system is const char* so I made msvcrt_spawn > const char* but then I had to add a cast when calling CreateProcessA > (see second hunk of cmdline3). The cast is wrong, we should do a copy there. CreateProcess takes a char*, not a const char*. Casting off the const and relying on CreateProcess to not modify the string is broken. Even better would be to convert the string to Unicode and call CreateProcessW; this would avoid a copy (well, right now it will cost an extra copy, but that's because CreateProcess should be fixed to do everything in Unicode). -- Alexandre Julliard julliard(a)winehq.com

2 1

Wine for OS X?
by Tyler Vano Sept. 7, 2001

Sept. 7, 2001

Hi All, I'm new to this list (and to Wine itself) but was wondering, is there a project in the works to port Wine to Mac OS X (www.apple.com/macosx)? OS X *is* based on FreeBSD (albeit with a bunch of new fluff for compatibility & aqua), so a port shouldn't be that difficult. (650,000 lines of code and the guy says it 'shouldn't be difficult.') Personally, I think the eventually payoff would be well worth it. You'd get the entire community of ecstatic Mac users, drunk with the power of being able to run Windows apps directly on their Macs (without VPC.) Just like Linux/Unix, Apple's custom Mach3 kernel (aka Darwin) is Open Sourced. Just curious. - Tyler www.creysoft.com __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com

2 1

Re: Make cmdline writable (cmdline4)
by Alexandre Julliard Sept. 7, 2001

Sept. 7, 2001

Francois Gouget <fgouget(a)free.fr> writes: > CreateProcess may modify the command line that was passed as a > parameter. It does this not in the current process but in the child > process so that the caller may not realize it, but it may hit a snag if > the command line is not writable in the first place. But the command line parameter is a LPSTR, so CreateProcess is allowed to modify it and the caller is not supposed to pass a const string. In what case does this cause a problem? -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: CryptoAPI
by Patrik Stridvall Sept. 6, 2001

Sept. 6, 2001

> > Beside the GPL doesn't cover use, only distribution, so if the user > > would install a Winelib that uses a GPL library that would be > > completely legal as far as that user would be concern despite the > > fact that he has a non-GPL:ed application that uses Winelib. > > Hmm, if only distribution is covered, then can we still write > code for a GPL > library (use) as long as the library isn't shipped with wine > and test for it > on the user's system? Well, actually since the Wine license is GPL compatible that is not a problem either. The problem is that some 3rd party might use Winelib for an application that has non-GPL compatible license. See below. > > However Alexandre has clearly expressed that he doesn't want Wine > > to be a legal test bed, if not primarily for the legal issues, so > > because he doesn't want an unsuspecting company using Winelib be > > "cruficed" on Slashdot or wherever for alleged GPL violation. :-) > > > > While I, in some meaning, agree, I do not believe that we should > > refrain from doing so because of fear of what might never be. > > Obviously we should turn off the use of any GPL:ed library > by default. > > I tend to agree with Alexandre and suggest little or no work > in this area > proceed until the legal debate is over. It seems only best > for the project > to avoid the possibility of legal action against us, > especially for something > we don't fully understand. As far as the Wine source code is concerned the debate as over as it can be without a real court case. The Wine license is GPL compatible so saying that the Wine source code violates the GPL is ridiculous. So what you have to claim is that the Wine source code facillitates others to violate the GPL. This is ridicioulous too for other reasons, foremost because none of requirements of contributary or vicarious (sp?) is even remotely fullfilled. As far as the binaries are concerned, well, the Wine project itself doesn't distribute binaries so it doesn't matter as far as the project is concerned. OK it links to others binaries but claiming liabillity for that is ridiculos too. So far the Wine project. As for other people, well no one really knows since there are very few (if any) relevant court cases on the subject. However consider this, that is actually not a hypotetical situation at all. Even if it is, it still illustrates an example. IIRC when Corel ported Corel Office it used some sort of font rendering library made by Bitstream IIRC. The library cost money to use, but the use of library was optional. If you had it was used if not you didn't get as good fonts as otherwise. So does Corel Office violate Bitstream's copyright? Obviously not, no sane court would claim that and beside Bitstream haven't and won't sue because they benefit from the sitution since now consumers has one more reason to buy their product. Beside that will make it a much harder for them to show damages since their are none. That covers pretty much the use of all normal commersial libraries. In short they have no reason to sue and no chance of success either. Now enter the GPL. The problem is that GPL has an entirely different goal than normal commersial licenses. The commersial library developers wants as many users as possible since each legal user pays money for their product and even illegal users might help them to make the library more widely spread and more of a defacto standard that will likely generate more users (both legal and illegal) in the long run. Note that they normaly don't care what license any user of library distributes his code under either. In short they don't make any difference between different users as long as they are paid. The copyright holder a GPL:ed library on the other hand have no intrest in that software under non-GPL compatible licenses uses their library. This is a fundmental difference. On the other hand the GPL is a distribution not a use license. Paradox? :-) I could speak about this much longer but the point what is legal or what is not is entirely dependent on: 1. Is the GPL is virus that can infect users of the code? 2. If it is a virus, to what extent does the infection spread. Put is another way: GPL:ed libraries discriminates again different kinds of users (developers and end user). The commersial libraries does not normaly do that. Whether and how far copyright law permits this is IMHO one of the most fundamental unresolved questions for open source software development. Even worse. Note that a ruling a _either_ direction have enormous implications for the future of open source software so keep that in mind. "United we stand, divided we fall." Another small note if you are less hostile to the GPL you could say that the GPL is not a virus it is a contract. However all copyright is a contract between the author and society question what contract takes predence is still revelant and unresolved. However if you see the problem with Wine project use of GPL:ed for a contract perspective you could in addition argue that you never have accepted the contract since you didn't have to since you didn't redistribute or modify the library and claim Wine and derived work of the library is rediculous. > > Anyway, unless or until Alexandre changes his mind, I think that > > you should submit all general code that needn't use a specific > > library and distribute that rest as a patch. Preferable so > > that Winelib could dynamically load it so it could be > > distributed seperately in binary form as well. > > Hmm, I never thought about libgcrypt, but if we can somehow > use it legally > then it could be a possible back-end as opposed to or > inconjunction with > OpenSSL. Naturally, I would prefer not to re-invent the > wheel by having to > re-write every needed algorithm used in the M$ API, if we can > find a library > that is legal in all circumstances :-! Use of all normal commersial libraries are "legal" as shown above, at least if you only distribute your Winelib application. Only the GPL and similar viral license can be a problem. > But has anyone considered the following: > -Writing code that interfaces with either OpenSSL or > libgcrypt depending on > what the USER (or any winelib developer) requires AND has > installed on their > system. Providing this is legal. From what I understand > this *should* be > legal long as we're not DISTRIBUTING whatever is illegal to do so. Most probably yes. The only issue as I can see it is how far the GPL extends. > -Use OpenSSL by default if it is more compatible with our own license. > -Disabling the cryptoAPI to winelib developers by default to > make them aware > of these issue and allow them to choose the interface that > matches their > requirements. > -Provide adequate documentation that discusses these points > and touches the > legalities of this software. > > One thing we should probably do no matter what is contact the > developers for > both OpenSSL and libgcrpyt and make them aware of out situation. (and > possibly see which one or both is willing to bend on their > license(s)). That is probably a good idea. > Oh and one other possibility may be to find a way to modify > our own license > such that it fits this problem. Since only GPL libraries AFAICS can be a problem and our license it already GPL compatible that not possible (or needed). > However, I'm not sure how > willing Alexandre > or any of us are about doing this (...again?, I think it's > has been done > before). Well I don't know. Ask him. However he is currently away so that will have to wait I guess. Anyway what you suggested above is fine by me.

1 0

RE: Problem with specmaker
by Patrik Stridvall Sept. 6, 2001

Sept. 6, 2001

> "Guy L. Albertelli" wrote: > > > > Recently had a problem with specmaker not generating > prototypes. Traced it > > down to a problem in function_grep.pl. > > > > If the following lines are in a .h file, no prototypes > after them are > > recognized. Removing the lines from the .h file allows the > prototype to be > > generated: > > > > #define IShellIcon_METHODS \ > > ICOM_METHOD3(HRESULT, GetIconOf, \ > > LPCITEMIDLIST,pidl, UINT,flags, LPINT,lpIconIndex) > > > > I suspect that the preprocessor elimination did not expect multiline > > condition. Well, it knows about multiline directives but it doesn't handle all case properly. > > I don't know perl so I cann't fix it. > thanks for sending the pb to me, but I didn't wrote that part at once > (I just recently upgraded specmaker with some dump facilities) > it seems however that the perl script only allow one backslash for > multiline extensions but fails with more than one > since Patrik seemed to have written this part at once (and it > could/should > be shared with the wineapi suite, I borrowed (cut and paste) code from the winapi suite then I was writing function_grep.pl. It is a crude hack but it works (sort of at least). And yes, function_grep.pl will be part of the winapi suite eventually but probably not in the next few months, but you never know. > I think he's the best suited for the > fix... ;-) Indeed. Here is a working fix I think (not tested). I found a bug in winapi_check a while ago but the fix didn't find its way the function_grep.pl it seems. The problem might also be that there is whitespace after on of the \:es. This is forbidden by ANSI C but most compilers accept it anyway. 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 @@ -60,11 +60,12 @@ if(/^\s*$/) { next; } # remove preprocessor directives - if(s/^\s*\#/\#/m) { - if(/^\#.*?\\$/m) { + if(s/^\s*\#/\#/s) { + if(/^\#.*?\\\s*\n/s) { $lookahead = 1; next; - } elsif(s/^\#\s*(.*?)(\s+(.*?))?\s*$//m) { + } elsif(s/^\#\s*\w+(?:\s+(.*?))?\s*$//s) { + $again = 1; next; } }

1 0

RE: CryptoAPI
by Patrik Stridvall Sept. 6, 2001

Sept. 6, 2001

> > > However, OpenSSL's license is incompatible with the GPL, > hence any GPL'd > > > applications that wish to use an OpenSSL-backed CryptoAPI > implementation > > > would be unable to do so. > > > > I'm not so sure about this. Question: is it possible to > write GPL'd > > software under Windows that links into, say, USER32.DLL? > Answer: yes, > > because USER32.DLL is considered part of the operating system. > > It might be that cryptoapi's dll is also considered part of > the win32 > > operating system api, thus allowing even gpl'd apps to dynamically > > link to it without violating the gpl. > > Sure, but I think it's a fine line to walk.. The Microsoft-provided > ADVAPI32.DLL is considered part of the OS, but the API itself is not. > If you were to create a replacement ADVAPI32.DLL for use > under Windows, > I don't think it would be legal for GPL apps to link with it; but hey, > IANAL, as they say. In any case, the line is even blurrier with wine, > since wine itself isn't part of the OS -- so someone wanting to port a > GPL'd windows app [for the sake of argument let's pretend that some > exist ;-)] to Linux using winelib might have issues. This issue has been discussed before (see mailing list archive). I think that the general consensus is that the GPL certainly could be interpreted (and indeed likely to be interpreted by a court) as not covering such cases as above, especially since the GPL obviously do not cover a GPL:ed application on Windows it would be ridiculous to make it legal distribute Wine and a Windows binary but not Winelib and make it illegal to do that with a Linux binary that dynamicly links to whatever version of Winelib installed of the system. The fact that a version of Winelib might exist that links to a GPL:ed library is a ridiculous ground for an court case. You might as well argue that distribution of any Windows binary is illegal since somebody might run it on a illegal (pirated) version of Windows. Beside the GPL doesn't cover use, only distribution, so if the user would install a Winelib that uses a GPL library that would be completely legal as far as that user would be concern despite the fact that he has a non-GPL:ed application that uses Winelib. That would effectively close any "have no legal uses" argument eventhough that argument is ridiculous regardless of this since even though no non-GPL:ed Wine implementation of CryptoAPI currently exists the application might be used with limited functionality until such time or that matter use the real ADVAPI.DLL from a legally bought copy of Windows instead. Beside I don't think any copyright holder of a GPL library would dare sue the Wine project or any user of Winelib, even disregarding their non existing chances of success, because of PR reason. However Alexandre has clearly expressed that he doesn't want Wine to be a legal test bed, if not primarily for the legal issues, so because he doesn't want an unsuspecting company using Winelib be "cruficed" on Slashdot or wherever for alleged GPL violation. :-) While I, in some meaning, agree, I do not believe that we should refrain from doing so because of fear of what might never be. Obviously we should turn off the use of any GPL:ed library by default. Anyway, unless or until Alexandre changes his mind, I think that you should submit all general code that needn't use a specific library and distribute that rest as a patch. Preferable so that Winelib could dynamically load it so it could be distributed seperately in binary form as well.

2 1

Re: dsound fix in wineoss
by eric pouech Sept. 6, 2001

Sept. 6, 2001

eric pouech wrote: > > for some (unexplained yet reasons), my libc implementation for memset > reads the content of the buffer it's supposed to fill > since the buffer passed in dsound init has only write access (it's > needed > for OSS in order to know it's a buffer for recording or playing), some > seg fault occurs > > I wrote it the easiest way (I don't think it's worth adding a configure > test for that) > > so I replaced the memset by a hand made equivalent > > (btw: libc 2.1.3 as shipped by Mandrake 7.2 ; bug has been submitted to > Mdk QA site, still waiting for some acknowledgement) ok.. got some feedback from the mandrake folks regarding this bug I'm looking for someone with a Mandrake 8.1 installed to test if the bug has been fixed in later release of mdk... any volunteer ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Problem with specmaker
by Guy L. Albertelli Sept. 6, 2001

Sept. 6, 2001

Recently had a problem with specmaker not generating prototypes. Traced it down to a problem in function_grep.pl. If the following lines are in a .h file, no prototypes after them are recognized. Removing the lines from the .h file allows the prototype to be generated: #define IShellIcon_METHODS \ ICOM_METHOD3(HRESULT, GetIconOf, \ LPCITEMIDLIST,pidl, UINT,flags, LPINT,lpIconIndex) I suspect that the preprocessor elimination did not expect multiline condition. I don't know perl so I cann't fix it. Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

Problem
by Borut Rozman Sept. 5, 2001

Sept. 5, 2001

I was fooling arround with wine installation and now have a big problem, Firstly I had problems with size of my disk so I downloaded a RPM file from wine.dataparty.no glibc2-RPM (requirements): Latest stripped build: wine-cvs-stripped-090401-1.i386.rpm Latest unstripped build: wine-cvs-unstripped-090401-1.i386.rpm these two, then I could not make it running so I downloaded a gzip and make a new fresh one and it comes upto this level : Compiling regapi... gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/X11R6/include -o regapi.o regapi.c ld -r regapi.o -o regapi.tmp.o strip --strip-unneeded regapi.tmp.o LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -sym regapi.tmp.o -o regapi.spec.c -spec ./regapi.spec gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/X11R6/include -o regapi.spec.o regapi.spec.c gcc -shared -Wl,-Bsymbolic regapi.spec.o regapi.o -o regapi.so -L../../library -lwine -lncurses -lm -lutil -ldl rm -f regapi && ln -s ../../wine regapi Preparing to install default Wine registry entries... Installing default Wine registry entries... wine client error:0x80685e8: version mismatch 48/51. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? Registry install failed. so u see it is some client/server error and now I cant go further plz help me out ! regards PS : Read too much of RTFM :P

3 3

this could be interesting for wine producers
by Igor Sept. 4, 2001

Sept. 4, 2001

Pavel Machek suggested GPLing the netwarefs tools, or no one would be able to use the source. Jeff replied, "I will cross mount the manos server to the FTP server this evening. This server has all of the source code for the entire TRG archive. I'll put all of it up this evening. It will be mounted off of /archive in the ftp home area. It also contains all of the Microsoft source code for all of our W2K file systems work. If it's helpful to anyone, they are welcome to it." Pavel reiterated, "Putting it off /archive is not enough, it does not make it GPLed. Those tools that are usefull should be marked with GPL so it is *legal* to use them. (You might also consider creating sourceforge.net project and putting your stuff there ;-)" Jeff replied, "It's all GPL, even the MS code. Sourcefroge is a great idea. I'll look into it." found here: http://kt.zork.net/kernel-traffic/kt20010903_131.html#4

1 0

Bugs involving returning strings from API functions
by Justin Santa Barbara Sept. 4, 2001

Sept. 4, 2001

There are a group of functions in the kernel that appear to be broken in that they don't follow the Windows API specification. The general convention for these functions is as follows: The function is called with a pointer to a buffer and the size of the buffer, and returns the number of characters copied to the buffer, excluding the null terminator, unless the buffer is too small when the total size in characters of the buffer needed (with a null terminator) is returned. If the buffer is too small, the string is not copied at all. Several functions that I have spotted don't implement this correctly - particularly ones in files/directory.c. eg GetSystemDirectory. They count the Null Terminator. A typical symptom of this is that an installation program attempts to call LoadLibrary on "C:\\WINDOWS\\SYSTEM", because it's appended eg "OLE32.DLL" after the null character. This is one of the problems when installing the Microsoft installer, for example. While looking for other functions that might do the same thing, I came across this: /*********************************************************************** * GetCurrentDirectoryW (KERNEL32.@) */ UINT WINAPI GetCurrentDirectoryW( UINT buflen, LPWSTR buf ) { LPSTR xpath = HeapAlloc( GetProcessHeap(), 0, buflen+1 ); UINT ret = GetCurrentDirectoryA( buflen, xpath ); if (ret < buflen) ret = MultiByteToWideChar( CP_ACP, 0, xpath, -1, buf, buflen ) - 1; HeapFree( GetProcessHeap(), 0, xpath ); return ret; } But HeapAlloc takes a number of bytes, whereas buflen is in (two-byte) characters. ie a small buffer would appear to crash this code. (right?) While I have succesfully patched these bugs on my machine, I'm not sure that going through and looking for every function that may be broken in some similar way and changing them one-by-one is a good way to proceed. These bugs all have to do with returning strings - it would probably be better to attempt to have functions that 'copy out an ANSI string' or 'copy out a UNICODE string' according to this API. Without meaning to be critical, the problem appears to be that the same functionality has been written many times throughout the code, and so multiple and different bugs have crept in. However, I'm quite new to using wine, and so would like the advice and opinions of those more experienced. My questions: 1) Is there a design reason why a single common function for string copying is not used? Maybe something to do with separate libraries, some of which may be replaced by native windows DLLs? Maybe someone more knowledgeable than myself could direct me as to the best place to put the helper function implementations. 2) Would writing these string helper functions and changing (most) string-returning functions to use them be worthwhile (or indeed even welcome)? 3) Is there a move to using UNICODE internally in the kernel that means that this would be best combined with some other effort? Certainly if this were an eventual design goal then using helper functions would make that job a little easier. Comments? Justin SB

2 3

CryptoAPI
by Travis Michielsen Sept. 3, 2001

Sept. 3, 2001

Hi, I was going to start implementing the Cypto API (in advapi32.dll) over the next few weeks. As of yet these functions are no more than stubs. However, I am finding increased use of this API as more applications becomed networkable and relying more heavily on internet connections. I was hoping to implement these functions by using the OpenSSL library (if/when available). This library seems to have similar capabilities. One of my concerns is about legal issues. What special concerns should I note about cryptographic software? Are there any special copyright issues I should be aware of? Another question is about design. M$ seems to split the cryptographic software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). Should I do this as well so that, applications can use the native dlls if necessary or should I simply implement it entirely though advapi32.dll which and avoid the need to create several new (and very small) dlls under wine? Because most of the code is already in another library (OpenSSL) creating extra dlls seems abit unnecessary. - Travis _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

3 4

Two threads waiting for a critical section
by Uwe Bonnes Sept. 3, 2001

Sept. 3, 2001

Hallo, appended log seems fishy to me: trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 (0) trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d34a0 (fs 01cf, pid 15616) count before 0 (1) ^^^^ ^^^^^^^^ trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d5280 (fs 07bf, pid 15623) count before 0 (2) ^^^^ ^^^^^^^^ trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_EnterSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 3 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 2 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 2 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 1 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count before 1 trace:win32:_LeaveSysLevel (0x4010f7d4, level 1): thread 0x96d41a0 (fs 02d7, pid 15615) count after 0 (3) err:ntdll:RtlpWaitForCriticalSection section 0x4010f7d4 "syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) fs=07bf err:ntdll:RtlpWaitForCriticalSection section 0x4010f7d4 "syslevel.c: Win16Mutex" wait timed out, retrying (5 min) fs=07bf At (0) 0x96d41a0 holds the Mutex. At (1) 0x96d34a0 tries to get it, but as 0x96d41a0 has the Mutex, it waits. At (2) 0x96d5280 also tries to get the lock and must also wait. At (3) 0x96d41a0 releases the lock, but neither 0x96d34a0 nor 0x96d5280 start to aquire the lock. Why doesn't one of them continue? This happens with the installer from the recent RS Components CD-ROM running SETUP.EXE with --winver nt40. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

' ' & '"' handling in the command line
by Francois Gouget Sept. 2, 2001

Sept. 2, 2001

Hi, Some time ago I realized that the command line handling in Wine did not work properly when arguments with spaces or double-quotes are involved. For instance I would start a Wine application like this: main "a b" c and it would tell me something like this: GetCommandLine=[./main a b c] Or I would call CreateProcess(... "main \"a b\" c" ...) and main would get: main -> argc=4 0 [./main] 1 [a] 2 [b] 3 [c] So I investigated this and found that * double-quotes, '"', have the same meaning in win32 as in unix (tested on Win95 & Win2000) * backslash, '\', work as on unix, especially wrt double-quotes * single-quotes, ''', have no special meaning So CreateProcess(... "main \"a b\" c" ...) should give me: GetCommandLine=[./main "a b" c] main -> argc=3 0 [./main] 1 [a b] 2 [c] I searched for places where we convert command lines to argv lists and reciprocally and modified them to work as on windows. With this patch things should be correct, whether you call a Wine application from Unix, from another Wine application via CreateProcess, or if you call a Unix application from Wine. There's just one little bit in the msvcrt code which I treated in a separate patch (p20010902-cmdline2.diff). In the process I wrote a few test applications: * hello regular hello world unix app * main A Wine console application which dumps its argc/argv and then calls GetCommandLine, ... You can also call it with a '-i' parameter to test CommandLineToArgvW, except that _getws is not implemented in Wine so you can only do that on windows * winmain A Wine Gui application which dumps lpCmdLine and then calls __getmainargs, CommandLineToArgvW(GetCommandLineW), ... * createp Which reads a command line from stdin and calls CreateProcess with it * spawnv Reads a list of arguments from stdin and calls spawnv with it (spawn* don't handle ' ' and '"', see p20010902-cmdline3.diff) * spawn Same but the command is fixed I know that there has been discussions about the command line handling before and that some applications do very weird things. Please test this patch and let me know how it goes. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: pe format
by Dan Kegel Sept. 2, 2001

Sept. 2, 2001

tiago r wrote: > From: Dan Kegel <dank(a)kegel.com> > > > tiago r wrote: > > > i know this doesn't got direct link with wine development, but i was wondering if someone has a complete reference of the portable executable format including BOUND_IMPORT_DIRECTORY description. > > > > google finds > > http://www.microsoft.com/hwdev/hardware/PECOFF.htm > > http://www.windowsitlibrary.com/Content/356/11/1.html > > http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile.html > > http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/pefile2.html > > In fact all of this (and other) documents describe the pe format but none of them describe the BOUND_IMPORT_DIR. Hmm. Searching for BOUND_IMPORT with google yields two links: http://www.radsoft.net/gallery/bv/ http://members.internettrash.com/astalalista/ac/pe_tut2.html plus one hit on groups.google.com (a guy doing a minimal hello_world.exe mentioned it). Maybe try asking on comp.lang.asm.x86, or some microsoft group... - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

1 0

pe format
by tiago r Sept. 1, 2001

Sept. 1, 2001

i know this doesn't got direct link with wine development, but i was wondering if someone has a complete reference of the portable executable format including BOUND_IMPORT_DIRECTORY description. regards, Tiago -- _______________________________________________ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Talk More, Pay Less with Net2Phone Direct(R), up to 1500 minutes free! http://www.net2phone.com/cgi-bin/link.cgi?143

2 1

Race condition?
by lawson_whitney＠juno.com Sept. 1, 2001

Sept. 1, 2001

Good day! My app just crashed, after I logged in and dismissed its modal nuisance ad. Normally it doesn't, so I guess this might be some kind of race condition? Here is a backtrace, in case it might be useful. If not, sorry for the noise. Oh, load order is: [DllOverrides] "*" = "builtin, so, native" [AppDefaults\\juno.exe\\DllOverrides] "msvcrt" = "native" "riched32" = "native" Haven't seen anything on wine-cvs since 29 August, but the local wine is up to that. No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42LOC.DLL' (0x76020000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RICHED32.DLL' (0x6c000000) Unhandled exception: page fault on read access to 0x2e6873f4 in 32-bit code (0x5f404eca). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x5f404eca (MFC42.DLL.2028+0xf in C:\AWAY\BIN\MFC42.DLL): cmpl $1,0xfffffff4(%eax) Wine-dbg>bt Backtrace: =>0 0x5f404eca (MFC42.DLL.2028+0xf in C:\AWAY\BIN\MFC42.DLL) (ebp=405b5b88) 1 0x15030f38 (JSESSION.DLL.2914+0x30d8 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5ca0) 2 0x150257a3 (JSESSION.DLL.2141+0xad3 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5cb4) 3 0x1502c816 (JSESSION.DLL.2606+0x766 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5e54) 4 0x1502d27a (JSESSION.DLL.2606+0x11ca in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5edc) 5 0x150249f9 (JSESSION.DLL.2039+0x699 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b5f7c) 6 0x15049088 (JSESSION.DLL.3948+0x988 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b6088) 7 0x1502d45a (JSESSION.DLL.2707+0x5a in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b61ac) 8 0x150241e8 (JSESSION.DLL.2035+0x88 in C:\AWAY\BIN\JSESSION.DLL) (ebp=405b61f4) 9 0x0042aff0 (juno.exe..text+0x29ff0 in C:\away\bin\juno.exe) (ebp=405b623c) 10 0x5f4019f0 (MFC42.DLL.5163+0x31c in C:\AWAY\BIN\MFC42.DLL) (ebp=405b62bc) 11 0x5f4016b2 (MFC42.DLL.6374+0x22 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b62dc) 12 0x5f40163b (MFC42.DLL.1109+0x71 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b633c) 13 0x5f4015c6 (MFC42.DLL.1578+0x2a in C:\AWAY\BIN\MFC42.DLL) (ebp=405b6358) 14 0x5f40157d (MFC42.DLL.1579+0x39 in C:\AWAY\BIN\MFC42.DLL) (ebp=405b6384) 15 0x40665a07 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b63a8) 16 0x40665a8d (WINPROC_CallWndProc+0x7d(proc=0x5f401544, hwnd=0x6005d, msg=0x403, wParam=0x0, lParam=0x0) [winproc.c:172] in libuser32.so) (ebp=405b63d8) 17 0x4066b417 (CallWindowProcA+0x93(func=0x40d31c44, hwnd=0x6005d, msg=0x403, wParam=0x0, lParam=0x0) [winproc.c:2639] in libuser32.so) (ebp=405b6400) 18 0x4064e822 (DispatchMessageA+0xd6(msg=0x4920dc) [message.c:922] in libuser32.so) (ebp=405b6444) 19 0x5f401226 (MFC42.DLL.5307+0x3a in C:\AWAY\BIN\MFC42.DLL) (ebp=004920dc) 20 0x00000403 (ebp=0006005d) Wine-dbg>info local MFC42.DLL.2028: Wine-dbg>up 15 Wine-dbg>info local WINPROC_wrapper: Wine-dbg>up 172 retvalue = WINPROC_wrapper( proc, hwnd, msg, wParam, lParam ); Wine-dbg>info local WINPROC_CallWndProc: long int(*none)()* proc == 0x5f401544 unsigned int hwnd == 0x0006005d unsigned int msg == 0x00000403 unsigned int wParam == 0x00000000 long int lParam == 0x00000000 unsigned int hwnd (optimized into register $edi) == 0x00000003 long int retvalue == 0x00000000 int iWndsLocks (optimized into register $esi) == 0x410f84ac long unsigned int ret (optimized into register $eax) == 0x2e687400 long unsigned int ret (optimized into register $eax) == 0x2e687400 Wine-dbg>up 2639 return WINPROC_CallWndProc( proc->thunk.t_from16.proc, Wine-dbg>info local CallWindowProcA: long int(*none)()* func == 0x40d31c44 unsigned int hwnd == 0x0006005d unsigned int msg == 0x00000403 unsigned int wParam == 0x00000000 long int lParam == 0x00000000 unsigned int wParam (optimized into register $edi) == 0x00000003 long int lParam (optimized into register $esi) == 0x410f84ac struct tagWINDOWPROC* proc (optimized into register $eax) == 0x2e687400 Wine-dbg>up 922 retval = CallWindowProcA( (WNDPROC)wndPtr->winproc, Wine-dbg>info local DispatchMessageA: struct tagMSG* msg == 0x004920dc struct tagMSG* msg (optimized into register $edi) == 0x00000003 struct tagWND* wndPtr (optimized into register $esi) == 0x410f84ac long int retval == 0x004920a8 int painting == 0x00000000 Wine-dbg> Regards, Lawson ---oof---cut here---- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0