wine-devel

wine-devel@winehq.org

1 participants
84398 discussions

Win95 version fix
by Francois Gouget 14 Jul '01

14 Jul '01

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.

1 0

RE: Documentation fixes
by Patrik Stridvall 14 Jul '01

14 Jul '01

> 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.

1 0

Re: Documentation fixes
by Alexandre Julliard 14 Jul '01

14 Jul '01

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

1 0

RE: Documentation fixes
by Patrik Stridvall 14 Jul '01

14 Jul '01

> 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.

1 0

Re: Documentation fixes
by Alexandre Julliard 14 Jul '01

14 Jul '01

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

1 0

Re: hello all
by Travis Michielsen 14 Jul '01

14 Jul '01

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/

1 0

[PATCH] dde unicode warning
by Gerard Patel 14 Jul '01

14 Jul '01

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

1 0

[PATCH] Toolbar : image list can be changed after TB_SETIMAGELIST;
by Gerard Patel 14 Jul '01

14 Jul '01

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

1 0

RE: Documentation fixes
by Patrik Stridvall 14 Jul '01

14 Jul '01

> 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.

1 0

Handling X errors using exception handlers
by Lionel Ulmer 14 Jul '01

14 Jul '01

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/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel