January 2002 - Wine-Devel - list.winehq.org

Re: _UNICODE vs UNICODE

by Francois Gouget

On Mon, 21 Jan 2002, Andriy Palamarchuk wrote: > Francois Gouget wrote: > > On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > > > Using macro name "UNICODE" instead of "_UNICODE" > is a > > > typo, right? > > > > No, not necessarily. Windows has both and > dinput.h, > > for instance, > > uses UNICODE, not _UNICODE. > > > > But I have no idea why they have two. > > I did a little research and found in a few places > information that UNICODE is used by Windows headers, > _UNICODE is used by C-runtime/MFC headers. However I > did not find official explanation of this. > Some examples, including a few MSDN ones, define both. > E.g. see: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_e… > > Can you tell now where we need to use which one? All Windows headers use UNICODE except the following which also make references to _UNICODE: * msacm.h This one does something like: #if defined(UNICODE) && !defined(_UNICODE) #define _UNICODE #endif * edk.h This one defines _UNICODE if UNICODE is defined, but then it will only test UNICODE! * oledlg.h This one will make sure that if one of UNICODE or _UNICODE is defined, then the other one is defined too. * bdnapi.h, dbdao.h, tchar.h These only test _UNICODE * sqlole.h This one tests both and defines SQLOLE_UNICODE to simplify further tests. It's a big mess if you ask me. The reason why there is no official explanation is that there was simply no design. But currently our headers all do the right thing (tchar.h uses _UNICODE and msacm.h uses neither for now). The Petzold mentions that you need _UNICODE for tchar.h and UNICODE for the other headers but does not go into why this was done this way. All it says is to define both if you are writing a Unicode application. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Jan. 21, 2002

Re: GetPrivateProfileInt*() fix

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > these functions were pretty much broken (overflow and signed/unsigned > behaviour), so I fixed almost every problem. Why did you add an exception handler? Do you have an app that passes garbage pointers to GetPrivateProfileInt? -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: Unnecessary imports?

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > There is one case where this seems to be the true. But in most of the > others I would find it surprising. I would rather suspect that the dll > used to import some wine-specific API from kernel32 but no longer does. Some of the imports are needed for other platforms; there are a number of functions that get inlined on i386 but not on other CPUs, so you need the import to compile there. Also some functions like the critical section ones are temporarily #defined to point to ntdll but they should actually be imported from kernel32, and will be when all the dlls import kernel32 properly. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

On Mon, 21 Jan 2002, Martin Wilck wrote: > I can't make sense out of these traces. The numbers of bytes transferred > are different, but you were transferring different data. > The general pattern of function calls and messages is very similar > with and without the patch. Especially the error patterns are similar. I didn't look at them very carefully, but yes, they did look kind of awfully similar in that way. ... > > The app seems to be using WSAAsyncSelect() and WS_ioctlsocket() a lot, > perhaps my patch conflicts with those. I can't think of a reason, though, > because the app is doing everything synchronously. > > Can you recommend me a few (16 and 32 apps) Winsock apps that are freely > downloadable and reported to run under Wine? Juno seems to be bound > to a certain provider, so I'd rather not go for that one now. Hmmm, wouldn't, say ftp and telnet and so on use winsocks? I basicaly don't have any 32 bit windows stuff except juno, but I have somewhere on a tar.gz WFW 3.11 that I think will have all those little apps in 16 bit versions I can mail you if you like. Maybe even some 32 bit ones from a freebie AOL CD. I guess any windose browser would use winsocks, too, netscrape if you want a big app, but I think to start ftp or telnet might be easier to test in controlled conditions. I have 32 bit ftp.exe and telnet.exe - maybe wfw 3.11 didn't come with those? Juno is bount to a provider, but the basic mail service is free. > > If you have time, a simultaneous tcpdump might clarify things a bit. > But I guess I need to rework my stuff before I send out others for testing > again. > I'll see if I can do some useful tests. > > I sent this by juno 4 without trace: > > That means nothing because I didn't touch the sending code :-( > Any time I send something, the app looks for something to receive too. Anyway, it won't consider a send done unless it receives an acknowledgement, I think. > > Did you try without trace once or several times? Just once, I think. > > Thanks again for you efforts, > Martin > > Btw I don't think I can help with the serial app. I see no indication > that overlapped IO plays a role there. > Lawson

Jan. 21, 2002

C testing framework. ASCII/Unicode portable version

by Andriy Palamarchuk

Attached version of the C testing framework, which is implemented with using TCHAR.H macros, so it is portable between ASCII and Unicode platforms. Also implemented test which can be used to test ASCII and Unicode API. As I found out creating ASCII/Unicode portable code requires much more attention than creating plain ASCII-only code, probably the same level of difficulty as creation Unicode-only code. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 21, 2002

Re: Some musings about DGA2 support in Wine...

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > All this leads now to the 10 ¤ (an Euro sign for all the people not having > an iso8859-15 font :-) ) question : how to fix this 'properly' and not with > the hack I just did ? It seems the right thing is to setup DGA in the thread that needs to receive the events, using the normal thread display. But this will require understanding exactly why doing other X calls on this display breaks event processing, and finding a work around for that. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2002

Re: _UNICODE vs UNICODE

by Andriy Palamarchuk

Francois Gouget wrote: > On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > > Using macro name "UNICODE" instead of "_UNICODE" is a > > typo, right? > > No, not necessarily. Windows has both and dinput.h, > for instance, > uses UNICODE, not _UNICODE. > > But I have no idea why they have two. I did a little research and found in a few places information that UNICODE is used by Windows headers, _UNICODE is used by C-runtime/MFC headers. However I did not find official explanation of this. Some examples, including a few MSDN ones, define both. E.g. see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_e… Can you tell now where we need to use which one? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 21, 2002

Re: Unnecessary imports?

by Francois Gouget

On Mon, 21 Jan 2002, Ove Kaaven wrote: > > On Mon, 21 Jan 2002, Francois Gouget wrote: > > > Compiling Wine I noticed many warnings saying that the dlls we import > > are not used. Is there any reason to still import them? > > I suppose it could in many cases be because someone *plan* to import stuff > from there sometime later (after they've churned out some code to fill the > stubs in the dll implementation with)... There is one case where this seems to be the true. But in most of the others I would find it surprising. I would rather suspect that the dll used to import some wine-specific API from kernel32 but no longer does. In any case, if it does not yet use kernel32 then there does not seem to be any point in importing it now. Possibly put it in a comment to note that we will likely one day have the dependency. But AFAICS, doing it right now only generates useless warnings. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Jan. 21, 2002

Re: struct async-private - now tested and cleaned up

by Mike McCormack

Hi Martin, Each DLL should only import standard win32 api functions exported by other (lower level) DLLs. Where possible, the code should be able to be compiled and run on a windows box. (ok, that excludes kernel, gdi, user, winsock, etc). That is necessary to support dll=native linking. In theory, we should only have to implement ntdll and the device driver interfaces, then Microsoft's kernel, gdi, user, etc. would all run on top of those too. Practically, some of our low level DLLs need the wineserver interface. Your client side register_async() func should be present in all the dlls that use it because Windows has no equivilent export from NTDLL (or any other dll). Maybe you could create an inline function in a header? My guess is that WinNT implements WSARecv() and ReadFile() using something like NtReadFile(). http://www.osr.com/ntinsider/1996/native.htm Mike > On 16 Jan 2002, Alexandre Julliard wrote: > > > Also note that because of dll separation you cannot use functions like > > register_async() from winsock. If absolutely necessary they could be > > exported, but I think it would be much better to use straight server > > calls (and in theory these functions shouldn't be used from comm.c > > either). > > Hmm. I guess I don't fully understand dll separation. Are you telling me > that the scheduling mechanism for async requests shouls be implemented > separately in each DLL? If so, I could have spared my efforts to build > a "generic" interface to async requests. I'd just mention that > this would be error-prone, because different parts of wine with > equivalent functionality would need to be maintained. Note > that an app is allowed to mix ReadFile() and WSARecv() calls > for a socket (however braindead that would be). I'd assume that > in Windows there must be a hidden layer for asynchronous requests > somewhere, too, or do you think their respective code is completely > separate? ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Jan. 21, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by Martin Wilck

On Thu, 17 Jan 2002 lawson_whitney(a)juno.com wrote: > > Perhaps I screwed up the blocking semantics of non-overlapped IO. > That's what it looks like to me. I can't make sense out of these traces. The numbers of bytes transferred are different, but you were transferring different data. The general pattern of function calls and messages is very similar with and without the patch. Especially the error patterns are similar. If the connection is sluggish anyway, the increased overhead through two more function calls should be negligible. Blocking shouldn't be an issue since the sockets seem to be nonblocking ones. The app seems to be using WSAAsyncSelect() and WS_ioctlsocket() a lot, perhaps my patch conflicts with those. I can't think of a reason, though, because the app is doing everything synchronously. Honestly I don't know how to proceed from here. Obviously I should do some testing of my own before reposting. Can you recommend me a few (16 and 32 apps) Winsock apps that are freely downloadable and reported to run under Wine? Juno seems to be bound to a certain provider, so I'd rather not go for that one now. If you have time, a simultaneous tcpdump might clarify things a bit. But I guess I need to rework my stuff before I send out others for testing again. > I sent this by juno 4 without trace: That means nothing because I didn't touch the sending code :-( > The app reported it failed to fetch my mail, try again later. > I tried again with a winsock trace, and it succeeded, producing socks.gz Did you try without trace once or several times? Thanks again for you efforts, Martin Btw I don't think I can help with the serial app. I see no indication that overlapped IO plays a role there. -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 21, 2002

MapVirtualKeyExA fixme

by John Atkinson

I've been using an app that the shortcut keys don't work, I get the following messages. fixme:keyboard:MapVirtualKeyExA (17,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (68,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (18,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (90,0,0x04090409), hkl unhandled! Does anyone know how to fix this type of problem. TIA

Jan. 21, 2002

Re: small configure patch

by Ove Kaaven

On Mon, 21 Jan 2002, Andreas Mohr wrote: > On Sun, Jan 20, 2002 at 09:49:49PM +0100, Ove Kaaven wrote: > > Index: wine/configure.in > > diff -u wine/configure.in:1.1.1.25 wine/configure.in:1.50 > > --- wine/configure.in:1.1.1.25 Wed Jan 16 10:58:58 2002 > > +++ wine/configure.in Fri Jan 18 09:28:22 2002 > > @@ -253,6 +281,14 @@ > > ) dnl *** End of X11/Xlib.h check > > > > dnl Check for the presence of OpenGL > > + > > + if test -e /usr/X11R6/lib/libGL.a -a ! -e /usr/X11R6/lib/libGL.so > > + then > > + AC_MSG_ERROR( > > +[/usr/X11R6/lib/libGL.a is present on your system. > > +This prevents linking to OpenGL. Delete the file and restart configure.]) > > + fi > > Umm, doesn't this get cached in config.cache ? No. AC_MSG_ERROR aborts the configure run outright (one thing I expect might cause Alexandre to reject it), so no cache file would be generated after this error.

Jan. 21, 2002

Re: Fix for the web site (WineHQ)

by James Juran

Andreas Mohr wrote: > > On Mon, Jan 21, 2002 at 01:28:33AM -0800, Francois Gouget wrote: > > > > This fixes a bug in the Web site: a pre tag was not closed properly. > Committed. Mea Culpa! Thanks for fixing this, Francois and Andreas. James -- James Juran jamesjuran(a)alumni.psu.edu

Jan. 21, 2002

Re: Unnecessary imports?

by Ove Kaaven

On Mon, 21 Jan 2002, Francois Gouget wrote: > Compiling Wine I noticed many warnings saying that the dlls we import > are not used. Is there any reason to still import them? I suppose it could in many cases be because someone *plan* to import stuff from there sometime later (after they've churned out some code to fill the stubs in the dll implementation with)...

Jan. 21, 2002

Re: Fix for the web site (WineHQ)

by Andreas Mohr

On Mon, Jan 21, 2002 at 01:28:33AM -0800, Francois Gouget wrote: > > This fixes a bug in the Web site: a pre tag was not closed properly. Committed. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 21, 2002

Re: struct async-private - now tested and cleaned up

by Martin Wilck

On 16 Jan 2002, Alexandre Julliard wrote: > Also note that because of dll separation you cannot use functions like > register_async() from winsock. If absolutely necessary they could be > exported, but I think it would be much better to use straight server > calls (and in theory these functions shouldn't be used from comm.c > either). Hmm. I guess I don't fully understand dll separation. Are you telling me that the scheduling mechanism for async requests shouls be implemented separately in each DLL? If so, I could have spared my efforts to build a "generic" interface to async requests. I'd just mention that this would be error-prone, because different parts of wine with equivalent functionality would need to be maintained. Note that an app is allowed to mix ReadFile() and WSARecv() calls for a socket (however braindead that would be). I'd assume that in Windows there must be a hidden layer for asynchronous requests somewhere, too, or do you think their respective code is completely separate? What would be the "clean" way in theory? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 21, 2002

Re: small configure patch

by Andreas Mohr

On Sun, Jan 20, 2002 at 09:49:49PM +0100, Ove Kaaven wrote: > Log: > Andrew Lewycky <andrew(a)transgaming.com> > Ove Kaaven <ovek(a)transgaming.com> > Check for common broken nVidia+Mesa OpenGL library setups. > Add some quoting. > > Index: wine/configure.in > diff -u wine/configure.in:1.1.1.25 wine/configure.in:1.50 > --- wine/configure.in:1.1.1.25 Wed Jan 16 10:58:58 2002 > +++ wine/configure.in Fri Jan 18 09:28:22 2002 > @@ -253,6 +281,14 @@ > ) dnl *** End of X11/Xlib.h check > > dnl Check for the presence of OpenGL > + > + if test -e /usr/X11R6/lib/libGL.a -a ! -e /usr/X11R6/lib/libGL.so > + then > + AC_MSG_ERROR( > +[/usr/X11R6/lib/libGL.a is present on your system. > +This prevents linking to OpenGL. Delete the file and restart configure.]) > + fi Umm, doesn't this get cached in config.cache ? Shouldn't we therefore add to delete config.cache before restarting, too ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 21, 2002

Re: SetEndOfFile fix

by Andreas Mohr

On Sun, Jan 20, 2002 at 08:13:53PM +0100, Rein Klazes wrote: > hi, > > This fixes office 97 MSword error (disk full or write protected) when > saving files on a vfat partition. MSword calls SetEndOfFile() which > uses ftruncate() that, in Linux, cannot grow files in this filesystem. Ah ! :-))) I already suspected this to be the case. At least I already found due to some error code that some ftruncate() must have failed, and I think I thus called it an ftruncate problem. Oh, and yes, that error condition was in the server, too, so it must have been this ftruncate. And one more: In several cases, some guys reported that programs needed some "touch"ing before being able to save a file. What do you wanna bet that *this* is the problem that's now solved ?? :) In short: a very important fix, I think. I guess we can call you a Wine Master now ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 21, 2002

Fix for the web site (WineHQ)

by Francois Gouget

This fixes a bug in the Web site: a pre tag was not closed properly. Changelog: * dev.shtml Fix a mis-closed <pre> tag -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Jan. 21, 2002

Re: SetEndOfFile fix

by lawson_whitney＠juno.com

On Sun, 20 Jan 2002, Rein Klazes wrote: > hi, > > BTW. A google search shows that the ftruncate problem has been > mentioned at least 3 times on c.e.m.w. in the last 6 months Since > nobody entered a fix, I could be overlooking something... Not exactly, I think. I remember several mentions of MSword (disk full or write protected), but nobody called it an ftruncate problem. I did think up some other rather ingenious ways you could misconfigure a fat filesystem to cause wine to be unable to save a file, but I missed ftruncate. I thought ftruncate only didn't work with umsdos, but I see I was wrong. I think you have just been paying better attention than some others of us. Good catch! > > Rein. > Lawson

Jan. 20, 2002

Re: Questions for developing functions

by David Elliott

On 2002.01.20 12:46 Gerhard W. Gruber wrote: > On Sun, 20 Jan 2002 11:38:48 -0500, David Elliott <dfe(a)tgwbd.org> wrote: > > >Well, if the code you contribute could be considered a derived work of > the > >code you disassembled then you'd have problems. But for instance if you > > >disassembled for the purposes of figuring out how many arguments the > >function takes and what not but didn't actually directly write your code > > >based on the disassembly, then you should be in the clear as far as that > > >is concerned. > > Of course I primarily use that insight to get information on what > arguments > are used. I don't intend to make a 1:1 representation of the binary code > to C. > :) > > >Now, as for the breaking of the license agreement on your software. > That > >mostly concerns you as you are the person under the license, not the > Wine > >project. So if you feel like you would get into legal trouble by even > >disassembling something to simply see what types of parameters it takes, > > >then I would suggest that you didn't do it. However if you feel that > you > >would not get into legal trouble, and assuming you don't create your > >implementation directly from the disassembly (i.e. you reimplement from > >scratch, but just use the disassembly to get some ideas of function > >parameters) then you should be very much in the clear, and so should the > > >wine project. > > Thanks. :) > Remember though.. I am not a lawyer, and I am not Alexandre Julliard. > >Hey man, if no one responds in this mailing list within a reasonable > >timeframe then probably no-one is working on it. Just have a go and if > >someone else beats you to it without saying anything you can always do a > > >peer-review of the code and see if maybe something should be done > >different. Two pairs of eyes are better than one. > > OK. Sorry to bother you with this, but I'm just starting out, so I don't > know > much about the procedure on how to contribute a bit. :) I'd also hate to > start > investingating when a few days later a patch is thrown at the list that > does > what I just started out to do. :) I also think that it wasted time on > behalf > of wine if many developers work on the same things and leave other areas > to > its own. > No, it's not a bother.. the fact that you just posted saying that you were gonna work on it is desirable. -Dave

Jan. 20, 2002

Re: Questions for developing functions

by David Elliott

On 2002.01.20 03:36 Gerhard W. Gruber wrote: > I have already posted this in the NG but I was told that this would be > more > appropriate here. > > One of my questions is how wine developers actualy develop their > functions. > I'm aware that some functions are (rather) easily determind just because > of > their name (i.e. CreateFile). Other functions can be derived from reading > the > documentation but there is quite a number of functions that arenot > documented > and some are not even mentioned anywhere (like functions in the > rpcnt.dll). > Now I wonder how you go about this. My approach would be to disassemble > such > functions and see how they work. Of course I know that in some countries > this > will be illegal while it is not in others. If I live in a country where > this > is legal would it still be a problem for the maintainer if I submit a > function > that is written based on the method I used to get the knowledge to write > it? > How do you circumvent that problem that you might infringe copyright as > reverse engineering is usually prohibited by the licence where this > licence is > actually legally binding. > Well, if the code you contribute could be considered a derived work of the code you disassembled then you'd have problems. But for instance if you disassembled for the purposes of figuring out how many arguments the function takes and what not but didn't actually directly write your code based on the disassembly, then you should be in the clear as far as that is concerned. Now, as for the breaking of the license agreement on your software. That mostly concerns you as you are the person under the license, not the Wine project. So if you feel like you would get into legal trouble by even disassembling something to simply see what types of parameters it takes, then I would suggest that you didn't do it. However if you feel that you would not get into legal trouble, and assuming you don't create your implementation directly from the disassembly (i.e. you reimplement from scratch, but just use the disassembly to get some ideas of function parameters) then you should be very much in the clear, and so should the wine project. > Another question is concerning the function CreateDispTypeInfo. I'd like > to > work on Hotline which uses this function. As I noticed, this function is > stubbed but not implemented and the last time it was worked on was > somewhere > in 2000, so I'd like to know if somebody is working on this. If I start > work > on it, do I have to submit this info somewhere in order to avoid > duplicate > work? > Hey man, if no one responds in this mailing list within a reasonable timeframe then probably no-one is working on it. Just have a go and if someone else beats you to it without saying anything you can always do a peer-review of the code and see if maybe something should be done different. Two pairs of eyes are better than one. -Dave

Jan. 20, 2002

Some musings about DGA2 support in Wine...

by Lionel Ulmer

Hi all, After being prodded by people on #WineHQ to look at the current DGA2 problem in Wine (it it works fine for graphics, but does not accept any user input at all and needs to either kill Wine remotely or do the three finger salute to the X server), I found the following things : - the DGA2 code (in dlls/x11drv/dga2.c) used the gdi_display connection to open the framebuffer and setting-up all the input handling. But it was the thread->display connection that was used to process the events. This is a no-go as when DGA2 is entered, there is only one connection that receives the event, the one which has grabbed the frame buffer (thanks to Ove to remind me of the 'one connection per thread' thingy). - so I removed all the mentions to 'gdi_display' in dga2.c and replaced them by the current thread display and still no go (although I checked that the event processing in WaitForMultipleEvents and subsequent process_events was done on the correct display). Still no go. So I investigated a bit with a little test program : = I did first try setting up DGA2 in a separate display and then doing all the 'standard' processing on another display (that is Wine does with DGA2 set-up in the init function to test if DGA2 is available and then really use it in another thread). As my test application still was working fine, this was not the problem... = then, I saw in the logs some calls to X11DRV functions after we have entered DGA2 (some due to the DDraw stuff creating DIB sections and so on, some due to the application I think). After adding the same stuff in my test program (ie I created a window just after entering DGA2), I found that it perturbed the event processing (I still had motion events, but neither key presses nor button presses). - so, finally, just to try, I backed off my changes in dga2.c (ie I used again the gdi_display for all the set-up) and had the process_events function in windows/x11drv/event.c use gdi_display instead of data->display when DGA was used (by testing the DGAUsed variable). And now it seems to work just fine.... All this leads now to the 10 � (an Euro sign for all the people not having an iso8859-15 font :-) ) question : how to fix this 'properly' and not with the hack I just did ? The only somewhat 'clean' solution I found would be to create a display connection specifically used for DGA2 (thus we would be sure that no X calls would 'pollute' the link). And in process_events, if DGA2 is used, use this connection instead of the thread connection (we already have some DGA specific variables there, what would be one more :-)) ). After, the question would be how we are sure that it's the 'good' WaitForMultipleEvents that receives the events (if the application is multi-threaded and has multiple threads calling this function). Anyway, if people want just to play some games using DGA2, they can always use my hacky solutions I just described up there :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 20, 2002

Questions for developing functions

by Gerhard W. Gruber

I have already posted this in the NG but I was told that this would be more appropriate here. One of my questions is how wine developers actualy develop their functions. I'm aware that some functions are (rather) easily determind just because of their name (i.e. CreateFile). Other functions can be derived from reading the documentation but there is quite a number of functions that arenot documented and some are not even mentioned anywhere (like functions in the rpcnt.dll). Now I wonder how you go about this. My approach would be to disassemble such functions and see how they work. Of course I know that in some countries this will be illegal while it is not in others. If I live in a country where this is legal would it still be a problem for the maintainer if I submit a function that is written based on the method I used to get the knowledge to write it? How do you circumvent that problem that you might infringe copyright as reverse engineering is usually prohibited by the licence where this licence is actually legally binding. Another question is concerning the function CreateDispTypeInfo. I'd like to work on Hotline which uses this function. As I noticed, this function is stubbed but not implemented and the last time it was worked on was somewhere in 2000, so I'd like to know if somebody is working on this. If I start work on it, do I have to submit this info somewhere in order to avoid duplicate work? Thanks. -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 20, 2002

Int 09 keyboard handler?

by Nog

Hi there, For 3 days now I have been trying to get Monkey Island 2 to work with wine, but I just can't seem to make it respond to keyboard input. The game installs a keyboard handler on int 09 which works. When a key gets pressed on the keyboard the key does get queued and then Monkey Island reads the key from port 0x60, which returns the correct key. So everything seems to work on the wine side of things but the game does not respond in any way. I have attached a +int,+io trace if that helps anyone. nog.

Jan. 19, 2002