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