July 2001 - Wine-Devel - list.winehq.org

Re: Handling X errors using exception handlers

by Lionel Ulmer

> The main problem with that is that I don't think you can jump out of > Xlib without corrupting its state. Also you'd need to properly unlock > the tsx11 lock in case of exception, which will probably require an > finally handler around each X call. Well, seems you are right about X not liking the 'longjmp' stuff (I asked on the XPert mailing list to confirm :-) ). > My idea was to have the following two functions: > > void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); > int X11DRV_check_error(void); > > You'd call X11DRV_expect_error before doing an X call that can fail; > then if an X error happens that matches what you expect, the X error > handler will simply set a flag and ignore the error (if it doesn't > match you get the standard error handling). Then after the call you > use X11DRV_check_error to see if your error happened or not. Would > this work for what you need? Yeah, this would work (and is about what I already did in the XShm and WGL code to detect X errors, except that I just set a global variable in case of error :-) ). The only problems I could see with this approach is that : - it cannot 'expect' more than one kind of error at the same time - I am not sure that the parameters thing are really a good idea. Are we sure that the error code are the same on all X servers ? Are they standardized ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 15, 2001

Re: Wine freshman class

by nog

July 15, 2001

re: small named pipe patch

by Mike McCormack

Hi Ove, funny that, i had the same problems with install shield and thought about the same solution... but i don't know enough about COM to make it work. i'll have a go at implementing WaitForNamedPipe... it'd be great to have an interprocess COM implementation :-) Mike > I'm planning to use named pipes to implement a basic interprocess COM, to > support the stupid InstallShield v6 under Wine, so it would be nice if > they could be implemented fully (would e.g. be nice if someone implemented > WaitForNamedPipe for me, and things like that). > > (Would that be a good idea?) ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

July 15, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > What kludge? Ugly OK, that is your subjective opinion, but kludge? > Even if we only see it from a purely C language perspective, > it solves the problem of making sure that the C library functions > have the prototypes we expect them to have. There is no other > way to solve that problem that I can think of so it is certainly > not a kludge. Not only is it not a problem we need to solve, but it's more likely to actually cause new problems. I wouldn't be surprised at all if your patch broke compile on some platforms that have some slight differences in prototypes (like char* vs. const char*). > If you are not convinced now, you never will be. I think we agree on this one ;-) -- Alexandre Julliard julliard(a)winehq.com

July 15, 2001

Re: implement SetCommState16 using SetCommState

by lawson_whitney＠juno.com

On Sat, 14 Jul 2001, Mike McCormack wrote: > > quickly checked. > > ChangeLog: > Rewrite SetCommState16 to use SetCommState > Okay, if you get this, juno 1.49 finds no fault in this patch either. Lawson ---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.

July 15, 2001

Wine freshman class

by Paul Gaynor

Hi, I am new to the development of wine, part of the wine freshman class :) I am really interested in developing wine for use with OpenGL hopefully to push the performance of the 3-D to window$ level. I am interested in making a striped build that just handles OpenGL strictly for gaming. Any pointers that any of you can give to get me started on my journey would be wonderfully appreciated. :) How much Win$/Linux programming experience is needed with the various tasks associated with developing wine? What are the different areas (and how much programming) is required for each task of developing wine? What do you think a good place for a beginning programmer/ developer to start? I am very excited that this group exists and I am looking forward to hacking on wine :) Paul Gaynor gpk2(a)uswest.net

July 14, 2001

Win95 version fix

by Francois Gouget

Hi, Bob Goodwin proposes the following change to misc/version.c as a fix for bug #232 (http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=232) --- cut here --- Index: misc/version.c =================================================================== RCS file: /home/wine/wine/misc/version.c,v retrieving revision 1.43 diff -u -r1.43 version.c --- misc/version.c 2001/07/02 19:59:49 1.43 +++ misc/version.c 2001/07/14 20:58:49 @@ -75,7 +75,7 @@ }, /* WIN95 */ { - 0x07005F03, + 0x07000304, 0xC0000004, { sizeof(OSVERSIONINFOA), 4, 0, 0x40003B6, --- cut here --- Note that the previous value for Win95 was the same as that for Win98 which is a bit strange. Can someone check the value proposed by Bob Goodwin? Or alternately, how would I check it myself? I have access to Win95/98/2000/Me so I could also check the value for Win2000 and even add one for Wine Me. Btw, if someone needs to check values for one of the above platforms and you can provide me with a simple test program, just let me know. I can probably help you. Of course, the simpler the program is to execute, the more likely I am to be able to help you. I can also accept source (Win32) so you can develop the test program with Winelib and just send me the source, I'll recompile it on Windows. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

July 14, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > However I'm a little curious where the documentation, > > and yes I'm talking about real documentation not just > > the external name and the ordinal, should be placed. > > Sure you have the underlying Unix man pages at least > > if we are talking about the MSVCRT and NTDLL functions, > > but it would be nice to have a proper Windows style > > man page for them eventually. > > Given that nobody is writing documention for the Windows functions > anyway, I don't think the documentation of standard C library > functions is an issue at all. Well, lack of people writing documentation is a problem in most open source projects and Wine doesn't seem to be an exception. However, denying people the possiblity to do so for some functions doesn't help either. > > I can't fix winapi_check properly. I can kludge it yes, but fix no. > > Your proposed solution is not fixing it either, it's just moving the > kludge from winapi_check directly into the source. And that's not a > good thing IMO. What kludge? Ugly OK, that is your subjective opinion, but kludge? Even if we only see it from a purely C language perspective, it solves the problem of making sure that the C library functions have the prototypes we expect them to have. There is no other way to solve that problem that I can think of so it is certainly not a kludge. Of course you can always argue that it is a solution searching for a problem, but that is not a what I would call a kludge. Anyway, arguing about misuse of words is a waste of time and I don't think I have anything more to add that are likely to convince you. If you are not convinced now, you never will be.

July 14, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > However I'm a little curious where the documentation, > and yes I'm talking about real documentation not just > the external name and the ordinal, should be placed. > Sure you have the underlying Unix man pages at least > if we are talking about the MSVCRT and NTDLL functions, > but it would be nice to have a proper Windows style > man page for them eventually. Given that nobody is writing documention for the Windows functions anyway, I don't think the documentation of standard C library functions is an issue at all. > I can't fix winapi_check properly. I can kludge it yes, but fix no. Your proposed solution is not fixing it either, it's just moving the kludge from winapi_check directly into the source. And that's not a good thing IMO. -- Alexandre Julliard julliard(a)winehq.com

July 14, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > What primarily intrests me now is how should the needed > information be > > stored? The problem with normal entry point is solved, the > question is > > how the stubs and forwards should be stored? Before we know that > > we can't really write any working extraction tool can we? > > Sure we can, that's the easy part; the hard part is making it work for > the normal entry points. And I'm not going to add anything to support > stubs etc. until it's clear that we can do it for normal entry points > in a way that I consider acceptable. Fair enough. However note that I'm not suggesting that we shuld. I said "While we probably should not actually change the .c files to look like this until we have a tool of acceptable complexity that can generate the .spec files, there is quite a few preparations that need to be done before that" But OK, I will concentrate on supporting normal entry points in an acceptable way first. > > While we probably should not actually change the .c files to > > look like this until we have a tool of acceptable complexity > > that can generate the .spec files, there is quite a few preparations > > that need to be done before that and I would really like to have the > > "Exported external functions" patch applied in the meantime > > for other reasons like winapi_check likes to know where all > > the DLL:s functions are "implemented". > > Then fix winapi_check. I don't want to have to add a bunch of external > declaration for C library functions, that's very ugly. First of all ugly is subjective, I can't see what is ugly about it, but OK you decide what you want, so arguing that point is no use. However I'm a little curious where the documentation, and yes I'm talking about real documentation not just the external name and the ordinal, should be placed. Sure you have the underlying Unix man pages at least if we are talking about the MSVCRT and NTDLL functions, but it would be nice to have a proper Windows style man page for them eventually. Perhaps the some of the functions have some limitation in Windows that the Unix variant doesn't have (or vice versa) and thus if you extend the Winelib application you really want to know that, so the Unix man page will not really be enough. So yes, I'm really curious to know where you think the documentation should be placed. I think my solution is quite good since it solve three problem. 1. Provides somewhere to write the documentation 2. Provides a C compiler checkable prototype that can give a warning if any of the native system functions happends to have another prototype. 3. Helps tools like winapi_check a place to check things that the .spec files entries are correct. Even if you still considers it ugly, it might be worth it considering what you get. > So no, I'm not > going to apply your patch. I can't fix winapi_check properly. I can kludge it yes, but fix no. There is no implementation or anything else in the source that indicates that it is supposed to use functions from another DLL. But sure I can kludge winapi_check to ignore the atom functions and lstrcmpi in USER. The functions from the C Library is already kludged since a long time ago, so what the hell lets just add another kludge, it is only 5 new functions. If you don't apply it I don't have much choice have I.

July 14, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > What primarily intrests me now is how should the needed information be > stored? The problem with normal entry point is solved, the question is > how the stubs and forwards should be stored? Before we know that > we can't really write any working extraction tool can we? Sure we can, that's the easy part; the hard part is making it work for the normal entry points. And I'm not going to add anything to support stubs etc. until it's clear that we can do it for normal entry points in a way that I consider acceptable. > While we probably should not actually change the .c files to > look like this until we have a tool of acceptable complexity > that can generate the .spec files, there is quite a few preparations > that need to be done before that and I would really like to have the > "Exported external functions" patch applied in the meantime > for other reasons like winapi_check likes to know where all > the DLL:s functions are "implemented". Then fix winapi_check. I don't want to have to add a bunch of external declaration for C library functions, that's very ugly. So no, I'm not going to apply your patch. -- Alexandre Julliard julliard(a)winehq.com

July 14, 2001

Re: Handling X errors using exception handlers

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > When discussing with Ove yesterday on #WineHQ about the handling of X > errors, he told me about an idea of his : using exceptions to handle X > errors. The main problem with that is that I don't think you can jump out of Xlib without corrupting its state. Also you'd need to properly unlock the tsx11 lock in case of exception, which will probably require an finally handler around each X call. My idea was to have the following two functions: void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); int X11DRV_check_error(void); You'd call X11DRV_expect_error before doing an X call that can fail; then if an X error happens that matches what you expect, the X error handler will simply set a flag and ignore the error (if it doesn't match you get the standard error handling). Then after the call you use X11DRV_check_error to see if your error happened or not. Would this work for what you need? -- Alexandre Julliard julliard(a)winehq.com

July 14, 2001

Re: hello all

by Travis Michielsen

Hi all, After reading Brandon's message I was inspired to introduce myself to this list as well. Although I have been following wine for several months now, I have just recently started wine development (only 1 small patch so far :-( ). Currently I am focusing on learning the API before I persue patches that are significantly larger, but have started a todo list. I am an avid C/C++ programmer and have experimented with serveral other languages including Java(script), Pascal, Basic, etc. I have done allot of programming for Windows/DOS in the past but when I discovered linux about 2 years ago, I immediately switched OS's and began pursuing linux programming. I do, however, still run windows occasionally, when I have trouble running programs under wine, but I believe that someday (hopefully sooner rather than latter), we will be able to use linux (and wine) to run almost every program without thought. Anyways, Welcome Brandon, and Hello All. :) Travis Michielsen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

July 14, 2001

[PATCH] dde unicode warning

by Gerard Patel

ChangeLog: * dlls/user/dde/misc.c Fix unicode warning

July 14, 2001

[PATCH] Toolbar : image list can be changed after TB_SETIMAGELIST;

by Gerard Patel

The imagelist of a toolbar can be changed by the app after it has set it to the toolbar (using TB_SETIMAGELIST). In this case the bitmap number can be wrong, leading to some apps not displaying text correctly (although the bitmaps were still showing because of Wine code not really testing for bitmap number in this case). Fix for Winzip 8.0, replaces the preceding one (same problem) ChangeLog: * dlls/comctl32/toolbar.c Refresh bitmap count to take in account imagelist changes after TB_SETIMAGELIST

July 14, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Well, there is the issue of maintaining redundant information. > > Sure winapi_check can (and indeed was the original reason for it) > > find missmatchs. But given the number of errors I have seen people > > make that winapi_check detected, we really should avoid having > > redundant information if we can. > > If there is an easy way to avoid it, sure. But if it requires a Perl > script as complex as winapi_check, especially the maintaining of the > *.api files, I'm not sure it's a win. Well the *.api files (or at least the manual maintainance of them) will be eliminated some day. I will just have to implement parsing of the "typedefs" in the headers. However, note that I'm not suggesting that we change to automatic generation of spec files right now, but at some point in the future. What tool we should for it is a later problem. With the exception of which types maps to which "kinds" (long ptr str wstr) the tool will not nessarily be very complex and I'm not sure what the parsing of typedefs to find out will be very complex either. But I wont know until I try. What primarily intrests me now is how should the needed information be stored? The problem with normal entry point is solved, the question is how the stubs and forwards should be stored? Before we know that we can't really write any working extraction tool can we? While I'm not entirely happy with your: /* ##spec## foo "@ forward bar(ptr str) BAZ.bar" */ solution it is the better that any ideas I have. Simplicity has its charm. :-) Then we could just, taking USER as example add /* ##spec## user "name user" */ /* ##spec## user "type win16" */ /* ##spec## user "heap 65520" */ /* ##spec## user "file user.exe" */ /* ##spec## user "owner user32" */ /* ##spec## user "rsrc resources/version16.res" */ /* ##spec## user "2 stub OldExitWindows" */ /* ##spec## user "3 stub EnableOEMLayer" */ /* ##spec## user "4 stub DisableOEMLayer" */ /* ... */ in a appropriate place in say dlls/user/user_main.c. The order that winapi_extract finds the directive is not important the .spec file format happends to make it possible to always get everything in the right order anyway. However this solves the header, the debug_channels, forwards and stubs problem and could be used to solve the remaining problems with "Exported external functions" but I would rather have it solved with my patch with that name, that you didn't apply when applying the other patches. So will accept such a solution? While we probably should not actually change the .c files to look like this until we have a tool of acceptable complexity that can generate the .spec files, there is quite a few preparations that need to be done before that and I would really like to have the "Exported external functions" patch applied in the meantime for other reasons like winapi_check likes to know where all the DLL:s functions are "implemented". > And it seems to me you are > finding a lot more errors in the comments than in the spec files ;-) Well, considering that our developers have neglected the comments for many year and only changing the spec files that is not very suprising. That is the problem with having redundant information, most developers only change where it really count either out of ignorance or lack of time. > > In addition it will be much easier for the developers (especially > > newbies). If you change the prototype in the .c files or the > > ordinal in the comment above it, it will be enough. Stub files > > will be something normal developers needn't concern himself with. > > If normal developers need to change the spec file for an existing > function, something is seriously wrong. The spec entry is dictated by > the dll interface, and there is no reason to change it (except maybe > to change a 'ptr' into an 'str', but this is a cosmetic issue). Well, you also have implementing new functions. You have FooA and want to implement FooW for example. It is much easier and much more natural to be able to just cut and paste without having to change the spec files. I have seen many such errors detected by winapi_check over the years.

July 14, 2001

Handling X errors using exception handlers

by Lionel Ulmer

Hi all, When discussing with Ove yesterday on #WineHQ about the handling of X errors, he told me about an idea of his : using exceptions to handle X errors. This way, when we have to explicitely handle X errors (as we will need to do for XVidmode and XDGA2 due to some (stupidly done IMHO :-) ) security fixes in XFree 4.x), we could do that using exceptions. Before doing this 'properly' (ie change the X11 drv, update the XShm error mechanism, the debugger, ...), here is what I did for now : 1) I created a new Wine-private exception type in include/wine/exception.h : /* unhandled X error */ #define EXCEPTION_WINE_X11DRV 0x80000104 2) I created a new X error handler that is installed at X11DRV initialization : static int X11DRV_XErrorHandler(Display *dpy, XErrorEvent *event) { EXCEPTION_RECORD rec; rec.ExceptionCode = EXCEPTION_WINE_X11DRV; rec.ExceptionFlags = 0; rec.ExceptionRecord = NULL; rec.ExceptionAddress = XGLErrorHandler; rec.NumberParameters = 4; rec.ExceptionInformation[0] = (DWORD)event->serial; rec.ExceptionInformation[1] = (DWORD)event->error_code; rec.ExceptionInformation[2] = (DWORD)event->request_code; rec.ExceptionInformation[3] = (DWORD)event->minor_code; RtlRaiseException(&rec); return 0; } 3) I changed the XVidMode detection code thus : /* handle only X errors */ static WINE_EXCEPTION_FILTER(xerror_handler) { switch (GetExceptionCode()) { case EXCEPTION_WINE_X11DRV: return EXCEPTION_EXECUTE_HANDLER; default: return EXCEPTION_CONTINUE_SEARCH; } } (...) void X11DRV_XF86VM_Init(void) { (...) wine_tsx11_lock(); (...) __TRY { if (!XF86VidModeQueryVersion(gdi_display, &xf86vm_major, &xf86vm_minor)) { xf86vm_major = 0; } XSync(gdi_display, False); } __EXCEPT(xerror_handler) { xf86vm_major = 0; } __ENDTRY wine_tsx11_unlock(); if (xf86vm_major == 0) { TRACE("No XVidmode\n"); return; } (...) } So what do you all think of this ? Is this something that I should add to the whole Wine tree ? The only problem with that is that it would make debugging X errors a bit more difficult as we won't have the standard X error message in debug reports from users... Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 14, 2001

cvs changes

by mdew

i havent had any problems until i updated to the latest CVS.., what exactly changed to cause this to pop up? (Using mIRC etc) fixme:console:SetConsoleCtrlHandler (0x3000f330,0) - no error checking or testing yet

July 14, 2001

Re: GetCommState16 ....

by Mike McCormack

Hey Lawson, thanks for sending Juno... i got it, but i haven't tried it yet... i thought i'd just keep patching a bit at a time until somebody complained :-) If anybody knows of any free win3.1 terminal programs, please tell me. Anyhow, this is my TODO list: * use SetCommState in SetCommState16 * save and restore m_stat using Get/SetCommState in OpenComm16 * use ReadFileEx/WriteFileEx instead of service thread * finally, move 16bit comm implementation to USER Mike > Good day! > > If you get this, neither this patch nor any of the recently committed > patches that muck with 16 bit comms bother my 16 bit comms app. > > Mike, did you not get juno.tar.gz or do you just not want to be bothered > filling in the junk to make a new account? > > Regards, > > Lawson ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

July 14, 2001

Re: PATCH: createwindow small unicode prob

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > WM_NCCREATE has a A/W struct, so check unicode flag for which call > to use. In what case did this cause a problem? The desktop window proc is Unicode-only, and the structure doesn't contain strings anyway, so it shouldn't make a difference. -- Alexandre Julliard julliard(a)winehq.com

July 14, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Well, there is the issue of maintaining redundant information. > Sure winapi_check can (and indeed was the original reason for it) > find missmatchs. But given the number of errors I have seen people > make that winapi_check detected, we really should avoid having > redundant information if we can. If there is an easy way to avoid it, sure. But if it requires a Perl script as complex as winapi_check, especially the maintaining of the *.api files, I'm not sure it's a win. And it seems to me you are finding a lot more errors in the comments than in the spec files ;-) > In addition it will be much easier for the developers (especially > newbies). If you change the prototype in the .c files or the > ordinal in the comment above it, it will be enough. Stub files > will be something normal developers needn't concern himself with. If normal developers need to change the spec file for an existing function, something is seriously wrong. The spec entry is dictated by the dll interface, and there is no reason to change it (except maybe to change a 'ptr' into an 'str', but this is a cosmetic issue). -- Alexandre Julliard julliard(a)winehq.com

July 14, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > For normal entry point, however, I respectfully disagree. > > One of the major reasons of having automatically > > generated .spec files is to avoid having to > > store redundant information. The needed information > > is already in the C function declaration and storing > > in a comment as well brings us back to the current > > situation. Sure it makes that generator less > > complicatated but it really isn't that important > > as long as it is reliable and not ambigeous. > > IMO, this is true if we can make the generator work purely on the > source code, so that you can give it the unmodified source of a > Windows dll and it spits out the spec file. If you need to add > comments before each and every exported function, then I don't see > much advantage to parsing the source. You might as well put all the > information in the comment (or leave it in the current spec file for > that matter). Well, the ordinal of each function and for that that matter which functions that should be exported must be specified somewhere. Currently winapi_extract takes this information from the comment lines looking like this in the nearest preceding comment: * Foo (BAR.@) All non-static functions with such preceding comment line(s) is considered exported using the name specified in the comment as the external name. Of course, I can take this information from anywhere, but for obvious reason I can't guess it. If the unmodified source contains Microsoft Visual C++ __declspec(dllexport) directives or the project has a Microsoft Export file (a .def file) I can generate a spec file. This is not supported yet, but is no particular problem supporting in itself. A little worse problem is that I currently doesn't extract the function "kinds" (long ptr double str wstr) from the source but use the tools/winapi_check/win{16,32}/*.api files to determine the "kinds". This is not a teoretical problem, however it might take some time to fix all the same. But after that winapi_extract will be able to take unmodified source if __declspec(dllexport) directives or a .def file exists. However I think we concentrate primarily on the Wine source. I think as far the it is concerned it will suffice to use comment lines like * Foo (BAR.@) to extract the normal entries for the spec files. The stubs and forwards need to have special handling but then so must it in the case of __declspec(dllexport) directives or a .def file as well. There is no problem for winapi_extract to support all the above either (except implementation time of course). > Basically, if the source parsing allows doing more than we do now > (like build spec files for new dlls) it's worthwhile; if all it does > is generate the existing spec files some other way I don't think > there's much point. After all, we have the spec files already, and > they are not going to change much. Well, there is the issue of maintaining redundant information. Sure winapi_check can (and indeed was the original reason for it) find missmatchs. But given the number of errors I have seen people make that winapi_check detected, we really should avoid having redundant information if we can. In addition it will be much easier for the developers (especially newbies). If you change the prototype in the .c files or the ordinal in the comment above it, it will be enough. Stub files will be something normal developers needn't concern himself with. > Another use of the source parser could be to generate more detailed > debugging information for +relay; but in this case I'd say it should > go to a completely different file, used by some external relay dumping > program. I don't want all the extra debug information to clutter up > the spec files. That is another thing that I have planned to do with winapi_extract. I don't have any good idea how this should look like yet. You (or somebody else) are welcome to write a specification on exactly what you want so I can fix the how when I have time.

July 13, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > For normal entry point, however, I respectfully disagree. > One of the major reasons of having automatically > generated .spec files is to avoid having to > store redundant information. The needed information > is already in the C function declaration and storing > in a comment as well brings us back to the current > situation. Sure it makes that generator less > complicatated but it really isn't that important > as long as it is reliable and not ambigeous. IMO, this is true if we can make the generator work purely on the source code, so that you can give it the unmodified source of a Windows dll and it spits out the spec file. If you need to add comments before each and every exported function, then I don't see much advantage to parsing the source. You might as well put all the information in the comment (or leave it in the current spec file for that matter). Basically, if the source parsing allows doing more than we do now (like build spec files for new dlls) it's worthwhile; if all it does is generate the existing spec files some other way I don't think there's much point. After all, we have the spec files already, and they are not going to change much. Another use of the source parser could be to generate more detailed debugging information for +relay; but in this case I'd say it should go to a completely different file, used by some external relay dumping program. I don't want all the extra debug information to clutter up the spec files. -- Alexandre Julliard julliard(a)winehq.com

July 13, 2001

Re: GetCommState16 ....

by lawson_whitney＠juno.com

Good day! If you get this, neither this patch nor any of the recently committed patches that muck with 16 bit comms bother my 16 bit comms app. Mike, did you not get juno.tar.gz or do you just not want to be bothered filling in the junk to make a new account? Regards, Lawson ---cut--- ________________________________________________________________ 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.

July 13, 2001

Re: hello all

by Brandon Kilgore

At 07:10 PM 7/13/01 +0200, Andreas Mohr wrote: >On Thu, Jul 12, 2001 at 05:57:46PM -0400, Brandon Kilgore wrote: > > Hi everyone, > > Just letting you all know that there's a new listener out here, > eager to > > pick up on what you're discussing. I'm only 17, so I'll be pretty much >Cool ! :-) > > > Anyways, I'll let you all get back to the important development > > discussions. I'll be talking to you... >If you have *any* questions about hacking on Wine, just bother me until >answering your questions is the last resort ;-) > >Frankly spoken, we need *way* more developers. >We've got about 20 active core developers right now, and Wine could *easily* >handle 3 times that much without stepping on each other's toes... > >Thanks ! > >-- >Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany >Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/ :-) Thanks for the response. I'll let you know when I need to pick your brain. Until then, count each day as a blessing ;-) - Brandon Kilgore "The manual said it required Windows 95 or better, so I installed Linux"

July 13, 2001

Re: hello all

by Andreas Mohr

On Thu, Jul 12, 2001 at 05:57:46PM -0400, Brandon Kilgore wrote: > Hi everyone, > Just letting you all know that there's a new listener out here, eager to > pick up on what you're discussing. I'm only 17, so I'll be pretty much Cool ! :-) > Anyways, I'll let you all get back to the important development > discussions. I'll be talking to you... If you have *any* questions about hacking on Wine, just bother me until answering your questions is the last resort ;-) Frankly spoken, we need *way* more developers. We've got about 20 active core developers right now, and Wine could *easily* handle 3 times that much without stepping on each other's toes... Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

July 13, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Like: > > > > > /************************************************************* > ********** > > * strcpy (MSVCRT.@) > > */ > > #if 0 /* Suppress warnings */ > > extern char *strcpy(char *dest, const char *src); > > #endif > > > > Perhaps we could do the same with atom functions and lstrcmpi? > > The #if 0 #endif isn't even needed for them I believe. > > That's quite ugly IMO. The #if 0 #endif or having to have a documentation comment at all? Anyway the #if 0 is not needed I thought it might be needed in some cases but it is not. I mistakingly believed it might be type conflicts but it can't be since any exported function must of course use the C library types otherwise you can't export them directly. If you are refering to the documentation comment, I can't really see why. All other functions have it and adding additional documentation might be a good idea in some cases as well. Furthermore the extern declaration makes it possible for the C compiler to check that the prototype is the same as the prototype in the included files. I spotted several error when doing the patch because of this. As hinted above, I have implemented a working solution that does what I have described above. See separate mail. > As long as we require comments, we might as > well put everything explicitly in the comment, something like: > > /* ##spec## msvcrt "@ cdecl strcpy(ptr str) strcpy" */ > > (we can probably come up with a better syntax, but you get the idea). > Then we can simply grep for '##spec##' and extract everything into the > spec file. We can do the same for forwards etc. (and in fact we could > do it for normal entry points as well). For forwards, stubs and other special cases, perhaps. I don't like it very much but it is acceptable. But we need not decide that now. I will think more about it and come back later with some kind of proposal that might or might not match yours. I'm not sure, we will see. For normal entry point, however, I respectfully disagree. One of the major reasons of having automatically generated .spec files is to avoid having to store redundant information. The needed information is already in the C function declaration and storing in a comment as well brings us back to the current situation. Sure it makes that generator less complicatated but it really isn't that important as long as it is reliable and not ambigeous. PS. For the record: I consider winapi_extract a prototype not something that nessary will finally use in "production". We might of course use it, but I would rather rewrite it so it becomes simpler and more reliable. Perhaps it shouldn't be in Perl but in C instead? Oh, well, that is a minor issue compared to how the information should be stored.

July 13, 2001

To strip or not to strip

by Jeremy White

We've always built the CodeWeavers Wine RPM unstripped, in the theory that it made supporting Wine newbies easier. However, AFAICT from watching cemw, we never get into a situation where a newbie goes into winedbg; more often, they shift first to the CVS tip, and from there maybe to winedbg. So, it seems like shipping debug symbols may just be a waste of bandwidth. (Note, we build with all full logging enabled, and we'll never change that). However, before we go ahead and yank the debug info out of our RPM, I thought I'd post a note, and let someone tell me if I'm wrong. Thanks, Jer

July 13, 2001

Re: Documentation fixes

by Brandon Kilgore

At 04:15 PM 7/12/01 -0700, Alexandre Julliard wrote: >Then we can simply grep for '##spec##' and extract everything into the >spec file. We can do the same for forwards etc. (and in fact we could >do it for normal entry points as well). I like that idea - Brandon

July 12, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Like: > > /*********************************************************************** > * strcpy (MSVCRT.@) > */ > #if 0 /* Suppress warnings */ > extern char *strcpy(char *dest, const char *src); > #endif > > Perhaps we could do the same with atom functions and lstrcmpi? > The #if 0 #endif isn't even needed for them I believe. That's quite ugly IMO. As long as we require comments, we might as well put everything explicitly in the comment, something like: /* ##spec## msvcrt "@ cdecl strcpy(ptr str) strcpy" */ (we can probably come up with a better syntax, but you get the idea). Then we can simply grep for '##spec##' and extract everything into the spec file. We can do the same for forwards etc. (and in fact we could do it for normal entry points as well). -- Alexandre Julliard julliard(a)winehq.com

July 12, 2001

hello all

by Brandon Kilgore

Hi everyone, Just letting you all know that there's a new listener out here, eager to pick up on what you're discussing. I'm only 17, so I'll be pretty much staying out of the way, but I love programming so hopefully you won't mind if I stick my hand up to ask a question or respond to someone every once in a while. Just so you can know a bit about me...I used to be a purely QBasic programmer in my "early" days, but a few years ago I began broadening my horizons, mostly with HTML and Visual Basic. For a long time I had wanted to learn C but never really got around to it, but a little over a year ago I finally sat down and started learning, and now its one of the only languages I ever use. Some other languages I currently program in (or would come back to me if need be :-) : C/C++/Visual C++ (Q)Basic/Visual Basic HTML Perl BF (there's an interesting language...) Java/JavaScript WISE InstallMaster scripting ;-) Anyways, I'll let you all get back to the important development discussions. I'll be talking to you... - Brandon

July 12, 2001

RE: Documentation fixes

by Patrik Stridvall

> > The problem is that if I say that the memory directory doesn't > > "belong" to dlls/user/user.spec winapi_{check,extract,fixup} will > > not find implementations for all functions, which will cause > > problems. > > > > For example how should winapi_extract know that I should > generate the line > > 471 pascal16 lstrcmpi(str str) lstrcmpiA > > when it generates the spec files? > > Well, it's a more general problem, namely that the spec files can > reference functions that are not implemented directly in the dll. > > You also have for instance: > > @ cdecl strcpy(ptr str) strcpy > > in MSVCRT, and strcpy is clearly not implemented there since it's in > the C library. So you cannot assume that only the functions contained > in the dll can be used in the spec files, it is legal for the spec > file to reference external functions. True. I didn't even thought of that particular problem. Functions like strcpy is currently suppressed by having it listed in tools/winapi_check/nativeapi.dat, but that is a little kludgy. [Thinking...] Well you could simply have an function documentation comment without a function implementation in some file that belongs to MSVCRT. Like: /*********************************************************************** * strcpy (MSVCRT.@) */ #if 0 /* Suppress warnings */ extern char *strcpy(char *dest, const char *src); #endif Perhaps we could do the same with atom functions and lstrcmpi? The #if 0 #endif isn't even needed for them I believe. > > I think that we need to move the solution of this problem one step > > up the "ladder" and discuss the more general problem: > > How should we store the information needed to generate > > the spec files in the source, especially concerning > > the forwards and stubs? > > You'll need a file somewhere that specifies all the entries that > cannot be determined automatically from the source. You simply cannot > build a 100% correct spec file based only on the function comments. Yes. I have some ideas, but no really good one. My currently best suggestion is having a .spec.in file that approximately looks like the .spec files but supports configure like substitutions. foo.spec.in: ---8<--- name foo type win32 init @init@ rsrc foo.res import baz.dll @debug_channels@ 101 forward Bar BAZ.Bar 102 stub BarFoo @fixed@ @ forward Foo BAZ.Foo @ stub FooBar @unfixed@ ---8<--- And simply let winapi_extract or whatever simple substitute @init@, @debug_channels@, @fixed@ and @unfixed@ with what can be extracted from the source. > And you definitely do not want to need to parse KERNEL source files > (like the ones in memory/) to build the USER spec file. Of course. The question was whether the memory directory belongs to USER or not. I have now accepted that it does not.

July 12, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > > No, USER does not use the memory directory. It links directly to > > libkernel32.so because it needs some internal functions in there, > > Like the atom functions that are implemented in memory/atom.c I guess > you mean. Actually no, the atom functions are similar to lstrcmpi, they are exported from kernel so we don't need to link to libkernel32.so to get them (and they shouldn't have USER comments either). The real problem is the internal kernel functions called by user, things like THUNK_Alloc or LOCAL_Alloc. > The problem is that if I say that the memory directory doesn't > "belong" to dlls/user/user.spec winapi_{check,extract,fixup} will > not find implementations for all functions, which will cause > problems. > > For example how should winapi_extract know that I should generate the line > 471 pascal16 lstrcmpi(str str) lstrcmpiA > when it generates the spec files? Well, it's a more general problem, namely that the spec files can reference functions that are not implemented directly in the dll. You also have for instance: @ cdecl strcpy(ptr str) strcpy in MSVCRT, and strcpy is clearly not implemented there since it's in the C library. So you cannot assume that only the functions contained in the dll can be used in the spec files, it is legal for the spec file to reference external functions. > I think that we need to move the solution of this problem one step > up the "ladder" and discuss the more general problem: > How should we store the information needed to generate > the spec files in the source, especially concerning > the forwards and stubs? You'll need a file somewhere that specifies all the entries that cannot be determined automatically from the source. You simply cannot build a 100% correct spec file based only on the function comments. And you definitely do not want to need to parse KERNEL source files (like the ones in memory/) to build the USER spec file. -- Alexandre Julliard julliard(a)winehq.com

July 12, 2001

RE: Documentation fixes

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > PS. And yes, the added lstrcmpi (USER.471) in memory/string.c > > should really be there. Both KERNEL and USER uses the memory > > directory. > > No, USER does not use the memory directory. It links directly to > libkernel32.so because it needs some internal functions in there, Like the atom functions that are implemented in memory/atom.c I guess you mean. > but > that's a different problem. lstrcmpi is a purely KERNEL function, that > happens to be imported by USER (and by other dlls too), That might be so, but it is also _exported_ by USER: grep lstrcmpi dlls/user/user.spec 471 pascal16 lstrcmpi(str str) lstrcmpiA and lstrcmpiA is not implemented anyware else The same goes for the atom functions: grep Atom dlls/user/user.spec 268 pascal16 GlobalAddAtom(str) GlobalAddAtomA 269 pascal16 GlobalDeleteAtom(word) GlobalDeleteAtom 270 pascal16 GlobalFindAtom(str) GlobalFindAtomA 271 pascal16 GlobalGetAtomName(word ptr s_word) GlobalGetAtomNameA > so USER must > not be mentioned in the comment IMO. The problem is that if I say that the memory directory doesn't "belong" to dlls/user/user.spec winapi_{check,extract,fixup} will not find implementations for all functions, which will cause problems. For example how should winapi_extract know that I should generate the line 471 pascal16 lstrcmpi(str str) lstrcmpiA when it generates the spec files? Of course the automatic generation of spec files is not 100% complete most importantly handling of forwards and stubs is not supported. I think that we need to move the solution of this problem one step up the "ladder" and discuss the more general problem: How should we store the information needed to generate the spec files in the source, especially concerning the forwards and stubs? I will address this issue in a separate mail, but you are welcome to add comments specific to this problem in this thread, I'm not sure I feel to writing it today. I have been postponing the writing of mail for quite some time and I'm currenly beginning to get rather tired. PS. Why not as an interim solution simply add support for forward in the Win16 spec files so 471 pascal16 lstrcmpi(str str) lstrcmpiA becomes 471 forward lstrcmpi(str str) USER32.lstrcmpiA which winebuild until actual need simply interprets as 471 pascal16 lstrcmpi(str str) lstrcmpiA Hmm. Perhaps we should have forward16 and forward to separate the pascal16 and pascal cases? Anyway this gives winapi_{check,fixup} enough information to handle the situation where the memory directory doesn't "belong" to dlls/user/user.spec.

July 12, 2001

Re: New problems with the debugger

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> WineDbg starting... file_set_error: No such process Can't attach >> process 8068d98: error 317 Alexandre> I don't see this here. Could you please run wineserver under Alexandre> gdb, put a breakpoint on the file_set_error message Alexandre> (server/file.c line 334), and send me the backtrace at this Alexandre> point? Thanks. Breakpoint 1, file_set_error () at file.c:334 334 default: perror("file_set_error"); set_error( ERROR_UNKNOWN /* FIXME */ ); break; (gdb) bt #0 file_set_error () at file.c:334 #1 0x804b1e5 in get_thread_context (thread=0x97fa210, flags=65537, context=0xbffff350) at context_i386.c:142 #2 0x804b567 in get_thread_single_step (thread=0x97fa210) at context_i386.c:481 #3 0x8051d2e in continue_thread (thread=0x97fa210) at ptrace.c:177 #4 0x8050e9f in resume_process (process=0x8068d98) at process.c:518 #5 0x804bfc6 in debugger_attach (process=0x8068d98, debugger=0x97fa778) at debugger.c:420 #6 0x804c278 in req_debug_process (req=0xbffff4d8) at debugger.c:540 #7 0x805669f in read_request (thread=0x97fa778) at request.c:168 #8 0x805922b in thread_poll_event (obj=0x97fa778, event=1) at thread.c:157 #9 0x8057642 in select_loop () at select.c:262 #10 0x804e5af in main (argc=1, argv=0xbffff6d4) at main.c:108 #11 0x40178baf in __libc_start_main () from /lib/libc.so.6 Perhaps to notice: I run 2.4.6 on a SMP machine, Suse 7.1 Hope this helps Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 12, 2001

Re: Documentation fixes

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > PS. And yes, the added lstrcmpi (USER.471) in memory/string.c > should really be there. Both KERNEL and USER uses the memory > directory. No, USER does not use the memory directory. It links directly to libkernel32.so because it needs some internal functions in there, but that's a different problem. lstrcmpi is a purely KERNEL function, that happens to be imported by USER (and by other dlls too), so USER must not be mentioned in the comment IMO. -- Alexandre Julliard julliard(a)winehq.com

July 12, 2001

New problems with the debugger

by Uwe Bonnes

Hallo, since the update yesterday evening ( and a fresh update recently), on a crash the debugger has problems like this one: 08067330:Call kernel32.UnhandledExceptionFilter(404e4b00) ret=7800f2b8 fixme:pthread_kill_other_threads_np FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/vol2 (No such file or directory), ignoring drive Y: FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/sys (No such file or directory), ignoring drive Z: WineDbg starting... file_set_error: No such process Can't attach process 8068d98: error 317 Beendet Is this known? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 12, 2001

Re: The [Windows] section

by Alexandre Julliard

"Bill Medland" <medbi01(a)accpac.com> writes: > The answer, for those interested > > In Windows 95 a load of configuration information moved from win.ini (esp > the [windows] section) to the registry. Now (when the edits are added to > the cvs) information should come from the [windows] section of win.ini if > the winelook is WIN31 and from the registry in general otherwise, with the > Tweak.Layout overriding both. Actually I have hacked your patch a bit when committing it (hope you don't mind ;-), with the idea of phasing out the Tweak.Layout stuff. So now the values come from the registry for Win95, and from win.ini (plus some hard-coded values) for Win3.1. -- Alexandre Julliard julliard(a)winehq.com

July 12, 2001

Re: PATCH: internetgetconnectionstate

by Berend Ozceri

Marcus Meissner wrote: > I spent some thought, and detecting how the computer is connected is not > trivial under Linux. You would need to parse either ifconfig -a output or > /proc/net/dev under Linux, then check for packets transmitted, interface > up/down status etc. This would be an ifdef and stringparsing hell. How about looking at the output of the route command (or /proc/net/route) and seeing if there is a default route present? Berend

July 12, 2001

Re: CreateWindow issue?

by Bill Medland

For Information Only Bill Medland <medbi01(a)accpac.com> wrote in article <01c10025$bb647f00$6f0c10ac(a)medbi01>... > Can anyone shed any light on this? > > 1. > If I take Petzold's POPPAD1 project and slightly modify it so that the > style is > WS_CHILD | WS_BORDER | WS_VISIBLE | ES_AUTOHSCROLL > and then spy on the WM_NCCREATE and WM_CREATE it tells me that the style > passed in is > WS_OVERLAPPEDWINDOW | WS_CHILDWINDOW | WS_VISIBLE | ES_AUTOHSCROLL > which is not the same thing. > > Does anyone know if > a. The Windows Spy++ is telling fibs > b. (Win95) CreateWindow patches them up in some way. > > > 2. (Why I was even looking at 1) > In the application I am working on we open Edit controls almost as above > inside dialogs and they appear with a single pixel solid frame under > Windows whereas under Wine they appear with a 2-pixel sunken frame. There > are several changes I can make in the controls/edit.c to get the same > behaviour under Wine but so far they all "mess up" normal sunken ones. > > (Under windows the resulting windows end up with zero extended style and > 50000088 style.) > > Any thoughts would be appreciated. > > Bill > > > > > Guess what. Microsoft Spy++ lies!! When it displays the parameters of the WM_CREATE and WM_NCCREATE messages it gives the actual pointer value and also the contents pointed to by that pointer. In general it is correct but for the style and extended style it doesn't give the hex value; it goes ahead and politely translates it for you into WS_VISIBLE, WS_BORDER etc. However it gets it wrong. You can see that it is wrong by 1. creating your own class and a window of that class and see what it sends you or 2. get the source code for the original spy program, modifying it a little and using it. Of course you can't get hold of the source for spy++ and correct it, as far as I am aware. (I'm getting to like this Open Source idea!!) I wonder how many other lies spy++ tells us. Bill

July 12, 2001

Re: The [Windows] section

by Bill Medland

For Information Only Bill Medland <medbi01(a)accpac.com> wrote in article <01c10410$55812780$6f0c10ac(a)medbi01>... > Is the [Windows] section of the config still supposed to be in use or > should Tweak.Layout be used instead? > > (I am looking at the [Windows].BorderWidth in particular) > > Bill > > > > > The answer, for those interested In Windows 95 a load of configuration information moved from win.ini (esp the [windows] section) to the registry. Now (when the edits are added to the cvs) information should come from the [windows] section of win.ini if the winelook is WIN31 and from the registry in general otherwise, with the Tweak.Layout overriding both. Bill

July 12, 2001

Re: PATCH: internetgetconnectionstate

by Marcus Meissner

> >Changelog: > > Have InternetGetConnectedState always return 'LAN connection'. > > Theoretically this could cause trouble when used with a computer > having no connection to the Internet, as an app could think it can > connect, try to do it, fail and terminate or display annoying messages. > It's not really a strong objection, as most decent computers are > connected to the Internet these days, but maybe a config option could > be better ? Just a thought. I spent some thought, and detecting how the computer is connected is not trivial under Linux. You would need to parse either ifconfig -a output or /proc/net/dev under Linux, then check for packets transmitted, interface up/down status etc. This would be an ifdef and stringparsing hell. I think the application usually has other fault handling in case the website is down anyway, so we should not bother now. Ciao, Marcus

July 12, 2001

Re: msvcrt switching from builtin to native

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > _ismbcdigit is unimplemented. The log looks like wine starts to think with > that call that msvcrt is a native dll. Implementing a semi stub for that > gives the same behaviour at the next unimplemented msvcrt function. This should fix it: Index: loader/pe_image.c =================================================================== RCS file: /opt/cvs-commit/wine/loader/pe_image.c,v retrieving revision 1.94 diff -u -r1.94 pe_image.c --- loader/pe_image.c 2001/05/24 18:43:16 1.94 +++ loader/pe_image.c 2001/07/11 20:50:37 @@ -655,7 +655,7 @@ return NULL; } - if (pe_export) + if (!builtin && pe_export) SNOOP_RegisterDLL( hModule, wm->modname, pe_export->Base, pe_export->NumberOfFunctions ); /* Send DLL load event */ -- Alexandre Julliard julliard(a)winehq.com

July 11, 2001

Re: msvcrt switching from builtin to native

by Aric Stewart

I was just noticing similar situations with urlmon when i we debugging something today. I thought there must be something wrong with my setup, but if you are seeing it also that is interesting. -aric > Hallo, > > trying to run msdev.exe with builtin msvcrt, at some point thins strange > +snoop,+relay log appears: > > 08066950:Call msvcrt._strdup(4040b294 "Microsoft Visual C++") ret=5f416652 > 08066950:Call kernel32.HeapAlloc(40390000,00000000,00000015) ret=4063d846 > 08066950:Ret kernel32.HeapAlloc() retval=4041c338 ret=4063d846 > 08066950:Ret msvcrt._strdup() retval=4041c338 ret=5f416652 > 08066950:Call msvcrt._mbsinc(5f49d450 "%d") ret=5f4160fb > 08066950:Ret msvcrt._mbsinc() retval=5f49d451 ret=5f4160fb > 08066950:Call msvcrt.atoi(5f49d451 "d") ret=5f41614d > 08066950:Ret msvcrt.atoi() retval=00000000 ret=5f41614d > 08066950:CALL msvcrt.292: _ismbcdigit(<unknown, check return>) ret=5f416161 > ^^^^ > 08066950:Call ntdll.RtlRaiseException(406064e0) ret=40631056 > 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 > 08066950:Call ntdll.RtlRaiseException(406061d0) ret=40631056 > 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 > > _ismbcdigit is unimplemented. The log looks like wine starts to think with > that call that msvcrt is a native dll. Implementing a semi stub for that > gives the same behaviour at the next unimplemented msvcrt function. > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 11, 2001

msvcrt switching from builtin to native

by Uwe Bonnes

Hallo, trying to run msdev.exe with builtin msvcrt, at some point thins strange +snoop,+relay log appears: 08066950:Call msvcrt._strdup(4040b294 "Microsoft Visual C++") ret=5f416652 08066950:Call kernel32.HeapAlloc(40390000,00000000,00000015) ret=4063d846 08066950:Ret kernel32.HeapAlloc() retval=4041c338 ret=4063d846 08066950:Ret msvcrt._strdup() retval=4041c338 ret=5f416652 08066950:Call msvcrt._mbsinc(5f49d450 "%d") ret=5f4160fb 08066950:Ret msvcrt._mbsinc() retval=5f49d451 ret=5f4160fb 08066950:Call msvcrt.atoi(5f49d451 "d") ret=5f41614d 08066950:Ret msvcrt.atoi() retval=00000000 ret=5f41614d 08066950:CALL msvcrt.292: _ismbcdigit(<unknown, check return>) ret=5f416161 ^^^^ 08066950:Call ntdll.RtlRaiseException(406064e0) ret=40631056 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 08066950:Call ntdll.RtlRaiseException(406061d0) ret=40631056 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 _ismbcdigit is unimplemented. The log looks like wine starts to think with that call that msvcrt is a native dll. Implementing a semi stub for that gives the same behaviour at the next unimplemented msvcrt function. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 11, 2001

Early crash with msdev.exe

by Uwe Bonnes

Hallo, trying msdev.exe from Microsoft Visual C in a demonstration at Linuxtag, I was astonished how far wine proceeds. Only when trying to create a template, wine crashed. Trying to debug with snoop, however the crash happens much earlier. I tried to look hard at snoop.c, but couldn't find where this error may originate from. Has anybody some idea? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- 08066950:RET msvcrt.658: malloc() retval = 40b01f20 ret=50043066 tid=08066950 08066950:CALL msvcrt.272: _initterm() ret=50043090 08066950:CALL devshl.1603: @(00000700,00000081,00000000,40605ad4,4060576c) ret=50301f0a 08066950:RET devshl.1603: @() retval = 00000000 ret=50301f0a tid=08066950 08066950:CALL mfc42.6374: @(<unknown, check return>) ret=50301f51 08066950:CALL mfc42.5163: @(<unknown, check return>) ret=5f401aff 08066950:CALL msvcrt.67: _EH_prolog(4101007d,00000081,00000000,40605ad4,40605728,40b06da0,00000000,40605748,41010064,00000081,00000000,40605ad4,40b06da0,40b06da0,40605764,50301f1f, ...) ret=5f401b2b 08066950:RET msvcrt.67: _EH_prolog() retval = 41010096 ret=5f401b2b tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.203: _except_handler3(<unknown, check return>) ret=4006ac97 08066950:CALL msvcrt.73: _XcptFilter(<unknown, check return>) ret=0040175d fixme:pthread_kill_other_threads_np FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/vol2 (No such file or directory), ignoring drive Y: FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/sys (No such file or directory), ignoring drive Z: WineDbg starting... on pid 80683b0 No debug information in 32bit DLL '<Debugged process>' (0x00400000) Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000da00 (_end+0x37fc1284) Loaded debug information from ELF '/spare/bon/wine/dlls/libntdll.so' (0x40026000) Loaded debug information from ELF '/spare/bon/wine/libwine.so' (0x40127000) Loaded debug information from ELF '/spare/bon/wine/libwine_unicode.so' (0x4013d000) Loaded debug information from ELF '/lib/libncurses.so.5' (0x40205000) Loaded debug information from ELF '/lib/libm.so.6' (0x4024f000) No debug information in ELF '/lib/libutil.so.1' (0x4026d000) No debug information in ELF '/lib/libdl.so.2' (0x40270000) Loaded debug information from ELF '/lib/libc.so.6' (0x40273000) Loaded debug information from ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/spare/bon/wine/dlls/libkernel32.so' (0x40617000) Loaded debug information from ELF '/spare/bon/wine/dlls/libgdi32.so' (0x406b4000) Loaded debug information from ELF '/spare/bon/wine/dlls/libadvapi32.so' (0x40723000) Loaded debug information from ELF '/spare/bon/wine/dlls/libuser32.so' (0x40762000) Loaded debug information from ELF '/spare/bon/wine/dlls/libshell32.so' (0x40882000) Loaded debug information from ELF '/spare/bon/wine/dlls/libshlwapi.so' (0x408e8000) Loaded debug information from ELF '/spare/bon/wine/dlls/libcomctl32.so' (0x40923000) Loaded debug information from ELF '/spare/bon/wine/dlls/libx11drv.so' (0x40c00000) Loaded debug information from ELF '/spare/bon/wine/libwine_tsx11.so' (0x40741000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40019000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40c4d000) No debug information in ELF '/usr/X11R6/lib/libXpm.so.4' (0x40c65000) No debug information in ELF '/usr/X11R6/lib/libXxf86dga.so.1' (0x40387000) No debug information in ELF '/usr/X11R6/lib/libXxf86vm.so.1' (0x404e5000) No debug information in ELF '/usr/X11R6/lib/libXv.so.1' (0x404ea000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40752000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40c74000) No debug information in ELF '/usr/lib/gconv/ISO8859-1.so' (0x4038d000) Loaded debug information from ELF '/spare/bon/wine/dlls/libversion.so' (0x404d3000) Loaded debug information from ELF '/spare/bon/wine/dlls/liblz32.so' (0x40695000) No debug information in 32bit DLL 'NTDLL.DLL' (0x40060000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSVCRT.DLL' (0x78000000) No debug information in 32bit DLL 'ADVAPI32.DLL' (0x40731000) No debug information in 32bit DLL 'GDI32.DLL' (0x406d0000) No debug information in 32bit DLL 'USER32.DLL' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42.DLL' (0x5f400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x7ff20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLEAUT32.DLL' (0x7fe80000) No debug information in 32bit DLL 'SHLWAPI.DLL' (0x408fd000) No debug information in 32bit DLL 'COMCTL32.DLL' (0x4092f000) No debug information in 32bit DLL 'SHELL32.DLL' (0x4089c000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL' (0x50000000) No debug information in 32bit DLL 'X11DRV.DLL' (0x40c11000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42LOC.DLL' (0x7baf0000) No debug information in 32bit DLL 'LZ32.DLL' (0x40698000) No debug information in 32bit DLL 'VERSION.DLL' (0x404d6000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x7fb90000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVEDIT.PKG' (0x50800000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG' (0x50300000) 08066950:RET msvcrt.73: _XcptFilter() retval = 00000000 ret=0040175d 08066950:RET msvcrt.203: _except_handler3() retval = 00000001 ret=4006ac97 Unhandled exception: page fault on read access to 0x0000000f in 32-bit code (0x5f401ead). In 32-bit mode. 0x5f401ead (MFC42.DLL.1145+0x10 in C:\WINDOWS\SYSTEM\MFC42.DLL): cmpl $0,0x10(%ebx) Wine-dbg>bt Backtrace: =>0 0x5f401ead (MFC42.DLL.1145+0x10 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605684) 1 0x5f401c94 (MFC42.DLL.5163+0x173 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=4060570c) 2 0x4101007d (_end+0x3c3255) (ebp=4060572c) 3 0x41010064 (_end+0x3c323c) (ebp=40605748) 4 0x50301f1f (DEVPRJ.PKG..text+0xf1f in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605764) 5 0x5f401a88 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406057c4) 6 0x5f401a10 (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406057e0) 7 0x5f4019cf (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=4060580c) 8 0x40803b87 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40605830) 9 0x40803c06 (WINPROC_CallWndProc+0x76(proc=0x5f401996, hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [winproc.c:171] in libuser32.so) (ebp=4060585c) 10 0x408097f8 (CallWindowProcA+0x88(func=0x40d70dbc, hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [winproc.c:2589] in libuser32.so) (ebp=40605884) 11 0x407ea1a3 (MSG_SendMessage+0x3b3(hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4, timeout=0xffffffff, type=0x2, pRes=0x406058ec) [message.c:1733] in libuser32.so) (ebp=406058bc) 12 0x407ea2a2 (SendMessageA+0x32(hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [message.c:1772] in libuser32.so) (ebp=406058f0) 13 0x40c15014 (X11DRV_CreateWindow+0x184(hwnd=0x700, cs=0x40605ad4, unicode=0x0) [window.c:871] in libx11drv.so) (ebp=40605938) 14 0x407fce51 (WIN_CreateWindowEx+0x6d1(cs=0x40605ad4, classAtom=0xc066, type=0x2) [win.c:865] in libuser32.so) (ebp=406059b0) 15 0x407fd2fb (CreateWindowExA+0x14b(exStyle=0x0, className=0x403fcebc, windowName=0x0, style=0x42000001, x=0x0, y=0x0, width=0x0, height=0x0, parent=0x2b4, menu=0x7310, instance=0x400000, data=0x40605be0) [win.c:1030] in libuser32.so) (ebp=40605b04) 16 0x5f40c211 (MFC42.DLL.2152+0x9a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605b74) 17 0x5f40aaa5 (MFC42.DLL.2124+0x46 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605bb0) 18 0x4101004b (_end+0x3c3223) (ebp=40605c04) 19 0x50311b41 (DEVPRJ.PKG.InitPackage+0x4b5 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c2c) 20 0x50310336 (DEVPRJ.PKG.EntryPoint+0xb5e in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c58) 21 0x50311a22 (DEVPRJ.PKG.InitPackage+0x396 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c84) 22 0x50311760 (DEVPRJ.PKG.InitPackage+0xd4 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=406060c0) 23 0x50036fa3 (DEVSHL.DLL.3467+0x9a in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=40606664) 24 0x500344be (DEVSHL.DLL.3219+0x53d in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=40606e0c) 25 0x41010019 (_end+0x3c31f1) (ebp=40606ecc) 26 0x400dbf23 (start_process+0x1a3 [process.c:391] in libntdll.so) (ebp=40606f30) 27 0x400dfaa1 (SYSDEPS_DoCallOnStack+0x21(func=0x400dbd80, arg=0x0) [sysdeps.c:173] in libntdll.so) (ebp=40606ff0) 28 0x400dfb43 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff5f0) 29 0x400dfbfa (SYSDEPS_SwitchToThreadStack+0x9a(func=0x400dbd80) [sysdeps.c:236] in libntdll.so) (ebp=bffff62c) 30 0x400dc2be (PROCESS_InitWine+0x1ce(argc=0x4, argv=0xbffff6c4, win16_exe_name=0x804c660, win16_exe_file=0x804c764) [process.c:519] in libntdll.so) (ebp=bffff644) 31 0x0804b20a (Letext [main.c] in wine) (ebp=bffff65c) 32 0x4028fbaf (__libc_start_main+0xcf in libc.so.6) (ebp=bffff698) 33 0x08049021 (_start+0x21 in wine) (ebp=00000000) Wine-dbg>quit WineDbg terminated on pid 80683b0

July 11, 2001

Re: PATCH: include mess up

by Marcus Meissner

On Tue, Jul 10, 2001 at 04:01:55PM -0700, Francois Gouget wrote: > On Tue, 10 Jul 2001, Marcus Meissner wrote: > > > Hi, > > > > There is some bad recursion when including objbase.h in non-WINE programs. > > This fixes that problem, by using winbase.h instead of windows.h. > > Yes but rpc.h is supposed to include 'windows.h', not 'winbase.h'. > The correct fix must be elsewhere. > What is the recursion that happens and which include statement (in > your application) triggers it? I am just trying to compile shdocvw out of the tree and get following error. (You should basically be able to reproduce it by compiling shdocvw with out __WINE__ defined.) /bin/sh ../../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I/opt/kde2/include -I/usr/lib/qt2/include -I/usr/X11R6/include -I/usr/X11R6/include/X11/mesa -I./../tools -I/home/marcus/wine/include -c persist.c gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I/opt/kde2/include -I/usr/lib/qt2/include -I/usr/X11R6/include -I/usr/X11R6/include/X11/mesa -I./../tools -I/home/marcus/wine/include -Wp,-MD,.deps/persist.pp -c persist.c -fPIC -DPIC -o .libs/persist.o In file included from /home/marcus/wine/include/objidl.h:10, from /home/marcus/wine/include/oaidl.h:5, from /home/marcus/wine/include/oleauto.h:10, from /home/marcus/wine/include/ole2.h:22, from /home/marcus/wine/include/windows.h:51, from /home/marcus/wine/include/rpc.h:9, from /home/marcus/wine/include/unknwn.h:4, from /home/marcus/wine/include/objbase.h:7, from shdocvw.h:16, from persist.c:8: /home/marcus/wine/include/wine/obj_clientserver.h:198: parse error before `RPC_AUTH_IDENTITY_HANDLE' /home/marcus/wine/include/wine/obj_clientserver.h:201: parse error before `RPC_AUTH_IDENTITY_HANDLE' /home/marcus/wine/include/wine/obj_clientserver.h:215: parse error before `RPC_AUTHZ_HANDLE' persist.c:10: warning: parameter names (without types) in function declaration persist.c:10: warning: data definition has no type or storage class make: *** [persist.lo] Error 1 RPC_AUTH_IDENTITY_HANDLE is getting defined in the includes later, but gets used due to the windows.h include including lots of other stuff. Ciao, Marcus

July 11, 2001

Re: PATCH: include mess up

by Francois Gouget

On Tue, 10 Jul 2001, Marcus Meissner wrote: > Hi, > > There is some bad recursion when including objbase.h in non-WINE programs. > This fixes that problem, by using winbase.h instead of windows.h. Yes but rpc.h is supposed to include 'windows.h', not 'winbase.h'. The correct fix must be elsewhere. What is the recursion that happens and which include statement (in your application) triggers it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

July 10, 2001

Re: implement overlapped completion routines

by Alexandre Julliard

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This patch implements overlapped completion routines, and fixes up a > small problem with the overlapped implementation. According to ms > docs, the transfer count should not be stored in the overlapped > structure. Shouldn't you queue an APC instead of calling the completion routine directly? -- Alexandre Julliard julliard(a)winehq.com

July 10, 2001

Re: Joysiick under Wine

by Ove Kaaven

On Mon, 9 Jul 2001, David Hagood wrote: > I'm trying to get HalfLife running under Wine. I have the GL working, I > have sound working, but I am one of those strange fellows that likes to > move with a stick, and look with a mouse. Well, could you check whether Half-Life uses DirectInput or the standard winmm joystick API to access the joystick? (--debugmsg +dinput etc) Since these interfaces have not yet been unified in Wine, the winmm API supports much less than the dinput API. For winmm, currently only the Linux 2.0 and 2.2 joystick interfaces are supported (and which of those to use is determined by configure), not the Linux 2.4 event-based interface.

July 10, 2001

Re: some rasapi32 stubs

by Marcus Meissner

On Tue, Jul 10, 2001 at 10:10:17PM +1000, Mike McCormack wrote: > > ChangeLog: > * dlls/rasapi32/rasapi.c, dlls/rasapi32/rasapi32.spec > Stub some rasapi functions. If you know arguments are strings you can use 'str' instead of 'ptr' in the .spec file, and relay debugging will print strings ;) Also you can use the return value of debugstr_a(a) for string output. Ciao, Marcus

July 10, 2001

Joysiick under Wine

by David Hagood

I've seen a couple of messages about getting USB joysticks working under Wine, but do regular (i.e. gameport) sticks work? I've confirmed that my stick is being read by Linux, and that it is reporting events correctly. Now, how do I get Wine to pass them along? I've confirmed: 1) that I have read/write permissions to /dev/js0 2) that Wine tries to read /dev/js0 3) that Wine indeed does read from /dev/js0, but that 4) Wine shortly thereafter closes /dev/js0, never to read it again. Do I need to have the X Window system joystick driver loaded? Or do I need to add something to the system.ini or .wine/config files. This is a Windowless install, under RH6.1, with 2.4.6, and a CVS pull of Wine from a few days ago. I'm trying to get HalfLife running under Wine. I have the GL working, I have sound working, but I am one of those strange fellows that likes to move with a stick, and look with a mouse. Are there any Windows/Wine tools that I can run to try to troubleshoot this?

July 10, 2001

Re: PATCH: internetgetconnectionstate

by Gerard Patel

At 11:37 PM 09/07/2001 +0200, you (Marcus Meissner) wrote: >Hi, > >QuickTimePlayer 5 is using InternetGetConnectedState to check whether to >download its 'homepage'. > >Just say we are connected, and on a LAN. > >Ciao, Marcus > >Changelog: > Have InternetGetConnectedState always return 'LAN connection'. Theoretically this could cause trouble when used with a computer having no connection to the Internet, as an app could think it can connect, try to do it, fail and terminate or display annoying messages. It's not really a strong objection, as most decent computers are connected to the Internet these days, but maybe a config option could be better ? Just a thought. Gerard

July 10, 2001

Re: wv{sn,ns}printf[AW]

by Alexandre Julliard

Peter Hunnisett <hunnise(a)yahoo.com> writes: > 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause > user32 to have to import shlwapi (because wsprintfA and friends use it > in their implementation) and I don't know if that's legal because user32 > seems to only import gdi32 and kernel32. If not, what's the solution? > Reimplement everything in user32 to not use wvnsprintf and move the > implementation over or just keep the existing situation and rename > wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? user32 cannot import shlwapi, since this would create a circular dependency. Since the functions are needed both in user32 and shlwapi, they have to be implemented in user32 and forwarded from shlwapi to user32 (the alternative is to have two complete wsprintf implementations, which is a bit of a pain). I guess you could also rename the user32 ones, but this is not strictly necessary (and the current name has the advantage of following the C library naming of vsnprintf). -- Alexandre Julliard julliard(a)winehq.com

July 9, 2001

wv{sn,ns}printf[AW]

by Peter Hunnisett

Hi, it appears that we have a bit of a hack in the wine code. Presently we export wvsnprintf[AW] from user32. - These two functions do not appear to be in the real user32.dll and the comments in the code seem to back it up. - Windows does have wvnsprintf[AW] (note the transposed "sn") exported from shlwapi.dll So my questions are: 1) Was the user32 a bit of a hack because those routines just weren't noticed or was it because of something from before shlwapi? 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause user32 to have to import shlwapi (because wsprintfA and friends use it in their implementation) and I don't know if that's legal because user32 seems to only import gdi32 and kernel32. If not, what's the solution? Reimplement everything in user32 to not use wvnsprintf and move the implementation over or just keep the existing situation and rename wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? Thanks, Peter hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

July 9, 2001

Re: Are these the ordinal names?

by Alexandre Julliard

Peter Hunnisett <hunnise(a)yahoo.com> writes: > Howdy, > I have a couple of questions about the following error messages > > err:win32:fixup_imports No implementation for > SHLWAPI.dll.281(wvnsprintfA) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.282(wvnsprintfW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.240(StrRetToStrW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > > 1) Do these messages mean that 281 is named wvnsprintfA and so on? If > so, why does the SHLWAPI.240 name not seem to jive with the existing > implementation? If a name is specified, the ordinal is only a hint, so it's OK for it to be different. What this means is that in some version of shlwapi StrRetToStrW is at ordinal 240, but it can be at other ordinals in other versions since it is looked up by name. In our builtin version, ordinal 240 is something else (which is fine), and StrRetToStrW is not implemented at all (which is the cause of your problem). You can either implement it, or use the native shlwapi. -- Alexandre Julliard julliard(a)winehq.com

July 8, 2001

Re: sharing windows between processes

by Alexandre Julliard

"Bill Medland" <medbi01(a)accpac.com> writes: > Some time ago I raised the issue of the fact that windows handles cannot be > shared between processes on the same server and was told that it was a > known significant issue. > > Is anyone doing anything about it? Sure, that's the main reason behind all the recent window management and messaging changes. So yes, it is being worked on. -- Alexandre Julliard julliard(a)winehq.com

July 8, 2001

Re: Mouse events

by Alexandre Julliard

Duane Clark <dclark(a)akamail.com> writes: > I assume some problem led to its removal. I regularly try out Myst (the > 32 bit version) as a test, running locally on a 700MHz Athlon, so this > can't be blamed on a slow ethernet connection or slow machine. When > dragging the slide controls in the "planetarium", they used to follow > the mouse just fine. With this patch, if you grab the control, move the > mouse and release it, the control does not keep up with the mouse but > just moves at a moderately slow pace until it reaches the point where > the mouse was released (a few seconds to travel from one end to the > other). At that point everything returns to normal. The new hardware event handling does not yet attempt to merge mouse motion events, so this is probably the reason for the problem. This should be fixed soon. -- Alexandre Julliard julliard(a)winehq.com

July 8, 2001

Re: printing docu

by Duane Clark

Andreas Mohr wrote: > Hi all, > > while trying to configure Wine for printing in order to be able to use > Windows Acrobat Reader instead of Linux acroread which is crashing on certain > PDF files, I remembered that the printing docu is everything but perfect. > > Updated printing docu a bit. > > ... > - <sect3> > <title>Spooling</title> > <para> > Spooling is rather primitive. The [spooler] section of > @@ -82,13 +82,14 @@ > example the following lines > </para> > <screen> > -"LPT1:" = "foo.ps" "LPT2:" = "|lpr" > +"LPT1:" = "foo.ps" > +"LPT2:" = "|lpr" > </screen> > <para> > map <systemitem>LPT1:</systemitem> to file <filename>foo.ps</filename> > and <systemitem>LPT2:</systemitem> to the <command>lpr</command> > - command. If a job is sent to an unlisted port then a file is created > - with that port's name e.g. for <systemitem>LPT3:</systemitem> a file > + command. If a job is sent to an unlisted port, then a file is created > + with that port's name; e.g. for <systemitem>LPT3:</systemitem> a file > called <systemitem>LPT3:</systemitem> would be created. > </para> > <para> While it used to work that way, for me at least, the part about - a job that is sent to an unlisted port will create a file with the port's name - stopped working a few months ago. And I just tested it a few minutes ago and it still does not work (for me). I don't know where the data goes, but it does not appear to be written to a file anywhere. Actually, I think that is probably a good thing. In most cases, the print dialog should have a "Print to file" button. And if there is no way to specify a file name, then the ~/.wine/config entry "FILE:" = "foo.ps" will control where it is written, and in this case it will in fact be correctly written to the indicated file name. Duane

July 8, 2001

Half-Life/CS under WINE

by David Bronaugh

Just as a follow-up to my previous email.. if you want a quick response from me, email me off the list - I'm getting the digest, as I don't want to massively clutter up my inbox. David Bronaugh

July 8, 2001

Problems running WINE with Half-Life with CounterStrike

by David Bronaugh

Hey all, I'm having some interesting issues with Half-Life running under WINE... I'm guessing these are due to it running under WINE (they are strange enough). #1 problem: I can't type normally in the Half-Life console (the keyboard is mapped to a completely nonsensical map). I believe this is because they implemented their own custom key handler. Is there any workaround in software/with config for this? Note that this is only in the game when the game engine is initialized, otherwise the keyboard works great (Kudos to the WINE people that my dvorak-mapped QWERTY keyboard works as it should in dvorak). #2 problem: I can't get to the Half-Life console without going through some convolutions... This in itself is useless to tell you people. How I do get into the game is by the following method: I join a game or whatever, and the "Loading" screen pops up. At this point.. it will sit there for hours (I'm guessing this is a locking issue with pthreads?). What I do that appears to relieve the deadlock is to click the "Done" button that is invisible (but I know where it is, so I click it). Then the game loads normally, and runs decently enough (performance isn't great, but playable... huge kudos to the Wine crew for that). Note that the only button that does this is the "Done" button, the rest do nothing out of the ordinary. Again, this may be due to some peculiarity with Half-Life or with my config.. I'm betting on a peculiarity with Half-Life interacting with some unimplemented feauture or bug in WINE. If anyone has suggestions re these two, send em to me.. I'm more than happy to spend a few hours to help resolve this. David Bronaugh

July 8, 2001

Are these the ordinal names?

by Peter Hunnisett

Howdy, I have a couple of questions about the following error messages err:win32:fixup_imports No implementation for SHLWAPI.dll.281(wvnsprintfA) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.282(wvnsprintfW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.240(StrRetToStrW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef 1) Do these messages mean that 281 is named wvnsprintfA and so on? If so, why does the SHLWAPI.240 name not seem to jive with the existing implementation? 2) Why would I be getting the error for SHLWAPI.dll.240(StrRetToStrW) given the fact that the shlwapi.spec file contains the following line and there does seem to be an implementation in ordinal.c? 240 stdcall @(long long long long) SHLWAPI_240 Ciao, Peter Hunnisett hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

July 8, 2001

Re: Win16 problems

by Gerard Patel

At 10:43 PM 03/07/2001 +0200, you wrote: <snip> >winmine fails to draw, whereas freecell runs just fine Yes, I see the problem with winmine; but is it really a 16-bits problem ? What I see is an app creating its main window iconic (minimized), then showing it using ShowWindow. Current Wine code does not take this particular behaviour (completely absurd, granted) in account - When the window is created the 'client' window is not mapped (since it's iconic, nothing surprising here), but in ShowWindow the iconic flag (WS_MINIMIZED) is cleared, and when SetWindowPos is called by ShowWindow, X11DRV_sync_client_window_position cleverly detects that the window is already mapped ;-) and decides that it's not necessary to do anything more. This seems more a Winmine specific problem than otherwise. BTW, I can't see any problem with sol.exe (win3.11 version) This patch : --- window.c.orig Wed Jun 27 03:03:36 2001 +++ window.c Sat Jul 7 23:19:03 2001 @@ -596,7 +596,7 @@ if (was_mapped && !is_client_window_mapped( win )) XUnmapWindow( display, data->client_window ); XConfigureWindow( display, data->client_window, mask, &changes ); - if (!was_mapped && is_client_window_mapped( win )) + if (is_client_window_mapped( win )) XMapWindow( display, data->client_window ); wine_tsx11_unlock(); } works around this particular problem. Gerard

July 7, 2001

Windows .lnk file parsing

by J. Henning Schwentner

Hi Wine developers, I am planning to write a little tool "lnk2desktop" which converts Windows LNK links into KDE/Gnome .desktop links, which you could use then to integrate your Windows start menu into your K menu. When I searched through the wine news archive I found a message about library that parses .lnk files and returns the command to execute, the icon etc. My question is now, does such a library exist and what other ways do exist for finding out such infomations? Regards, Henning Schwentner Lanthan Software KG P.S.: Please CC me, since I am not subscribed to the list.

July 7, 2001

sharing windows between processes

by Bill Medland

Some time ago I raised the issue of the fact that windows handles cannot be shared between processes on the same server and was told that it was a known significant issue. Is anyone doing anything about it? It seems to me that what has to be done is to have wineserver coordinate the allocation of handles. Any comments? Bill

July 6, 2001

Re: Confusing SHGetFolderPath

by Juergen Schmied

The MSDN tells you: ----------- Remarks This function is a superset of {HYPERLINK "SHGetSpecialFolderPath.htm"}SHGetSpecialFolderPath, included with earlier versions of the Shell. It is implemented in a redistributable DLL, SHFolder.dll, that also simulates many of the new Shell folders on older platforms such as Windows 95, Windows 98, and Windows NT 4.0. This DLL always calls the current platform's version of this function. If that fails, it will try to simulate the appropriate behavior. -------- So the shfolder.dll is only for updating older operating systems. WinME/W2K has this function in shell32. The shfolder one has a smaller set of supported CSIDL's. I suspect (by looking on the imports with depends) the shfolder.dll just loads shell32 with LoadLibrary and forwards the functions if a GetProcAddress() is successful. Ciao Juergen From: nog <nog(a)sdf.lonestar.org> Subject: Confusing SHGetFolderPath To: "wine-devel(a)winehq.com" <wine-devel(a)winehq.com> Send reply to: "wine-devel(a)winehq.com" <wine-devel(a)winehq.com> Date sent: Mon, 01 Jul 2002 22:12:13 +0200 > Hi, > > While I was looking through some of the wine dlls' code I found that the > function SHGetFolderPath is in the shell32 dll and the shfolder dll. Is > this ment to be like this? Because the docs that I read says that the > function is meant to be in shfolder. Anyway are the two functions meant > to do the same thing? If so then why is the one in shell32 implemented > and working and the one on shfolder doesn't eaven appear to give a fixme > message? > > Nog > > > >

July 6, 2001

Re: Help with nonclient Windows 95 frame

by Bill Medland

Bill Medland <medbi01(a)accpac.com> wrote in article <01c1058a$50e51260$6f0c10ac(a)medbi01>... > I'd appreciate some advice here before I mess things up for everyone else. > > In the longer term I am fixing a border issue with the edit control, but > before doing so I am fixing up the nonclient frame drawing code (i.e. > NC_DoNCPaint95). > > The code contains quite a bit of calculation based upon the system metrics. > The code seems to reflect the Windows documentation. However it should > come as no surprise that there are disagreements between that documentation > and what I see on my Win95 computer! For example a frame with WS_THICKEDGE > but no WS_BORDER nor WS_DLGFRAME nor WS_EX_DLGMODALFRAME on my computer is > only 3 pixels wide, not 4 (although one of those pixels is the COLOR_WINDOW > associated with the WS_THICKEDGE) > > Is there a way to adjust the size of the borders on the Win95 to be able to > see what affects what? > > Bill > > > > > yes. Control Panel->Display->Appearance->Item and mess about (e.g. adjusting ActiveWindowBorder adjusts the BorderWidth setting in the WindowMetrics section of the Registry)

July 6, 2001

Help with nonclient Windows 95 frame

by Bill Medland

I'd appreciate some advice here before I mess things up for everyone else. In the longer term I am fixing a border issue with the edit control, but before doing so I am fixing up the nonclient frame drawing code (i.e. NC_DoNCPaint95). The code contains quite a bit of calculation based upon the system metrics. The code seems to reflect the Windows documentation. However it should come as no surprise that there are disagreements between that documentation and what I see on my Win95 computer! For example a frame with WS_THICKEDGE but no WS_BORDER nor WS_DLGFRAME nor WS_EX_DLGMODALFRAME on my computer is only 3 pixels wide, not 4 (although one of those pixels is the COLOR_WINDOW associated with the WS_THICKEDGE) Is there a way to adjust the size of the borders on the Win95 to be able to see what affects what? Bill

July 5, 2001

Mouse events

by Duane Clark

Howdy, Just tried the most recent CVS. I found that the patch from 6/25 to windows/x11drv/event.c has led to mildly annoying mouse behavior in certain (admittedly very limited) cases. Here is the change that did it: @@ -292,21 +291,8 @@ case ButtonRelease: EVENT_ButtonRelease( hWnd, (XButtonEvent*)event ); break; case MotionNotify: - /* Wine between two fast machines across the overloaded campus - ethernet gets very boged down in MotionEvents. The following - simply finds the last motion event in the queue and drops - the rest. On a good link events are servered before they build - up so this doesn't take place. On a slow link this may cause - problems if the event order is important. I'm not yet seen - of any problems. Jon 7/6/96. - */ - if ((current_input_type == X11DRV_INPUT_ABSOLUTE) && - (in_transition == FALSE)) - /* Only cumulate events if in absolute mode */ - while (TSXCheckTypedWindowEvent(display,((XAnyEvent *)event)->;window, - MotionNotify, event)); EVENT_MotionNotify( hWnd, (XMotionEvent*)event ); break; I assume some problem led to its removal. I regularly try out Myst (the 32 bit version) as a test, running locally on a 700MHz Athlon, so this can't be blamed on a slow ethernet connection or slow machine. When dragging the slide controls in the "planetarium", they used to follow the mouse just fine. With this patch, if you grab the control, move the mouse and release it, the control does not keep up with the mouse but just moves at a moderately slow pace until it reaches the point where the mouse was released (a few seconds to travel from one end to the other). At that point everything returns to normal. Other similar slide controls, such as the musical slide controls in the space ship, work fine with the patch, however. Perhaps it is possible that the code above was masking some other problem causing the control to move too slowly to follow the mouse? Duane

July 3, 2001

Re: Win16 problems

by Ove Kaaven

On Tue, 3 Jul 2001, eric pouech wrote: > > I could probably look into the OpenGL problem if that was the only > > problem, but why are Win16 windows never drawn anyway? > > (Unfortunately, I don't have sol.exe here, I tested with MS Word > > Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my > > tree) > well; same issue here (without opengl support) > however, it's not consistent across all apps > winmine fails to draw, whereas freecell runs just fine I thought FreeCell was a Win32 app (it was part of the Win32s package for Win3.x).

July 3, 2001

The [Windows] section

by Bill Medland

Is the [Windows] section of the config still supposed to be in use or should Tweak.Layout be used instead? (I am looking at the [Windows].BorderWidth in particular) Bill

July 3, 2001

Re: Win16 problems

by eric pouech

> I could probably look into the OpenGL problem if that was the only > problem, but why are Win16 windows never drawn anyway? > (Unfortunately, I don't have sol.exe here, I tested with MS Word > Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my > tree) well; same issue here (without opengl support) however, it's not consistent across all apps winmine fails to draw, whereas freecell runs just fine A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

July 3, 2001

Re: Mixed mode CD's and volume label

by Andreas Mohr

On Tue, Jul 03, 2001 at 09:47:03AM -0500, David Hagood wrote: > I was trying to get Half-Life running under Wine last night, and ran > into a problem with getting the CD label under Wine. Since the HL CD is > a mixed mode data/audio disk (as are most game disks nowadays) Wine > complained with a > > We don't have a way of determining the label of a mixed mode CD - Linux > doesn't allow raw access ! Well, actually this message is dead wrong. Linux doesn't allow "normal" block device access, but there are certainly ioctls for special CD-ROM sector formats available. A lot of experimentation of mine didn't enable me to find out how the serial of a mixed-mode CD gets calculated, though. Reading the label of a mixed-mode CD is an entirely different matter, of course. Either you intend to hack on it a bit, or it'll definitely be on my ToDo list for the next weeks to come. > As an experiment, I disabled this check in misc/cdrom.c, and it worked > quite happily. Hmm, then this program didn't really have demanding requirements ;) > Now, if I could just work out why the OpenGL is flashing... Check out lhl.linuxgames.com AFAIK that might be the frequently mentioned DRI bug. -- Andreas Mohr

July 3, 2001

Mixed mode CD's and volume label

by David Hagood

I was trying to get Half-Life running under Wine last night, and ran into a problem with getting the CD label under Wine. Since the HL CD is a mixed mode data/audio disk (as are most game disks nowadays) Wine complained with a We don't have a way of determining the label of a mixed mode CD - Linux doesn't allow raw access ! However, Xcdroast was easily able to access the data. As an experiment, I disabled this check in misc/cdrom.c, and it worked quite happily. Perhaps this check is out of date. Perhaps it is my system setup: 2.4.6-pre7, Samsung CD-Writer/DVD reader on IDE, ide-scsi module loaded, Wine configured to use the /dev/scd0 link. Now, if I could just work out why the OpenGL is flashing...

July 3, 2001

Re: Window painting problem

by Malte Starostik

On Dienstag, 3. Juli 2001 14:35, Glenn Schrader wrote: > The problem appears to be in BeginPaint. There is a > test which checks to see if the window has the > CS_PARENTDC flag set. If so then then the update > region is discarded and the window is painted. > This has the side effect of making the whole > window repaint every time anything in the window > changes. > > According to the windows docs that i've looked at, > the CS_PARENTDC should just make the window paint > using its parent's device context. There isn't any > mention of also removing the invalid region clipping > so i'm pretty sure that what BeginPaint is doing > isn't right. As I posted a while back (http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2001-06/da…) there are other problems with it and there are contradicting pieces of documentation :( -Malte

July 3, 2001

Re: Window painting problem

by r.maurizzi＠gvs.it

Glenn Schrader <gschrad(a)ll.mit.edu> wrote: > The symptom is that (in some cases) any change to a > window will cause the entire window to be repainted. > (...) > This doesn't happen on most applications. > In fact, the only one where i've seen this effect is > RoAClient (a really good MUD client). Even so, its > really annoying and makes the window flash so much > that the app is effectively useless. Just for info, Lotus Notes v 4.6x has the same problem. Ciao, Roberto.

July 3, 2001

Window painting problem

by Glenn Schrader

I've been tracking down a window painting problem and I think that I know whats happening but I'd like to get some opinions on the 'right' way to fix it. The symptom is that (in some cases) any change to a window will cause the entire window to be repainted. For instance, using the mouse to select a single character causes the whole window to update rather than just the small region which needs to be highlighted. This doesn't happen on most applications. In fact, the only one where i've seen this effect is RoAClient (a really good MUD client). Even so, its really annoying and makes the window flash so much that the app is effectively useless. The problem appears to be in BeginPaint. There is a test which checks to see if the window has the CS_PARENTDC flag set. If so then then the update region is discarded and the window is painted. This has the side effect of making the whole window repaint every time anything in the window changes. According to the windows docs that i've looked at, the CS_PARENTDC should just make the window paint using its parent's device context. There isn't any mention of also removing the invalid region clipping so i'm pretty sure that what BeginPaint is doing isn't right. In my hacking around, I disabled the branch of the test which removes the clipping region and things appear to work a lot better. The screen updating is definitely smoother. What I'm not sure of is whether this is good enough or whether the CS_PARENTDC case really should be slightly different. Normally the clipping region is offset relative to the window thats being drawn but with CS_PARENTDC should the offset be done relative to the parent window instead? Are there any other subtle things that CS_PARENTDC affects? Any insight would be appreciated... Thanks much, G. Schrader

July 3, 2001

Re: Win16 problems

by Gerard Patel

At 02:58 AM 03/07/2001 +0200, you wrote: >Is it just me, or does no Win16 GUI apps work in the current Wine CVS? If >Wine is compiled with --enable-opengl, then we get BadMatch errors in >X_CreateWindow (some kind of visual mismatch), If I disable the OpenGL >visual, then the windows are created and seem to exist, but they're never >drawn. > >Win32 apps work fine, of course. For me Win16 apps have not more problems than Win32 ones. Word viewer 16 bits has one regression with current Cvs vs say one month ago, a focus problem that is occuring only in managed mode. Other than that, it is starting and loading files, either on my old computer with Xfree 3.3 and on my newer one with Xfree 4 (compiled with --enable-opengl) I still run most of my test apps on the old computer, but none of them crashes and the new redrawing problems are less than what you say. IMO Wine behaviour depends more now on the specific X server and window manager. I use Kde on both computers, btw (1.1.1 and 2.1 respectively) Gerard

July 3, 2001

Win16 problems

by Ove Kaaven

Is it just me, or does no Win16 GUI apps work in the current Wine CVS? If Wine is compiled with --enable-opengl, then we get BadMatch errors in X_CreateWindow (some kind of visual mismatch), If I disable the OpenGL visual, then the windows are created and seem to exist, but they're never drawn. Win32 apps work fine, of course. I could probably look into the OpenGL problem if that was the only problem, but why are Win16 windows never drawn anyway? (Unfortunately, I don't have sol.exe here, I tested with MS Word Viewer 16-bit, but DOS apps like Monkey Island gets the same issues in my tree)

July 3, 2001

Re: dead lock

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > let's assume fixing it is now on Alexandre's TODO list ;-) Yes, I'll fix it, thanks for the report. You'll have to wait a bit though, as I will be away most of the week. -- Alexandre Julliard julliard(a)winehq.com

July 3, 2001

Re: PATCH: setsockopt differences for winsock/winsock2

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > That was the time that I spotted that the #defines for the IP_* > stuff _differs_ between winsock and winsock2. So I had to split up > the IPPROTO_IP handling. I tried to keep code duplication to a minimum. > > I am not sure whether the forwarders are good style. They are not IMHO. I'd suggest writing a ws1-to-ws2 conversion function instead, and use it (by duplicating its code) both for the 16-bit functions in ws2_32 and for the version 1 functions in wsock32. A little code duplication is better than adding entry points. An even better alternative that would avoid the duplication could be to have the 16-bit functions implemented in wsock32 instead of ws2_32, but this is probably a lot more work. -- Alexandre Julliard julliard(a)winehq.com

July 3, 2001

tray icon creation problem

by Adriaan Moors

hi, earlier, i reported a problem with create_icon_window. It doesn't crash anymore with today's cvs (it says an error occurred when initing the tray icon). The application (winmx) continues to load, but it keeps moving downwards. This only occurs when using enlightenment, with window maker it stays still :-) Maybe it's a bug in enlightenment? regards adriaan moors -- Have you ever noticed that the people who are always trying to tell you, "There's a time for work and a time for play," never find the time for play?

July 3, 2001

Request for feature

by David Ronis

I posted this to comp.emulators.ms-windows.wine, but got no reply. I'd been having problems with a windows application that want's to pass off a URL to a browser (netscape). OK I figured out part of my problem. [In short, I have an windows application that spawn netscape with some command-line url]. As was suggested in this thread, I had to install a windows version of netscape (I only had the linux native version installed). The installation set up the registry and things work (well sort of, netscape complains about not being able to write to the tmp directory e: [which is /tmp]). The problem now is that I seem to be on the slippery slope; i.e., most of the plugins/helper applications are absent, so in order to see various file types I have to download more windows versions of things already on my system. None of this would be necessary if there was some way to get wine to first try a native program; e.g., before trying netscape.exe or whatever was in the registry, try netscape using a standard unix system call; only if this failed would wine look for a windows version. Alternately the order could be reversed (I'd be more than willing to remove the windows versions of netscape). The best solution, would be some sort of override capability be added to the config file, for example, similar to the way native vs windows .dll's are chosen. I'm willing to play around with this, but have no experience with the internals of wine. Can somebody point me to the right point of the source code? It'd probably be trivial (and less likely to mess up wine) to first try to fork off a linux command (e.g., by mapping the end of command to something lowercase and less the .exe or .com suffix) and if that failed resort to the windows command. David P.S., I don't subscribe to this list, so please CC me.

July 2, 2001

dead lock

by eric pouech

an app of mine, using two threads, dead locks as follows: thread 1 0 0x40057b1b (RtlpWaitForCriticalSection+0x147(crit=0x40652d48, crit=0x40652d48) [critsection.c:185] in libntdll.so) (ebp=40a96a74) 1 0x40057bf6 (RtlEnterCriticalSection+0x3e(crit=0x40652d48) [critsection.c:241] in libntdll.so) (ebp=40a96a88) 2 0x400ca883 (_EnterSysLevel+0xf7(lock=0x40652d48) [syslevel.c:80] in libntdll.so) (ebp=40a96ab4) 3 0x40639a5f (GDI_AllocObject+0x2f(size=0x34, magic=0x4f4b, handle=0x40a96afc, handle=0x40a96afc) [gdiobj.c:427] in libgdi32.so) (ebp=40a96ad8) 4 0x4062c668 (CreateBitmap+0x78(width=0x20, height=0x20, planes=0x1, bpp=0x18, bits=0x4039fe1c) [bitmap.c:124] in libgdi32.so) (ebp=40a96b00) 5 0x40770f66 (GetIconInfo+0xca(hIcon=0x24e, iconinfo=0x40a96b50) [cursoricon.c:1816] in libuser32.so) (ebp=40a96b30) 6 0x40805a4a (set_icon_hints+0xe6(display=0x8082898, wndPtr=0x4037fe00, hints=0x8083da0, display=0x8082898, win=0x4037fe00, display=0x8082898, win=0x4037fe00) [window.c:263] in libx11drv.so) (ebp=40a96b8c) 7 0x40805ccb (set_wm_hints+0xf3(display=0x8082898, win=0x4037fe00) [window.c:370] in libx11drv.so) (ebp=40a96bbc) 8 0x4080691e (create_whole_window+0x1aa(display=0x8082898, win=0x4037fe00, win=0x4037fe00) [window.c:699] in libx11drv.so) (ebp=40a96c50) 9 0x40806ead (X11DRV_CreateWindow+0xb5(hwnd=0x4ac, cs=0x40a96e2c, unicode=0x0) [window.c:856] in libx11drv.so) (ebp=40a96c90) 10 0x40797831 (WIN_CreateWindowEx+0x6c9(cs=0x40a96e2c, classAtom=0xc014, type=0x2) [win.c:865] in libuser32.so) (ebp=40a96d08) 11 0x40797cca (CreateWindowExA+0x15a(exStyle=0x0, className=0x404c86ce, windowName=0x4049ef3c, style=0xcf0000, x=0x366, y=0x14, width=0x19a, height=0x16f, parent=0x0, menu=0x0, instance=0x4049d000, data=0x0) [win.c:1030] in libuser32.so) (ebp=40a96e5c) 12 0x4049be85 (SInitInstance+0x169(hInstance=0x4049d000, nCmdShow=0x1) [sinit.c:247] in a.so) (ebp=40a96ecc) 13 0x4049911b (ServerThread+0x4b(p=0x405e6e14) [a.c:19] in a.so) (ebp=40a96f1c) 14 0x400cb1ac (THREAD_Start+0x98 [thread.c:273] in libntdll.so) (ebp=40a96f38) 15 0x400ca44e (SYSDEPS_StartThread+0x36(teb=0x40aa7000) [sysdeps.c:73] in libntdll.so) (ebp=40a96ff4) 16 0x4030531a (NTDLL.DLL.memcpy+0x494aa in libc.so.6) (ebp=00000000) thread 2 0 0x40057b1b (RtlpWaitForCriticalSection+0x147(crit=0x40841d10, crit=0x40841d10) [critsection.c:185] in libntdll.so) (ebp=405e6ac0) 1 0x40057bf6 (RtlEnterCriticalSection+0x3e(crit=0x40841d10) [critsection.c:241] in libntdll.so) (ebp=405e6ad4) 2 0x4080b668 (lock_tsx11+0x1c [x11drv_main.c:109] in libx11drv.so) (ebp=405e6ae4) 3 0x4080f595 (X11DRV_StretchBlt+0x39(dcDst=0x4039f710, xDst=0x0, yDst=0x0, widthDst=0xa0, heightDst=0x80, dcSrc=0x4039f4e8, xSrc=0x0, ySrc=0x0, widthSrc=0x190, heightSrc=0x140, rop=0xcc0020) [bitblt.c:1555] in libx11drv.so) (ebp=405e6b10) 4 0x4061bbf2 (StretchBlt+0x102(hdcDst=0xf4, xDst=0x0, yDst=0x0, widthDst=0xa0, heightDst=0x80, hdcSrc=0xf0, xSrc=0x0, ySrc=0x0, widthSrc=0x190, heightSrc=0x140, rop=0xcc0020) [bitblt.c:120] in libgdi32.so) (ebp=405e6b54) 5 0x40499b84 (CInitializeCoolBitmaps+0x36c [cinit.c:229] in a.so) (ebp=405e6bd4) 6 0x4049a265 (CMainWndProc+0x205(hWnd=0x13c, msg=0x590, wParam=0x0, lParam=0x0) [client.c:131] in a.so) (ebp=405e6d24) 7 0x4079e197 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405e6d48) 8 0x4079e216 (WINPROC_CallWndProc+0x76(proc=0x4049a060, hwnd=0x13c, msg=0x590, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=405e6d74) 9 0x407a3da8 (CallWindowProcA+0x88(func=0x4096054c, hwnd=0x13c, msg=0x590, wParam=0x0, lParam=0x0) [winproc.c:2589] in libuser32.so) (ebp=405e6d9c) 10 0x40785fcc (DispatchMessageA+0xd8(msg=0x405e6e24) [message.c:2359] in libuser32.so) (ebp=405e6de0) 11 0x404991ff (WinMain+0x9b(hInstance=0x4049d000, hPrevInstance=0x0, lpCmdLine=0x40360747, nCmdShow=0x1) [a.c:78] in a.so) (ebp=405e6e40) 12 0x4049e082 (__wine_exe_main+0x82 [a.spec.c:5838] in <Debugged process>) (ebp=405e6ecc) 13 0x400c6d52 (start_process+0x1a6 [process.c:391] in libntdll.so) (ebp=405e6f30) 14 0x400ca559 (SYSDEPS_DoCallOnStack+0x25(func=0x400c6bac, arg=0x0) [sysdeps.c:173] in libntdll.so) (ebp=405e6ff0) 15 0x400ca603 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff660) 16 0x400ca6ad (SYSDEPS_SwitchToThreadStack+0x95(func=0x400c6bac) [sysdeps.c:236] in libntdll.so) (ebp=bffff69c) 17 0x400c70de (PROCESS_InitWine+0x1ce(argc=0x1, argv=0xbffff734, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:519] in libntdll.so) (ebp=bffff6b4) 18 0x0804b1ee (Letext [main.c] in wine) (ebp=bffff6cc) 19 0x4027bcbe (NTDLL.DLL.sqrt+0x3262e in libc.so.6) (ebp=bffff708) 20 0x08049021 (_start+0x21 in wine) (ebp=00000000) it (simply) deadlocks because the new window management code (written by Alexandre), (rev 1.5 of dlls/x11drv/window.c, change log entry Create an X window for every window, including children. Fixed non-client rectangle calculations in managed mode. Added support for icon window in managed mode. ) does call GDI functions (here GetIconInfo) while the x11drv critical section is held, which shouldn't be the case let's assume fixing it is now on Alexandre's TODO list ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

July 2, 2001

Re: Confusing SHGetFolderPath

by Francois Gouget

On Mon, 1 Jul 2002, nog wrote: > Hi, > > While I was looking through some of the wine dlls' code I found that the > function SHGetFolderPath is in the shell32 dll and the shfolder dll. Is > this ment to be like this? Because the docs that I read says that the > function is meant to be in shfolder. Anyway are the two functions meant > to do the same thing? If so then why is the one in shell32 implemented > and working and the one on shfolder doesn't eaven appear to give a fixme > message? Just another datapoint: according to my files SHGetFolderPath does not exist in Win95, is implemented in shfolder on Win98, and has entry points in both shfolder and shell32 in Win2000 and WinMe. That's probaby why we have the situation described by Uwe Bones in Wine. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

July 2, 2001

Re: convert 16bit comm stuff to use handles

by lawson_whitney＠juno.com

On Sun, 1 Jul 2001, Ove Kaaven wrote: > > Not good... you *must* duplicate the handle (probably with > DuplicateHandle) before passing it to SERVICE_AddObject. The > SERVICE_Delete will close the handle passed to AddObject, which is bound > to cause problems if it's not a duplicate. > Okay, third try at this patch works fine AFAICT, exercising the following functions: trace:comm:COMM_Init trace:comm:CloseComm16 trace:comm:EscapeCommFunction16 trace:comm:FlushComm16 trace:comm:GetCommError16 trace:comm:GetCommState16 trace:comm:OpenComm16 trace:comm:ReadComm16 trace:comm:SetCommEventMask16 trace:comm:SetCommState16 trace:comm:WriteComm16 trace:comm:comm_notification If we want to exercise the other 16 bit comm functions, we need another app. Or we can go ahead with this, and handle the others on a com[laint basis. I guess Mike will be sending it to wine-patches presently, or I can, after breakfast and physical therapy. Lawson ---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.

July 2, 2001

Re: Confusing SHGetFolderPath

by Uwe Bonnes

>>>>> "nog" == nog <nog(a)sdf.lonestar.org> writes: nog> Hi, While I was looking through some of the wine dlls' code I found nog> that the function SHGetFolderPath is in the shell32 dll and the nog> shfolder dll. Is this ment to be like this? Because the docs that I nog> read says that the function is meant to be in shfolder. Anyway are nog> the two functions meant to do the same thing? If so then why is the nog> one in shell32 implemented and working and the one on shfolder nog> doesn't eaven appear to give a fixme message? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/sh… tells that ShGetFolderPath is in shell32.lib. So we implemented it there, and we have a Forward to shell32 in shfolder.dll Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 2, 2001

Re: GDI Memory Leak + err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this.

by Andreas Mohr

On Sun, Jul 01, 2001 at 07:04:53AM -0500, adoniz(a)hushmail.com wrote: > I got these errors while trying to do something a little uncommon: > > I have been running Halflife from my windows partiton just fine. But I > wanted to remove the huge files and replace them with symlinks to a cdrom, > but since I can't do symlinks on fat32 (is there a wine hack for this?? > i think it would be a great idea!!), I figured I copy the basic files of > HL to my linux partition, and symlink the huge pak files. > So, I have /mnt/halflife and under there I have some symlinks. I went > ahead and added these to my ~/.wine/config Hmm, you do know that directory symlinks (*not* file symlinks, though !) are ignored by Wine per default ? Set [wine] "ShowDirSymlinks" = "1" if you *really* (and I mean "really", since it can have bad results) want to use this. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Microsoft Windows: Made for the Internet The Internet: Made for Unix

July 2, 2001

Confusing SHGetFolderPath

by nog

Hi, While I was looking through some of the wine dlls' code I found that the function SHGetFolderPath is in the shell32 dll and the shfolder dll. Is this ment to be like this? Because the docs that I read says that the function is meant to be in shfolder. Anyway are the two functions meant to do the same thing? If so then why is the one in shell32 implemented and working and the one on shfolder doesn't eaven appear to give a fixme message? Nog

July 2, 2001

Re: Re: rebar trouble with WinZip 8.0

by Mike McCormack

Hi Guy, Yep, that does it. Thanks, Mike Original message from: "Guy L. Albertelli" <galberte(a)neo.lrun.com> > >Hi Mike, > >See if the attached patch fixes your problem. It seems to do it for me. > >Thanks for finding this. > >Guy > >-----Original Message----- >From: Mike McCormack <mike_mccormack(a)start.com.au> >To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> >Date: Thursday, June 28, 2001 10:46 PM >Subject: rebar trouble with WinZip 8.0 > > >>Hi, >> >>WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but >>it seems to have a problem now, since only the LHS >>button is shown. Some debug output below. >> >>Mike ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

July 2, 2001

opengl32.dll works, but how about opengl.dll

by adoniz＠hushmail.com

Another (small I think) problem I noticed is that some braindead Windows apps (yes, 32bit, Windows 9x) are linked against opengl.dll as opposed to opengl32.dll !! But this makes wine refuse to run them because it doesn't "recognize" that the application needs the built-in openGL support. So how would one go about fixing this, so that Wine will use the builtin OpenGL support not just for openg32.dll but also for opengl.dll ? thanks in advance ps. please email me as i am not subscribed to the ML Free, encrypted, secure Web-based email at www.hushmail.com

July 1, 2001

GDI Memory Leak + err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this.

by adoniz＠hushmail.com

I got these errors while trying to do something a little uncommon: I have been running Halflife from my windows partiton just fine. But I wanted to remove the huge files and replace them with symlinks to a cdrom, but since I can't do symlinks on fat32 (is there a wine hack for this?? i think it would be a great idea!!), I figured I copy the basic files of HL to my linux partition, and symlink the huge pak files. So, I have /mnt/halflife and under there I have some symlinks. I went ahead and added these to my ~/.wine/config [Drive H] "Path" = "/mnt" "Type" = "hd" "Filesystem" = "vfat" Now, as root try running halflife with: cd /mnt/halflife ; wine hl.exe or wine h:\\halflie\hl.exe (or with all the command line options for opengl, software, etc) I get these errors and a SegFault from wine: /mnt/halflife# wine h:\\halflife\\hl.exe -- -console -toconsole -soft -w 640 -win err:local:LOCAL_GetBlock not enough space in GDI heap 0237 for 108 bytes err:region:CombineRgn Invalid rgn=0000 err:x11drv:X11DRV_SetDeviceClipping Rgn is 0. Please report this. err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 err:region:CombineRgn Invalid rgn=0000 Segmentation fault whatever:/mnt/halflife# err:ntdll:RtlpWaitForCriticalSection Critical section 0x4065da54 wait timed out, retrying (60 sec) fs=0257 Running notepad.exe from /mnt/ works just fine. So something else is happening here... Email me if you need more info thanks Free, encrypted, secure Web-based email at www.hushmail.com

July 1, 2001

Re: rebar trouble with WinZip 8.0

by Guy L. Albertelli

Hi Mike, See if the attached patch fixes your problem. It seems to do it for me. Thanks for finding this. Guy -----Original Message----- From: Mike McCormack <mike_mccormack(a)start.com.au> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> Date: Thursday, June 28, 2001 10:46 PM Subject: rebar trouble with WinZip 8.0 >Hi, > >WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but >it seems to have a problem now, since only the LHS >button is shown. Some debug output below. > >Mike > > >mike(a)linux:~/c > wine Program\ Files/WinZip/WINZIP32.EXE >Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: >x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in >config file >.. >trace:rebar:REBAR_AdjustBands start=0, end=0, max x=550, max y=61 >trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start >band 0, end band 0 >trace:rebar:REBAR_AdjustBands start=0, end=0, max x=561, max y=61 >trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, >xsep=0 >err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start >band 0, end band 0 >.. >fixme:shell:SHGetFileInfoA set icon to shell size, stub >fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray >0x405a6a74 >mike(a)linux:~/c > > > >------------------------------------------ >mailto:Mike_McCormack(a)looksmart.com.au >ph +82 16 430 0425 > >__________________________________________________________________ >Get your free Australian email account at http://www.Looksmart.com.au > > >

July 1, 2001

Re: convert 16bit comm stuff to use handles

by Ove Kaaven

On Sat, 30 Jun 2001, Mike McCormack wrote: > this is the first step in cleaning up the 16bit comm code. > This patch is untested, so have a look, and give it a go! > - ptr->s_read = SERVICE_AddObject( FILE_DupUnixHandle( ptr->fd, > - GENERIC_READ | SYNCHRONIZE ), > + ptr->s_read = SERVICE_AddObject( ptr->handle, > comm_notification, > (ULONG_PTR)ptr ); Not good... you *must* duplicate the handle (probably with DuplicateHandle) before passing it to SERVICE_AddObject. The SERVICE_Delete will close the handle passed to AddObject, which is bound to cause problems if it's not a duplicate.

July 1, 2001

Re: convert 16bit comm stuff to use handles (fwd)

by lawson_whitney＠juno.com

OOPS, this was meant for wine-devel, not wine-patches. Sorry! On Sat, 30 Jun 2001, Mike McCormack wrote: > > Hi, > > this is the first step in cleaning up the 16bit comm code. > This patch is untested, so have a look, and give it a go! > > Mike > Good day! Turns out the app will still run with --winver win31 (I swear it worked with --winver nt40 before, I think :-) but with the patch, it can't find the modem with both hands and a flashlight. Seems not to see input. comm trace is attached. Let me know if (which) additional traces would help. Lawson ---blah---

July 1, 2001