- wine-devel - winehq.org

Wine for OS X?
by Tyler Vano 07 Sep '01

07 Sep '01

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

2 1

Re: Make cmdline writable (cmdline4)
by Alexandre Julliard 07 Sep '01

07 Sep '01

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

2 1

RE: CryptoAPI
by Patrik Stridvall 06 Sep '01

06 Sep '01

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

1 0

RE: Problem with specmaker
by Patrik Stridvall 06 Sep '01

06 Sep '01

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

1 0

RE: CryptoAPI
by Patrik Stridvall 06 Sep '01

06 Sep '01

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

2 1

Re: dsound fix in wineoss
by eric pouech 06 Sep '01

06 Sep '01

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

1 0

Problem with specmaker
by Guy L. Albertelli 06 Sep '01

06 Sep '01

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

2 1

Problem
by Borut Rozman 05 Sep '01

05 Sep '01

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

3 3

this could be interesting for wine producers
by Igor 04 Sep '01

04 Sep '01

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

1 0

Bugs involving returning strings from API functions
by Justin Santa Barbara 04 Sep '01

04 Sep '01

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

2 3

CryptoAPI
by Travis Michielsen 04 Sep '01

04 Sep '01

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

3 4

Two threads waiting for a critical section
by Uwe Bonnes 03 Sep '01

03 Sep '01

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

1 0

' ' & '"' handling in the command line
by Francois Gouget 03 Sep '01

03 Sep '01

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

1 0

Re: pe format
by Dan Kegel 02 Sep '01

02 Sep '01

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

1 0

pe format
by tiago r 01 Sep '01

01 Sep '01

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

2 1

Race condition?
by lawson_whitney＠juno.com 01 Sep '01

01 Sep '01

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

1 0

Re: wine-devel digest, Vol 1 #445 - 9 msgs
by Robert Lunnon 30 Aug '01

30 Aug '01

Attempt 2 :-) I am trying to get winsock to work under Solaris and need a little help. When connecting, the call to connect doesn't generate a syn packet as expected, The problem appears to be WSOCK32_socket, where the type of socket is passed as type 1 for a tcp service, as it turns out the Solaris header file defines SOCK_STREAM as 2 and SOCK_DGRAM as 1 which makes the subsequent call to connect succeed without establishing a connection because a UDP endpoint was created instead of a tcp one. Now to find out where SOCK_STREAM is getting defined as 1 :-/ I probably need to check the standard function calls between a solaris binary and a windows one so does someone have a simple test program and a unix source (IE windows binary with unix compatible source code) that I can use to compare behaviours between the two environments ? Thanks Bob

2 1

Re: [PATCH] DestroyWindow16
by eric pouech 30 Aug '01

30 Aug '01

Gerard Patel wrote: > > As DestroyWindow does a lot of handle comparaisons, it is necessary > to give it a real 32 bit handle. This avoids a systematic crash when > ForteFreeAgent 16 bit exits. I have not looked for other places where > this can be necessary - but it would not be surprising that this happens. perhaps as an extension of the relay code ? (it would mean typing correctly windows handles in spec files though) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Problems with WM_PAINT and threads
by Ove Kaaven 30 Aug '01

30 Aug '01

After trying to merge Wine 20010824 into WineX, I've encountered a threading issue. A window is created in an app thread: 0806d1f0:Call user32.CreateWindowExA(00000000, 403cb0d4 "Afx:400000:3",0055b674 "3DMark - Display Window", 80000000,00000000,00000000,00000280,000001e0,00000000, 00000000,00400000,00000000) ret=5f40c486 trace:win:WIN_CreateWindowEx "3DMark - Display Window" "Afx:400000:3" 00000000 80000000 0,0 640x480 0000 0000 00400000 (nil) trace:win:WIN_CreateWindowEx winproc type is 2 (WIN_PROC_32A) ... This works fine, until our ddraw update thread somehow decides to send it a message after syncing its own window 31bc: 08107170:Ret x11drv.CreateWindow() retval=00000001 ret=407f542f trace:win:WIN_CreateWindowEx created window 31bc 08107170:Call x11drv.SetWindowPos(44a12e88) ret=407fb159 trace:x11drv:X11DRV_SetWindowPos hwnd 31bc, swp (0,0)-(0,0) flags 0000255b trace:x11drv:X11DRV_SetWindowPos current (0,0)-(800,600), style 84000000 warn:x11drv:SWP_DoOwnedPopups (31bc) hInsertAfter = 0000 trace:x11drv:X11DRV_sync_whole_window_position setting win 3200001 pos 0,0,800x600 after 8081268 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 31bc trace:x11drv:X11DRV_SetWindowPos status flags = 1843 08107170:Ret x11drv.SetWindowPos() retval=00000001 ret=407fb159 trace:win:RedrawWindow 31bc (0000) NULL 0,0-0,0 0000 flags=0180 trace:win:RDW_UpdateRgns hwnd 31bc [0000] -> hrgn [0000], flags [0180] trace:win:RDW_Paint hwnd 31bc [0000] -> hrgn [0000], flags [0180] 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000002,44a12da4,ffffffff,000000ff,00000000) ret=407e4237 trace:x11drv:X11DRV_Expose win 31bc (3200002) 0,0 800x600 trace:win:RedrawWindow 31bc (0000) rect 0,0-800,600 0000 flags=0005 trace:win:RDW_UpdateRgns hwnd 31bc [174a] -> hrgn [0000], flags [0005] trace:win:RDW_Paint hwnd 31bc [174a] -> hrgn [0000], flags [0005] 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000002 ret=407e4237 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=407a1ca4 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=407a1ca4 trace:msg:MSG_peek_message got type 5 msg f hwnd 0 wp 0 lp 0 trace:win:WIN_FindWinToRepaint found 3124 trace:win:RedrawWindow 3124 (1746) NULL 0,0-0,0 0000 flags=0050 trace:win:RDW_UpdateRgns hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:message:SPY_EnterMessage (00003124) "3DMark - D..." message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 08107170:Call window proc 0x5f4019fa (hwnd=00003124,msg=WM_PAINT,wp=00000000,lp=00000000) ^^^^^^^^ ^^^^^^^^ After Wine dispatches this WM_PAINT message from the wrong thread, 3DMark2000 fails to locate its thread-local data, gets confused, and crashes. Maybe Alexandre did a mistake somewhere in his restructures?

1 0

Re: BUG with wine/dlls/ntdll/string.c:_ultoa() ???!!??
by Uwe Bonnes 30 Aug '01

30 Aug '01

>>>>> "Johann" == Johann Messner <johann.messner(a)zid.uni-linz.ac.at> writes: Johann> Hi there, First: thanks & compliments for your impressive Johann> project!!! Johann> please check wine/dlls/ntdll/string.c:_ultoa() ... I think there Johann> is a bug in it ... There are for sure more bug... Johann> hans Johann> ==> this is the path to it in the web cvs: ... Johann> ==> this is the source snippet with the patch as suggested ... Did you test? As no win function is uses, you can easily write a test programm wrapper, like static char *_ultoa(... void main() { char buffer[32]; printf(" x %d, radix %d, result %s\n",1000,10,_ultoa(1000,buffer,10)); printf("... } The loop decrements p after use, so p needs to be corrected and I would think that the original version is right. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Mouse Events
by Brad Campbell 30 Aug '01

30 Aug '01

G'day all, Maiden post. Please be gentle.. I had a problem using wine with a touchscreen under XFree 4.0.2. With the help of Gerard Patel and Ove Kaaven I have come up with a patch that solves my problem, and does not appear to disrupt any of the other machines and programs I use. I have looked at several ways of achieving this, and this seems to be the least messy. This has been tested with both the touchscreen and also ps/2 mouse and works well with both. I'm not a C programmer at all, and have little experience with the WINE code. All comments both positive and negative appreciated.. Thanks.. To be applied to windows/input.c --- input.c Wed Aug 29 21:00:42 2001 +++ input.c.new Wed Aug 29 20:59:01 2001 @@ -195,43 +195,43 @@ if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTDOWN : MOUSEEVENTF_RIGHTDOWN)) { MouseButtonsStates[0] = AsyncMouseButtonsStates[0] = TRUE; - queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTUP : MOUSEEVENTF_RIGHTUP)) { MouseButtonsStates[0] = FALSE; - queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTDOWN : MOUSEEVENTF_LEFTDOWN)) { MouseButtonsStates[2] = AsyncMouseButtonsStates[2] = TRUE; - queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTUP : MOUSEEVENTF_LEFTUP)) { MouseButtonsStates[2] = FALSE; - queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEDOWN) { MouseButtonsStates[1] = AsyncMouseButtonsStates[1] = TRUE; - queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEUP) { MouseButtonsStates[1] = FALSE; - queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_WHEEL) { queue_raw_hardware_message( WM_MOUSEWHEEL, MAKELONG( keystate, mi->mouseData), 0, - PosX, PosY, mi->time, mi->dwExtraInfo ); + mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } } -- Brad Campbell /"\ Save the Forests \ / ASCII RIBBON CAMPAIGN Burn a Greenie. X AGAINST HTML MAIL / \

1 1

Comment from IBM developer re FS register corruption
by Jeremy White 30 Aug '01

30 Aug '01

At LinuxWorld today, a couple of developers from IBM stopped by and mentioned a patch that they recently sent to Linus (which he accepted with dismay at such a long standing bug, and apparently committed to the 2.4.8 tree). Sadly, I have forgotten the woman's name, but she indicated that there was a race condition that could sometimes cause the fs register to become corrupt, and that this problem had existing in all versions of Linux, as far as they could tell. She indicated that the patch had a fairly innocuous description, but it might be worth understanding this problem better (although from her description, it didn't sound like a good workaround was available). Cheers, Jeremy p.s. Wine was a finalist for best open source project, but lost out to KDE. Next time, the crystal plaque is ours. I can feel it.

1 0

Powerdvd running under linux
by Robert Lowery 30 Aug '01

30 Aug '01

Hi I have a graphics card with an SIS6326 chipset. Under Windows 98 (using PowerDVD), I get fantastic performance on my Pention 233MMX as it supports YUV->RGB, Motion Compensation and iDCT in hardware. This chipset is not currently supported under Linux. What do you think the chances are of PowerDVD working with hardware acceleration under WINE/WINEX? What sort of performance should I expect? Please cc replies to my email, as I am not subscribed Thank-you for your help -Robert

3 2

./configure file in cvs
by Gioele Barabucci 29 Aug '01

29 Aug '01

Hello everyone, why is there a ./configure file in your cvs? configure was meant to be created for endusers, not for developers. Many projects based on auto* tools create a ./autogen.sh or ./bootstrap script. The fact is that the configure supplied (and all the auto* files) creates lot of confusion and some errors sometime. simple as: #!/bin/sh # rm -f configure ltmain.sh config.guess config.sub echo "Running libtoolize..." libtoolize --force --copy >/dev/null echo "Running aclocal..." aclocal $ACLOCAL_FLAGS echo "Running autoheader..." $use_autoheader echo "Running autoconf..." $use_autoconf echo "Running automake..." automake --add-missing --copy --foreign -- Gioele Barabucci (Gb]) <gioeleb(a)tiscalinet.it>

3 2

Re:Call for Volunteers (Re: Newbie work?)
by Eric Pouech 29 Aug '01

29 Aug '01

> Also I'm thinking about starting an additional section for > 'hard(er)' projects that would significantly improve Wine. > Maybe it > could also list projects that are already underway and for which help > would be appreciated (DCOM?, STRICT handles?). I think that when folks start working on a rather large chunk they should talk about it a bit more (that they started, post some ideas on how it should be done, call for contributions...). All developpers are rather terse on this matter. > Easy: > Medium (I expect these would take longer or be a bit harder) > * Provide a pedump utility > #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 > I know there's sample code that does that already floating around so > it should be relatively simple. > Eric Pouech seems to be working on this. I did not check if his > pedump dump the imports/exports but it probably does. yes, but it's missing delayed imports and resource. disass could be provided to. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: Newbie work?
by Gerard Patel 29 Aug '01

29 Aug '01

At 03:25 PM 28/08/2001 -0700, you wrote: >I noticed that there was a file on >ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine >developers. I also noticed that it was written in 1994. So I was wondering >if there was a more up to date version or if anyone had some ideas of >usefull work that a developer new to wine could do? www.winehq.com/projects The one I would like to be done is 'loadable fonts'. It's difficult but it would make many people happy with Wine from some posts I see on cemw. Gerard

1 0

Re: Crash in latest version
by Gerard Patel 29 Aug '01

29 Aug '01

At 04:03 PM 28/08/2001 -0700, you wrote: >Gerard Patel <gerard.patel(a)nerim.net> writes: > >> What this means is that any use of 16 bit code with >> window handles in Wine will break as the handles >> will be truncated. I already see many new crashes... > >Actually truncated handles should work just fine, the generation >number is simply ignored if it is zero. There may theoretically be >problems when we pass a truncated handle to a 32-bit app that compares >it to a full 32-bit handle stored previously, but this should be >fairly rare behavior. So your crashes are probably caused by something >else. > .Backtrace for the next crash : Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00462b9b). In 32-bit mode. 0x00462b9b (eudora.exe.EntryPoint+0xb2ee in H:\eudora\eudora\eudora.exe): movl 0x0(%eax),%eax >0 0x00462b9b (eudora.exe.EntryPoint+0xb2ee in H:\eudora\eudora\eudora.exe) (ebp=406159c0) 1 0x00462dd7 (eudora.exe.EntryPoint+0xb52a in H:\eudora\eudora\eudora.exe) (ebp=40615a04) 2 0x40724e33 (WINPROC_CallWndProc+0x73(proc=0x462daa, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=40615a30) 3 0x4072a919 (WINPROC_CallProc32WTo32A+0x89(func=0x462daa, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:2442] in libuser32.so) (ebp=40615a58) 4 0x4072af32 (CallWindowProcW+0xb2(func=0x40dc1069, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:2683] in libuser32.so) (ebp=40615a8c) 5 0x406c37fe (call_window_proc+0x9e(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=40615ae4) 6 0x406c434b (SendMessageTimeoutW+0xcb(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40615b68) [message.c:1498] in libuser32.so) (ebp=40615b44) 7 0x406c45c7 (SendMessageW+0x37(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0) [message.c:1576] in libuser32.so) (ebp=40615b78) 8 0x406fb4ec (DEFDLG_SetFocus+0x5c(hwndDlg=0x1003a, hwndCtrl=0x3b) [defdlg.c:32] in libuser32.so) (ebp=40615b9c) 9 0x406fb5d7 (DEFDLG_RestoreFocus+0x67(hwnd=0x1003a) [defdlg.c:74] in libuser32.so) (ebp=40615b This crash goes away by changing the HWND16 in DIALOG_INFO to HWND. I have a third new one for you, but I have not the time to search for the reason this night (there is no hint of 16 bit handles here) 0x4071ff50 (GetParent+0x30 [win.c:2143] in libuser32.so): movl 0x20(%eax),%esi 2143 retvalue = wndPtr->parent->hwndSelf; Wine-dbg>bt bt Backtrace: =>0 0x4071ff50 (GetParent+0x30(hwnd=0x20021) [win.c:2143] in libuser32.so) (ebp=40615e7c) 1 0x4070a17f (DefMDIChildProcA+0x1f(hwnd=0x20021, message=0x82, wParam=0x0, lParam=0x0) [mdi.c:1617] in libuser32.so) (ebp=40615e98) 2 0x00474107 (eudora.exe.EntryPoint+0x1c85a in H:\eudora\eudora\eudora.exe) (ebp=40615f54) 3 0x00462ba3 (eudora.exe.EntryPoint+0xb2f6 in H:\eudora\eudora\eudora.exe) (ebp=40615fc8) 4 0x00462dd7 (eudora.exe.EntryPoint+0xb52a in H:\eudora\eudora\eudora.exe) (ebp=4061600c) 5 0x40724e83 (WINPROC_CallWndProc+0x73(proc=0x462daa, hwnd=0x20021, msg=0x82, wParam=0x0, lParam=0x0) [w inproc.c:171] in libuser32.so) (ebp=40616038) 6 0x4072ae72 (CallWindowProcA+0xb2(func=0x462daa, hwnd=0x20021, msg=0x82, wParam=0x0, lParam=0x0) [winpr oc.c:2647] in libuser32.so) (ebp=4061606c) 7 0x406c3823 (call_window_proc+0xc3(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0, unicode=0x0) [messag e.c:1112] in libuser32.so) (ebp=406160c4) 8 0x406c4496 (SendMessageTimeoutA+0xd6(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0, flags=0x0, timeou t=0xffffffff, res_ptr=0x40616148) [message.c:1544] in libuser32.so) (ebp=40616124) 9 0x406c4617 (SendMessageA+0x37(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0) [message.c:1587] in libu ser32.so) (ebp=40616158) 10 0x4071d6a4 (WIN_DestroyWindow+0x94(wndPtr=0x40403d54) [win.c:420] in libuser32.so) (ebp=40616180) 11 0x4071ebb2 (DestroyWindow+0x282(hwnd=0x20021) [win.c:1243] in libuser32.so) (ebp=406161a0) 12 0x40708506 (MDIDestroyChild+0xd6(parent=0x1002b, ci=0x403f4528, child=0x20021, flagDestroy=0x1) [mdi. c:712] in libuser32.so) (ebp=406161c4) 13 0x407096d2 (MDIClientWndProc_common+0x3d2(hwnd=0x1002b, message=0x221, wParam=0x20021, lParam=0x0, un icode=0x0) [mdi.c:1295] in libuser32.so) (ebp=40616218) 14 0x407099f6 (MDIClientWndProcA+0x36(hwnd=0x1002b, message=0x221, wParam=0x20021, lParam=0x0) [mdi.c:14 06] in libuser32.so) (ebp=4061623c) 15 0x40724e03 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40616260) 16 0x40724e83 (WINPROC_CallWndProc+0x73(proc=0x407099c0, hwnd=0x1002b, msg=0x221, wParam=0x20021, lParam =0x0) [winproc.c:171] in libuser32.so) (ebp=4061628c) 17 0x4072ae72 (CallWindowProcA+0xb2(func=0x407099c0, hwnd=0x1002b, msg=0x221, wParam=0x20021, lParam=0x0 ) [winproc.c:2647] in libuser32.so) (ebp=406162c0) 18 0x406c3823 (call_window_proc+0xc3(hwnd=0x1002b, msg=0x221, wparam=0x20021, lparam=0x0, unicode=0x0) [ message.c:1112] in libuser32.so) (ebp=40616318) 19 0x406c4496 (SendMessageTimeoutA+0xd6(hwnd=0x1002b, msg=0x221, wparam=0x20021, lparam=0x0, flags=0x0, All I can say for now is that wndPtr->parent is NULL. And I have yet another 20 apps to try :-) Gerard

1 0

Re: Crash in latest version
by Alexandre Julliard 29 Aug '01

29 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > This crash goes away by changing the HWND16 in DIALOG_INFO to HWND. Seems to be less rare than I hoped then ;-) I've added a fix. > All I can say for now is that wndPtr->parent is NULL. This one should be fixed too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Crash in latest version
by Gerard Patel 29 Aug '01

29 Aug '01

At 10:34 PM 28/08/2001 +0200, you wrote: >Notice the change in the hwnd Windows handles are now generated on the server. This is a historical moment, btw :-) Now Wine has all the architectural features of Win 95 Not everything is implemented, FindWindow does not yet work across processes for example. But it's an important step nonetheless. Alexandre Julliard has implemented the 'generation' feature of handles. The higher part of a 32 bit handle is used for a counter that is incremented from a window creation to another, avoiding the age-old problem of windows being deleted, then braindead application trying to use their handles, using newly created windows instead. What this means is that any use of 16 bit code with window handles in Wine will break as the handles will be truncated. I already see many new crashes... The dialog code uses a 16 bit only Api (FillWindow) The following (and simplistic) patch should make your app crash a bit later. Gerard --- defdlg.c.orig Tue Aug 21 15:09:31 2001 +++ defdlg.c Wed Aug 29 00:07:28 2001 @@ -135,10 +135,18 @@ static LRESULT DEFDLG_Proc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, DIALOGINFO *dlgInfo ) { + HBRUSH hbrush; switch(msg) { case WM_ERASEBKGND: - FillWindow16( hwnd, hwnd, (HDC16)wParam, (HBRUSH16)CTLCOLOR_DLG ); + hbrush = SendMessageA( hwnd, WM_CTLCOLORDLG, + wParam, (LPARAM)hwnd ); + if (hbrush ) + { + RECT r; + GetClientRect(hwnd, &r); + FillRect( (HDC) wParam, &r, hbrush ); + } return 1; case WM_NCDESTROY:

1 0

Call for Volunteers (Re: Newbie work?)
by Francois Gouget 28 Aug '01

28 Aug '01

Hi, On Tue, 28 Aug 2001, Daniel Sabo wrote: > I noticed that there was a file on > ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine > developers. I also noticed that it was written in 1994. So I was wondering > if there was a more up to date version or if anyone had some ideas of > usefull work that a developer new to wine could do? Unfortunately this file does not seem very helpful. Time for another round of my Call for Volunteers it seems :-) Note that I did not get much time to update it so please send me your ideas. Also I'm thinking about starting an additional section for 'hard(er)' projects that would significantly improve Wine. Maybe it could also list projects that are already underway and for which help would be appreciated (DCOM?, STRICT handles?). But first, many thanks go to all those who fixed bugs from the previous call for volunteers and especially to Maciek Kaliszewski for his wrc fixes. What is the "Call for Volunteers"? I have built a list of projects that should be easy to tackle by new Wine developpers. The main goal is to provide the needed inspiration to potential Wine developpers that just are not motivated by the standard 'grep FIXME' answer (and I can understand them). So here goes. Easy: * PrgWin95/98: System metrics differ from the Win9x values #48: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48 One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, 2000, ... * The doc about the command line arguments and the config file is out of date. See TextCP, XVideoPort and Synchronous for instance. I'm sure there are plenty of other things that are out of date. * Metabug: Test Wine with the VXCL samples #242: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=242 Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion. You can probably start reporting the most obvious bugs just by testing in Wine, but for more subtle bugs you will need two computers (or Win4Lin/VmWare) to more easily compare the behavior in Windows and in Wine. * Metabug: Test Wine with the Common Control Spy Samples #239: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239 Get the Common Control Spy samples and test Wine with them. You will need the native comctl32 dll but you can do the tests without rebooting between each test or using two computers. * PrgWin95: Listbox getting a recessed border instead of a flat one #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56 (I can provide you with the sample application) This one my be fixed, to check... * I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming. * Tabs are missing their inner border #243: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=243 There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code. Medium (I expect these would take longer or be a bit harder) * Quickbooks Pro Timer does not accept date (GetCalendarInfoA error) #276: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=276 GetCalendarInfoA/W are not implemented yet. They involve quite a lot of internationalisation aspects, but providing a first implementation that at least handles the common cases should be feasible. * Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 I know there's sample code that does that already floating around so it should be relatively simple. Eric Pouech seems to be working on this. I did not check if his pedump dump the imports/exports but it probably does. * CreateIcon does not resize bitmaps #175: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175 I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction. * winemaker: 'winemaker --nomfc' does not have the intended effect #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227 * winemaker: Ignores the '--with-{mfc,wine}' options once they are cached #225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225 If you're familiar with autoconf and know how configure scripts should behave... * StrokePath ignores PS_JOIN_xxx #11: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11 This should not be too difficult to fix but it would certainly help if you are familiar with GDI. * Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences. * Enhancing the above perl script. In particular it could be made smarter wrt. detecting whether an API is exported by ordinal or not. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

1 0

Newbie work?
by Daniel Sabo 28 Aug '01

28 Aug '01

I noticed that there was a file on ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine developers. I also noticed that it was written in 1994. So I was wondering if there was a more up to date version or if anyone had some ideas of usefull work that a developer new to wine could do? Daniel Sabo

2 1

Re: Crash in latest version
by Alexandre Julliard 28 Aug '01

28 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > What this means is that any use of 16 bit code with > window handles in Wine will break as the handles > will be truncated. I already see many new crashes... Actually truncated handles should work just fine, the generation number is simply ignored if it is zero. There may theoretically be problems when we pass a truncated handle to a 32-bit app that compares it to a full 32-bit handle stored previously, but this should be fairly rare behavior. So your crashes are probably caused by something else. -- Alexandre Julliard julliard(a)winehq.com

1 0

Crash in latest version
by Uwe Bonnes 28 Aug '01

28 Aug '01

Hallo, sorry, the failure in the last mail was with an executable cvs-updated to " wine/ dlls/ttydrv/wnd.c dlls/x11drv/desktop.c ..." Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Crash in latest version
by Uwe Bonnes 28 Aug '01

28 Aug '01

Hallo, after an CVS update this evening including up to http://cvs.winehq.com/patch.py?id=999019609445169733371586 msdev.exe crashes earlier than before, when opening FILE->NEW This is from the relay log: 080681b8:CALL mfc42.2385: @(00000014,00000088,00000000) ret=5f47abec 080681b8:Call user32.CallWindowProcA(40d20259,00010052,00000014,00000088,00000000) ret=5f47a172 080681b8:Call window proc 0x4077d990 (hwnd=00010052,msg=WM_ERASEBKGND,wp=00000088,lp=00000000) 080681b8:Call window proc 0x5f47e7c0 (hwnd=00010052,msg=WM_ERASEBKGND,wp=00000088,lp=00000000) 080681b8:Ret window proc 0x5f47e7c0 (hwnd=00010052,msg=WM_ERASEBKGND,wp=00000088,lp=00000000) retval=00000000 080681b8:Call window proc 0x5f4bc820 (hwnd=00000052,msg=WM_CTLCOLORDLG,wp=00000088,lp=00000052) ^^^^^^^^ Notice the change in the hwnd. Backtrace is: =>0 0x5f4791e7 (AfxCallWndProc+0xc7(pWnd=0x0, hWnd=0x52, nMsg=0x136, wParam=0x88, lParam=0x52) [wincore.cpp:215] in D:\WINE95\SYSTEM\MFC42.DLL) (ebp=405c5110) 1 0x5f479539 (AfxWndProc+0x39(hWnd=0x52, nMsg=0x136, wParam=0x88, lParam=0x52) [wincore.cpp:368] in D:\WINE95\SYSTEM\MFC42.DLL) (ebp=405c5130) 2 0x5f4bc86a (AfxWndProcBase+0x4a(hWnd=0x52, nMsg=0x136, wParam=0x88, lParam=0x52) [afxstate.cpp:220] in D:\WINE95\SYSTEM\MFC42.DLL) (ebp=405c5160) 3 0x40793be7 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c5184) 4 0x40793c66 (WINPROC_CallWndProc+0x76(proc=0x5f4bc820, hwnd=0x52, msg=0x136, wParam=0x88, lParam=0x52) [winproc.c:171] in libuser32.so) (ebp=405c51b0) 5 0x407999cb (CallWindowProcA+0x3b(func=0x5f4bc820, hwnd=0x52, msg=0x136, wParam=0x88, lParam=0x52) [winproc.c:2631] in libuser32.so) (ebp=405c51d8) 6 0x40733673 (call_window_proc+0xc3(hwnd=0x52, msg=0x136, wparam=0x88, lparam=0x52, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405c5224) 7 0x407342f0 (SendMessageTimeoutA+0xd0(hwnd=0x52, msg=0x136, wparam=0x88, lparam=0x52, flags=0x0, timeout=0xffffffff, res_ptr=0x405c52ac, hwnd=0x52) [message.c:1542] in libuser32.so) (ebp=405c527c) 8 0x40734469 (SendMessageA+0x39(hwnd=0x52, msg=0x136, wparam=0x88, lparam=0x52) [message.c:1587] in libuser32.so) (ebp=405c52b0) 9 0x407810b9 (PAINT_GetControlBrush+0x39(hParent=0x52, hWnd=0x52, hDC=0x88, ctlType=0x4) [painting.c:439] in libuser32.so) (ebp=405c52d8) 10 0x40781138 (PaintRect16+0x48(hwndParent=0x52, hwnd=0x52, hdc=0x88, hbrush=0x4, rect=0x405c5330) [painting.c:456] in libuser32.so) (ebp=405c52fc) 11 0x4078106b (FillWindow16+0x7b(hwndParent=0x52, hwnd=0x52, hdc=0x88, hbrush=0x4) [painting.c:430] in libuser32.so) (ebp=405c5348) 12 0x4076a3bd (DEFDLG_Proc+0xed(hwnd=0x10052, msg=0x14, wParam=0x88, lParam=0x0, dlgInfo=0x4041f91c) [defdlg.c:142] in libuser32.so) (ebp=405c536c) Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Codeweavers announces CrossOver plugin
by Marcus Meissner 28 Aug '01

28 Aug '01

Hi, Codeweavers has announced the CrossOver plugin, allowing Shockwave, Quicktime etc. to run in your favorite browser :) http://www.codeweavers.com/about/press_releases/?id=20010827.xml Ciao, Marcus

2 2

Wine in the press
by Eric Pouech 28 Aug '01

28 Aug '01

http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2806411,00.html not a very good review for Wine indeed, but worth the reading this simply pinpoints what has to be fixed & enhanced A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: strange code
by Alexandre Julliard 27 Aug '01

27 Aug '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > in PROFILE_LoadWineIni(), we return from processing in case we're not > the boot thread only *after* having created HKLM\\Software\\Wine\\Wine > registry keys: > > if (!CLIENT_IsBootThread()) return 1; /* already loaded */ > > Why ?? After all the registry is globally shared in > wineserver, so it shouldn't be necessary to create them again > via NtCreateKey if we're not the wine boot process. We don't need to create the keys, but we need to create the handle to the key. We could use NtOpenKey instead but NtCreateKey works just as well and avoids duplicating code. -- Alexandre Julliard julliard(a)winehq.com

1 0

strange code
by Andreas Mohr 27 Aug '01

27 Aug '01

Hi all, in PROFILE_LoadWineIni(), we return from processing in case we're not the boot thread only *after* having created HKLM\\Software\\Wine\\Wine registry keys: if (!CLIENT_IsBootThread()) return 1; /* already loaded */ Why ?? After all the registry is globally shared in wineserver, so it shouldn't be necessary to create them again via NtCreateKey if we're not the wine boot process. Am I right ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

help me with WIN95 value of version16()
by Ladislav Sladecek 27 Aug '01

27 Aug '01

The return value of GetVersion16() for win95 changed recently from 0x5f03 to 0x304 in misc/version.c (patch 1.43 -> 1.44). The version of "real" win95 I use (Czech, win95 2nd ed) gives 0x5f03 while "wine --winver win95" gives 0x304. As I do not have the US version of win95 I am not able to determine the right value. Since people from many countries read this group I ask for help. I created a simple test (compiled binary attached or compile yourselves in a 16 bit compiler). Please let me know what do your win95 (win98) returns. #include <windows.h> int WINAPI WinMain() { char s[1024]; DWORD v; v = GetVersion(); wsprintf(s,"GetVersion returned: 0x%0x",v); MessageBox(NULL,s,"lsla(a)post.cz",0); return 0; } Ladislav Sladecek

3 4

Re: help me with WIN95 value of version16()
by Gerard Patel 27 Aug '01

27 Aug '01

At 08:57 AM 27/08/2001 -0700, you wrote: <snip> > Now, why would we have a version with 3.95 and another with 3.4? Is >it a Win95 vs Win95 OSR2 issue? I tested it on an original Win95, not on OSR2. I have no idea if OSR2 or 98 or Me behave differently, but I doubt it, else there would be a huge number of complaints in past Usenet postings archived on Google. IMO to fix the problem it's sufficient to change GetVersion16 along the lines of : if version = 0400 and winversion=win95 then version = 3.95 Gerard

1 0

Re: help me with WIN95 value of version16()
by Gerard Patel 27 Aug '01

27 Aug '01

At 08:34 PM 26/08/2001 -0700, you wrote: >> The return value of GetVersion16() for win95 changed recently from 0x5f03 to >> 0x304 in misc/version.c (patch 1.43 -> 1.44). The version of "real" win95 I use >> (Czech, win95 2nd ed) gives 0x5f03 while "wine --winver win95" gives 0x304. >> As I do not have the US version of win95 I am not able to determine the right >> value. > > I would like to help you and I have a Win95 system around. But I >don't have a Win16 compiler as these things are getting quite rare. I can compile and run 16 bits apps, on win3.1 if needed (it's a pain because it's old hardware I hardly use otherwise) GetVersion 16 bits must be a special case, returns 3.95, while 32 bits apps get 4.00 Gerard

2 1

propably simple
by Ibrahim Hamouda 27 Aug '01

27 Aug '01

I'm sorry for posting to the developers group, although I'm not one. I just have a simple question and the other news group is not helping. for three days now I'm trying to get an application connects to a MSSQL database on a windows box. I'm running the following: Mandrake 8.0 wine 20010731 windows 98 partition and sql server is installed on it My application is built in Powerbuilder 6.0. it comes up with the user name and password box which should be authenticated through the database. when I submit the user name and password I get the following error: [Microsoft][ODBC SQL SERVER DRIVER][TCP?IP SOCKET]General network error on the linux box I've already setup the MSSQL alias in the client connectivity utility of the sql server. I just want to know if I'm configuring the native and builtin wrong in my conf file or what I'm trying to do is not doable at all. I'll appreciate an answer so I can get some sleep, I'm literaly working on that for three days. Ibrahim Hamouda Internode Networks

2 1

keyboard problem
by Stefan Leichter 27 Aug '01

27 Aug '01

Hello all, after a long time of debugging (because of my little experience with windows programing and debugging), i found the problem that breaks the keyboard input of my favorite game "You Don't Know Jack" (demos of newer versions downloadable at http://www.take2.de/downloads/demos.php). The problem is that the game is waiting for keyboard input by checking for the messages WM_KEYDOWN, WM_CHAR and WM_KEYUP at least for the keys 1-0 and a-z. But wine generates the messages WM_SYSKEYDOWN, WM_SYSCHAR? and WM_SYSKEYUP. The problem is in the file "windows/message.c" in the methode "process_raw_keyboard_message" in the line 383: if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; For some reason i do not understand the message becomes changed. If i remove this line the game recognize the keyboard input and is playable (somehow). An other option(untested) for the game is to change the line to something like this: if (msg->message < WM_KEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; Does anyone know why the message becomes changed? Or does anyone know a better fix for the problem? Is there a program the need the line as it is? Tschüß Stefan PS: I am not subscriped to this mailing list, but i'm reading the newsgroup wine.devel. So it will take some time to see my answers to your questions in the mailing list

3 3

Re: keyboard problem
by Gerard Patel 27 Aug '01

27 Aug '01

At 05:49 PM 26/08/2001 -0700, you (Daniel Sabo) wrote: <snip> >As far as i can see the function is ok, maybe GetFocus is bugged? > >static BOOL process_raw_keyboard_message( MSG *msg, ULONG_PTR extra_info ) >{ > if (!(msg->hwnd = GetFocus())) > { > /* Send the message to the active window instead, */ > /* translating messages to their WM_SYS equivalent */ > msg->hwnd = GetActiveWindow(); > if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; > } >... I doubt GetFocus is bugged. What is quite probable is that the focus/active window handling is not behaving like Windows does (if there is really *one* behaviour in the different versions of Windows, that is). Another possibility (less probable in this case) could be that the Ms doc about WM_SYS* messages is inaccurate or incomplete. Gerard

1 0

undefined symbol send
by lawson_whitney＠juno.com 25 Aug '01

25 Aug '01

Good day! I just got a new binutils about a year ago (well, maybe it was 2) to keep up with y'all. Is my as dragging again? make[1]: Entering directory `/oof/Wine-20010824/loader/dos' gcc -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boun dary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o dosmod ./dosmod.c /tmp/cc1rBlP7.s: Assembler messages: /tmp/cc1rBlP7.s:1355: Error: undefined symbol send in operation /tmp/cc1rBlP7.s:1355: Error: undefined symbol signal in operation make[1]: *** [dosmod] Error 1 make[1]: Leaving directory `/oof/Wine-20010824/loader/dos' make: *** [loader/dos/dosmod] Error 2 [whit@giftie Wine-20010824]$ as --version GNU assembler 2.10.90 Copyright 2000 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i586-mandrake-linux'. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 1

__ws_select
by Robert Lunnon 25 Aug '01

25 Aug '01

I'm trying to hack on wine to get it working properly on Solaris X86. Now that the basic things are working on Solaris, I have run into a problem with networking. The Network apps block on a read operation. Here is a debug trace of ftp for example bash-2.03$ wine ftp -debugmsg +winsock,+thread -managed trace:winsock:WSOCK32_LibMain 0xdf630000 0x1 1 trace:winsock:WSAStartup verReq=101 trace:winsock:WSAStartup succeeded trace:winsock:WSOCK32_getservbyname 'ftp', 'tcp' fixme:console:SetConsoleCtrlHandler (1001dc5,1) - no error checking or testing yet ftp> o ftp.cdrom.com trace:winsock:WSOCK32_gethostbyname ftp.cdrom.com trace:winsock:WSOCK32_socket af=2 type=1 protocol=0 trace:winsock:WSOCK32_socket created 0030 trace:winsock:WSOCK32_bind socket 0030, ptr 1008700, length 16 trace:winsock:WSOCK32_setsockopt socket 0030, lev 65535, opt 0x8, ptr df7666d4, len 4 trace:winsock:WSOCK32_connect socket 0030, ptr 1008700, length 16 trace:winsock:WSOCK32_getsockname socket: 0030, ptr 1008760, ptr 10 Connected to wcarchive.cdrom.com. trace:winsock:__ws_select read df766570, write 0, excp 0 trace:winsock:fd_set_unimport Connection closed by remote host. ftp> Can anyone give me a starting point, I only have basic tcp knowledge Thanks in advance Bob

1 0

ICQ 2000b
by Daniel Walker 24 Aug '01

24 Aug '01

ICQ appears to get in some kind of loop. It eventually crashes with a stack overflow, but there are 16000+ lines in the backtrace so .... The sequence below repeats over and over in the backtrace .. Wine did load this application at one time, right? Or has someone seen this before? Daniel Walker 16429 0x406eb4ac (SendMessageA+0x38(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5858) [message.c:1588] in libuser32.so) (ebp=405b57bc) 16430 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b5858) [winpos.c:856] in libx11drv.so) (ebp=405b5840) 16431 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b5874) 16432 0x408f561b (SHAppBarMessage+0x147(msg=0x9, data=0x405b58d0) [shell32_main.c:537] in libshell32.so) (ebp=405b58b4) 16433 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds@BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5904) 16434 0x2194c273 (ICQCORE.DLL.?AlwaysCheckBounds@BCDbListCtrl@@UAE_NXZ+0x9d0 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5998) 16435 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b59b8) 16436 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a18) 16437 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a34) 16438 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a60) 16439 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b5a84) 16440 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b5c4c) [winproc.c:171] in libuser32.so) (ebp=405b5ab0) 16441 0x4074db5e (CallWindowProcA+0x3a(func=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b5c4c) [winproc.c:2656] in libuser32.so) (ebp=405b5ad8) 16442 0x406ea6d6 (call_window_proc+0xc2(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405b5b24) 16443 0x406eb333 (SendMessageTimeoutA+0xcf(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c, flags=0x0, timeout=0xffffffff, res_ptr=0x405b5bac, hwnd=0x2a0) [message.c:1566] in libuser32.so) (ebp=405b5b7c) 16444 0x406eb4ac (SendMessageA+0x38(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c) [message.c:1588] in libuser32.so) (ebp=405b5bb0) 16445 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b5c4c) [winpos.c:856] in libx11drv.so) (ebp=405b5c34) 16446 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b5c68) 16447 0x408f561b (SHAppBarMessage+0x147(msg=0x9, data=0x405b5cc4) [shell32_main.c:537] in libshell32.so) (ebp=405b5ca8) 16448 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds@BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5cf8) 16449 0x2194c273 (ICQCORE.DLL.?AlwaysCheckBounds@BCDbListCtrl@@UAE_NXZ+0x9d0 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5d8c) 16450 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5dac) 16451 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e0c) 16452 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e28) 16453 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e54) 16454 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b5e78) 16455 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b6040) [winproc.c:171] in libuser32.so) (ebp=405b5ea4) 16456 0x4074db5e (CallWindowProcA+0x3a(func=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b6040) [winproc.c:2656] in libuser32.so) (ebp=405b5ecc) 16457 0x406ea6d6 (call_window_proc+0xc2(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b6040, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405b5f18) 16458 0x406eb333 (SendMessageTimeoutA+0xcf(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b6040, flags=0x0, timeout=0xffffffff, res_ptr=0x405b5fa0, hwnd=0x2a0) [message.c:1566] in libuser32.so) (ebp=405b5f70) [Here is the very begining, this doesn't repeat.] 16460 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b6040) [winpos.c:856] in libx11drv.so) (ebp=405b6028) 16461 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b605c) 16462 0x408f561b (SHAppBarMessage+0x147(msg=0x0, data=0x405b60b8) [shell32_main.c:537] in libshell32.so) (ebp=405b609c) 16463 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds@BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b60ec) 16464 0x2194c1e9 (ICQCORE.DLL.?AlwaysCheckBounds@BCDbListCtrl@@UAE_NXZ+0x946 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b6118) 16465 0x5f401f1b (MFC42.DLL.5163+0x20f in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6194) 16466 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b61b4) 16467 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6214) 16468 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6230) 16469 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b625c) 16470 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b6280) 16471 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x403b09d4) [winproc.c:171] in libuser32.so) (ebp=405b62ac) 16472 0x4074d76d (WINPROC_CallProc32WTo32A+0x85(func=0x5f401b81, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x403b09d4) [winproc.c:2441] in libuser32.so) (ebp=405b62d4) 16473 0x4074dca7 (CallWindowProcW+0x93(func=0x41030b41, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x405b66b4) [winproc.c:2692] in libuser32.so) (ebp=405b62fc) 16474 0x406ea6b1 (call_window_proc+0x9d(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=405b6348) 16475 0x406eb1f4 (SendMessageTimeoutW+0xc8(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4, flags=0x0, timeout=0xffffffff, res_ptr=0x405b63cc) [message.c:1508] in libuser32.so) (ebp=405b639c) 16476 0x406eb460 (SendMessageW+0x38(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4) [message.c:1577] in libuser32.so) (ebp=405b63d0) 16477 0x40a79215 (X11DRV_CreateWindow+0x2dd(hwnd=0x2a0, cs=0x405b66b4, unicode=0x1) [window.c:927] in libx11drv.so) (ebp=405b6418) 16478 0x40741a00 (WIN_CreateWindowEx+0x6d4(cs=0x405b66b4, classAtom=0x8002, type=0x3) [win.c:812] in libuser32.so) (ebp=405b6490) 16479 0x40741fe8 (CreateWindowExW+0x14c(exStyle=0x10080, className=0x8002, windowName=0x21a5e00e, style=0x80cc0044, x=0x0, y=0x0, width=0xad, height=0x10a, parent=0x0, menu=0x0, instance=0x21880000, data=0x0) [win.c:1039] in libuser32.so) (ebp=405b66e4) 16480 0x40723989 (DIALOG_CreateIndirect+0x3ad(hInst=0x21880000, dlgTemplate=0x21a5e034, win32Template=0x1, owner=0x0, dlgProc=0x5f408e75, param=0x0, procType=0x2, modal=0x0) [dialog.c:833] in libuser32.so) (ebp=405b678c) 16481 0x40723dbc (CreateDialogIndirectParamA+0x30(hInst=0x21880000, dlgTemplate=0x21a5dff0, owner=0x0, dlgProc=0x5f408e75, param=0x0) [dialog.c:1006] in libuser32.so) (ebp=405b67c0) 16482 0x5f40a1a1 (MFC42.DLL.2147+0xc9 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6828) 16483 0x5f40a35e (MFC42.DLL.2168+0x27 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6cec) 16484 0x00401555 (Icq.exe..text+0x555 in C:\Program Files\ICQ\Icq.exe) (ebp=405b6e0c) 16485 0x5f40b4f3 (MFC42.DLL.1576+0x47 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6ecc) 16486 0x400d005d (start_process+0x195 [process.c:390] in libntdll.so) (ebp=405b6f30) 16487 0x400d394c (SYSDEPS_DoCallOnStack+0x20(func=0x400cfec8, arg=0x0) [sysdeps.c:183] in libntdll.so) (ebp=405b6ff0) 16488 0x400d39f3 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff89c) 16489 0x400d3aa0 (SYSDEPS_SwitchToThreadStack+0x94(func=0x400cfec8) [sysdeps.c:238] in libntdll.so) (ebp=bffff8d8) 16490 0x400d03ee (PROCESS_InitWine+0x1ca(argc=0x5, argv=0xbffff954, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:522] in libntdll.so) (ebp=bffff8f0) 16491 0x0804b1e6 (Letext [main.c] in wine) (ebp=bffff908) 16492 0x402789cb (__libc_start_main+0xff(main=0x804b1cc, argc=0x5, argv=0xbffff954, init=0x80486d4, fini=0x804b224, rtld_fini=0x4000ae60, stack_end=0xbffff94c) [libc-start.c:92] in libc.so.6) (ebp=bffff928) 16493 0x08049021 (_start+0x21 in wine) (ebp=00000000)

2 2

Re: dumping utility
by Alexandre Julliard 24 Aug '01

24 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > what about winextract ? Seems a bit too generic, google turns up a number of Windows programs with this name already. I guess we should start a naming contest ;-) Maybe winedump? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dumping utility
by Alexandre Julliard 24 Aug '01

24 Aug '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Actually for Caldera I am already putting all non-user called programs > (wineserver,winedbg,wineshelllink, and dosmod) into /usr/lib/wine. At least wineserver and winedbg can legitimately be started directly, so I would leave them in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dumping utility
by Alexandre Julliard 24 Aug '01

24 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > I choose the later because I didn't like to have a dump utility > named specmaker... however, we can go back to the former, and go > for another name ;-) I think that may be better. And a name starting in 'wine' would be better than specmaker anyway, this would make sure we don't conflict with other projects. -- Alexandre Julliard julliard(a)winehq.com

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel