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

Re: Documentation fixes
by Alexandre Julliard 15 Jul '01

15 Jul '01

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

1 0

Re: implement SetCommState16 using SetCommState
by lawson_whitney＠juno.com 15 Jul '01

15 Jul '01

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.

1 0

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