wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Dialog painting
by Niclas Karlsson MATE 10 Sep '01

10 Sep '01

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

1 0

Monkey Island 3
by Johan Gill 09 Sep '01

09 Sep '01

The installation of Curse of Monkey Island seems to be broken in latest CVS. All I get is a dialog saying that setup requires a different version of Windows. A trace is available on the web at http://www.lysator.liu.se/~johane/monkey3.txt /Johan Gill, johane(a)lysator.liu.se

1 0

what if MS is forced to publish all API's?
by Scott Bradford 09 Sep '01

09 Sep '01

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

1 0

Focus livelock
by Jukka Heinonen 09 Sep '01

09 Sep '01

I posted a patch that would fix a focus related livelock. However, I have to admit that the patch is quite hacky and likely not to be included in Wine. Since I would like to get this bug fixed, I thought to ask opinions about the correct way to fix the bug. The short description of the bug is that setting active/foreground/focus window in Wine calls X11DRV_SetFocus, which calls XSetInputFocus. This makes Wine receive FocusIn event, the handler of which calls SetForegroundWindow. Even though SetForegroundWindow does nothing if its parameter matches current foreground window, it can be easily seen that having more than one window can lead into livelock. This happens repeatably every time you start Colonization for Windows. I'm currently thinking about calling directly some WINPOS_* routine from X11 FocusIn handler instead of SetForegroundWindow. If the routine acted exactly like SetForegroundWindow except it made sure that it causes no calls to X11DRV_SetFocus, focus problem would be fixed. Unfortunately I have not figured any good way to pass an extra flag to default handler for WM_ACTIVATE, so that the routine would call something like SetFocus_DontCallDriver instead of regular SetFocus... -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: Option to disable XVidMode
by Ove Kaaven 08 Sep '01

08 Sep '01

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

2 2

Re: ukrainian layout
by Dmitry Timoshkov 08 Sep '01

08 Sep '01

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

2 2

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

08 Sep '01

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

3 2

WM_[LR]BUTTON{DOWN,DBLCLK} in menus
by Bobby Bingham 08 Sep '01

08 Sep '01

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

1 0

Re: Problems with WM_PAINT and threads
by Alexandre Julliard 07 Sep '01

07 Sep '01

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

2 1

Re: Bugs involving returning strings from API functions
by Alexandre Julliard 07 Sep '01

07 Sep '01

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

1 0

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

07 Sep '01

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

2 1

Wine for OS X?
by Tyler Vano 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel