January 2002 - Wine-Devel - list.winehq.org

Re: Fwd: Total Annihilation

by Daniel Davis

Sorry, I feel like an idiot.. I didn't even think about return codes inside the program which you wouldn't have any control over. I was assuming it was a wine generated code. (blatantly incorrect assumption now that I'm coherent).. Well, I guess that's what I get for trying to think while being exhausted. Actually, I am reasonably certain it's more of a setup issue than a bug. I am interested in helping the development effort but I am just getting started using Wine so I didn't want to ask too many stupid questions without knowing enough about the codebase. I would like to point out that I have 7 years experience programming in C and 4 in C++ and I'm perfectly competent. But we all have to start somewhere. I think I've figured out the problem though. It's not finding a DLL in the same directory as the executable. Daniel On Monday 28 January 2002 06:10 pm, David Elliott wrote: > On 2002.01.28 09:03 Daniel Davis wrote: > > Hi guys, I sent this to the wine-users list but didn't get any response > > so I > > thought maybe you could answer this. I am simply trying to figure out > > why > > Total Annihilation keeps terminating with a code 21. I would prefer to > > know > > where the list of errors is so that I can solve these on my own without > > needing to pester people all the time. :-) > > > > Daniel > > Could you be more vague? > > I have no idea what the value of the wine return code can be. So if you > are talking about something like printing out the value that the wine > program returned from the shell after running it.. I dunno what to tell > you. > > Now if you are talking about some message, well the error code is most > likely a Windows one, which you could find in the include/winerror.h > file. Doing a quick look through that shows that ERROR_NOT_READY is > defined to windows error code 21. > > For Linux error codes EISDIR corresponds to error code 21 (from > /usr/include/asm/errno.h). > > I would suggest that you stick to the wine-users list unless you plan on > helping to develop Wine. Not that we don't like you, but this list is for > developer traffic which /sometimes/ includes /detailed/ bug reports. Look > in the wine documentation on how to use debugmsg effectively and so on and > post an appropriate trace to wine-users. Generally one of the developers > who monitors wine-users will take the detailed bug report and do something > about it. Usually involving posting the relevant information to this list > (wine-devel). > > -Dave

Jan. 28, 2002

Re: Sooo quiet...

by David Elliott

On 2002.01.28 16:50 Dimitrie O. Paun wrote: > On Mon, 28 Jan 2002, Eric Pouech wrote: > > > IMO, what's important behind version numbers isn't the version in > > itself, > > but rather: > > 1] the goal you want to reach > > 2] the milestones between where you stand and 1] > > Indeed. But you see, for an outsider, these are all "just details". For > most people, version numbers provide a sort of progress bar. (It's true, > the info provided by a progress bar is mostly useless, but most people > will want that instead of no feedback). It is up to Alexandre to figure > out this progress bar, on whatever terms. A version number like 0.98.4 > does provide a lot more "warm & fuzzy" (and a little bit more > information), than a 020402 version which provides _no_ information > whatsoever. In fact, just by looking at such version you can't figure: > -- if the project made any progress at all > -- how much progress was made (if we assume some did occur) > -- the psychological gage of the maintainer on how close we are to some > meaningful goal. > There is this wonderful thing called the ChangeLog. There is also the ability to view the wine-cvs mailing list archives and see what has been fixed. I think that Wine still has a bit to go before we can even consider pre-1.0 releases. As eric said in order to do 0.99.x type releases you need goals/milestones. I think that we should get all the technical stuff done (i.e. stabilize server protocol, overhaul USER) before 0.99.0. When the major things have been done then I think we could safely consider wine to be beta software instead of alpha software, at which point I think an 0.99.0 branch of the CVS tree should be made and we should work towards 1.0 from there. The other option is to just leave it in the trunk of CVS-- which for our purposes may be just as well if not better since we'd probably want to concentrate development work on 1.0. Moving to a 0.99.x version scheme while wine is still alpha is /not/ a good idea. -Dave

Jan. 28, 2002

Re: Fwd: Total Annihilation

by Lionel Ulmer

> > Total Annihilation keeps terminating with a code 21. I would prefer to > > know where the list of errors is so that I can solve these on my own without > > needing to pester people all the time. :-) > > Could you be more vague? Well, just to add something, I once had a report like that on #WineHQ and the error report came (as far as I could tell) from here : miscemu/main.c : int WINAPI wine_initial_task( HINSTANCE inst, HINSTANCE prev, LPSTR cmdline, INT show ) { (...) if ((instance = NE_StartMain( main_exe_name, main_exe_file )) < 32) { (...) switch (instance) { case 2: MESSAGE("file not found\n" ); break; case 11: MESSAGE("invalid exe file\n" ); break; default: MESSAGE("error=%d\n",instance ); break; } (...) loader/ne/module.c : HINSTANCE16 NE_StartMain( LPCSTR name, HANDLE file ) { (...) if ((hModule = NE_LoadExeHeader( file, name )) < 32) return hModule; static HMODULE16 NE_LoadExeHeader( HANDLE hFile, LPCSTR path ) { (...) _llseek( hFile, mz_header.e_lfanew, SEEK_SET ); if (_lread( hFile, &ne_header, sizeof(ne_header) ) != sizeof(ne_header)) return (HMODULE16)11; /* invalid exe */ So it seems that Wine did not manage to read the NE header of the given executable. But I did not investigate further than that as all this is a bit over my head :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 28, 2002

Re: CodeWeaver's patches

by Gerard Patel

At 01:57 AM 1/28/02 -0500, you wrote: >I have finished doing that with one exception: the ListView. This one will >require a lot more work due to the fact that it was extensively modified. >I will work on the listview.c file this week, as I have some of my own >changes that I need to cleanup and submit, as well as CW's changes. Speaking of listview, I have issues with your last changes : notification is broken. I can see it with Eudora 4, but I have a test app in Python that I can send you if you want. I attach the changes I did to get Eudora working again Note that the change in notify() is unrelated, I just noticed the problem when searching the notification problem. Also the following change - if (*ppszText == NULL) - *lpLVItem->pszText = '\0'; is not related to your changes, this was broken a very long time ago. It's just that it makes listview work again for columns > 0. If you think to send your changes soon, maybe you could use my changes or implement them to your liking. Else I can send them myself (if you don't object to my changes), as you prefer. Gerard

Jan. 28, 2002

RE: Sooo quiet...

by lawson_whitney＠juno.com

On 28 Jan 2002, Jeremy White wrote: > Also, I think what's most important about 1.0 is not 1.0 itself, > but it is the promise inherent in 1.1 - that 1.1 will do everything > 1.0 did, and a little more. Exactly. Until we can be reasonably sure that it will, progress-bar version numbers only serve to make us look incompetent. > To that end, I agree that we should > finalize the Wine server protocol, and it sure wouldn't hurt > to have a nice regression system in place as well. > > Jer > The regression testing we need before 0.9.0 or whatever might make sense. I don't mind if the server protocol changes frequently for now. When it settles down, we can finalize it, subject to change in a later release. The server version control mechanism works pretty well, and I've only been bit by it a few times. Lawson

Jan. 28, 2002

Re: Compilation error

by David Elliott

On 2002.01.28 11:49 Christian Schmitt wrote: > Hello, > > i have a strange problem compiling the newest wine version (20020122). > The compilation process stops with an error message concerning freetype: > [SNIP huge amount of make errors] First of all, generally the first few errors are related to the problem and the remaining ones are caused by the first few errors or have something to do with them. It looks to me as if some header file isn't getting included correctly or is missing the appropriate information. Wine has had several problems with freetype since freetype have changed their header names and defines between releases. The first and most obvious thing to do is remove the config.cache from the wine sourcetree and try rerunning configure to make it detect freetype again. Possibly you had checked out the source, built it, updated freetype, then updated wine from CVS and tried building again but because of config.cache Wine still thinks you have the old freetype. If that fails make SURE you have the freetype libraries AND headers installed properly and that the versions match. Might also be a good idea to search your filesystem for old headers installed in another directory or maybe an old release of the freetype headers installed in the same directory. If all of this fails, post a message to wine-users and see if someone can help you out. Generally the wine-devel list is not meant for this type of question. -Dave

Jan. 28, 2002

Re: Fwd: Total Annihilation

by David Elliott

On 2002.01.28 09:03 Daniel Davis wrote: > Hi guys, I sent this to the wine-users list but didn't get any response > so I > thought maybe you could answer this. I am simply trying to figure out > why > Total Annihilation keeps terminating with a code 21. I would prefer to > know > where the list of errors is so that I can solve these on my own without > needing to pester people all the time. :-) > > Daniel > Could you be more vague? I have no idea what the value of the wine return code can be. So if you are talking about something like printing out the value that the wine program returned from the shell after running it.. I dunno what to tell you. Now if you are talking about some message, well the error code is most likely a Windows one, which you could find in the include/winerror.h file. Doing a quick look through that shows that ERROR_NOT_READY is defined to windows error code 21. For Linux error codes EISDIR corresponds to error code 21 (from /usr/include/asm/errno.h). I would suggest that you stick to the wine-users list unless you plan on helping to develop Wine. Not that we don't like you, but this list is for developer traffic which /sometimes/ includes /detailed/ bug reports. Look in the wine documentation on how to use debugmsg effectively and so on and post an appropriate trace to wine-users. Generally one of the developers who monitors wine-users will take the detailed bug report and do something about it. Usually involving posting the relevant information to this list (wine-devel). -Dave

Jan. 28, 2002

Re: MS' hidden API

by David Elliott

On 2002.01.28 00:44 Zhang Shu wrote: > Dear wine developers, > > I have one question on the development of wine. Long(one or > two years) ago I've heard that Microsoft got some hidden > APIs in their products of various windows, and they use > these APIs in their own applications. I wonder if this is > still a problem on their recent product like windows XP. If > it is, I guess wine will not be able to run such MS > applications which uses hidden APIs. Is this right? > > And, is wine designed(or its goal is) to run all > applications(including MS product and non-MS product) that > runs on windows? > > Please forgive me if this problem has appeared in the > past. I just joined this list a couple of days ago. > Use the source, Luke! Seriously.. a very quick perusal of the Wine sourcetree will show you quite a few undocumented functions that are already well-implemented. It will also show you quite a few that are spec-file stubs (i.e. no-one even knows what parameters the function takes, just that it is there). And you'll also see quite a few that are implemented as stubs (i.e. they receive the correct number and type of paramters and print out a fixme with that information). You also I am sure (with more looking) could find an undoc function that has the parameters wrong. Although most of the time this is not the case since if the incorrect number of bytes are popped off the stack then the program will surely crash. -Dave

Jan. 28, 2002

Re: A new SDL back-end we've been toying with

by Hetz Ben Hamo

> Hmm, maybe I should actually do that. As an added bonus since VNC is just > basically a generic framebuffer it would allow a fairly easy port to > another generic framebuffer interface such as LinuxFB (or whatever the new > hot-shit FB project for Linux is these days). Hmm, do I hear embedded devices with wine? :) Hetz

Jan. 28, 2002

Re: CodeWeaver's patches

by Dimitrie O. Paun

On Mon, 28 Jan 2002, Gerard Patel wrote: > Speaking of listview, I have issues with your last changes : > notification is broken. I can see it with Eudora 4, but I have a test > app in Python that I can send you if you want. Of course I'd like that, if it's not too much to ask. > If you think to send your changes soon, maybe you could > use my changes or implement them to your liking. Else I can > send them myself (if you don't object to my changes), as > you prefer. It's OK, just go ahead and submit them, I'll work from them as soon as Alexandre starts commiting stuff. Thanks for finding and fixing the bugs. -- Dimi. P.S. Looking at CW's patch, I realized that I forgot to do the conversion on the way back in the LVN_GETDISPINFO notification...

Jan. 28, 2002

Re: A new SDL back-end we've been toying with

by David Elliott

On 2002.01.28 02:12 Gavriel State wrote: > There would be no appreciable differences. As I said, this was mostly > something > we were just toying with. > > -Gav > Very interesting. I was considering making an RFB (the VNC protocol) backend for Wine for about the same reason. That is that the only really decent driver is X11 right now since ttydrv is fairly useless. Hmm, maybe I should actually do that. As an added bonus since VNC is just basically a generic framebuffer it would allow a fairly easy port to another generic framebuffer interface such as LinuxFB (or whatever the new hot-shit FB project for Linux is these days). -Dave

Jan. 28, 2002

Re: Sooo quiet...

by Dimitrie O. Paun

On Mon, 28 Jan 2002, Alexandre Julliard wrote: > Do you want me to commit patches, or do you want a flamewar? You > can't have both <g> But of course I want both! (I'm just like a little kid -- I want my cake and eat it too :)) > Seriously, it is planned to have a 0.9 version, but I don't want to > use the name for any random version, otherwise it doesn't mean > anything more than the current scheme. My plan is to have 0.9 mark the > point where all the 1.0 features are in place and all that remains is > bug fixing. Then the 0.9.x series will be a progressive code freeze > (each release being a little colder than the previous one) converging > towards 1.0. Excellent -- this is exactly what I had in mind. Happy, happy, joy, joy! BTW, I'm a pedantic bastard sometimes, and one thing that bothers me (and is not that important in the great scheme of things, I agree), is the fact that we haven't completed the directory restructuring yet. I would hope we get that done before 1.0 so we don't have to (1) propagate it for historical reasons, and (2) don't confuse newcomers. -- Dimi.

Jan. 28, 2002

Re: Sooo quiet...

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Yeah, I was wondering about that. I have some more in the queue, but I'll > for Alexandre to commit whatever I already submitted. (hint, hint :) ) Do you want me to commit patches, or do you want a flamewar? You can't have both <g> Seriously, it is planned to have a 0.9 version, but I don't want to use the name for any random version, otherwise it doesn't mean anything more than the current scheme. My plan is to have 0.9 mark the point where all the 1.0 features are in place and all that remains is bug fixing. Then the 0.9.x series will be a progressive code freeze (each release being a little colder than the previous one) converging towards 1.0. -- Alexandre Julliard julliard(a)winehq.com

Jan. 28, 2002

RE: Sooo quiet...

by Dimitrie O. Paun

On Mon, 28 Jan 2002, Patrik Stridvall wrote: > Well, I guess he will have fun with all the outstanding patches. > I think he has never had so many. :-) Yeah, I was wondering about that. I have some more in the queue, but I'll for Alexandre to commit whatever I already submitted. (hint, hint :) ) > Unfortunetely there won't be any flamewar as far as I'm > concerned since don't care very much either way. :-) You are either with me, or against me!!! No middle of the road will do on this issue :P -- Dimi.

Jan. 28, 2002

Re: Sooo quiet...

by Dimitrie O. Paun

On Mon, 28 Jan 2002, Eric Pouech wrote: > IMO, what's important behind version numbers isn't the version in > itself, > but rather: > 1] the goal you want to reach > 2] the milestones between where you stand and 1] Indeed. But you see, for an outsider, these are all "just details". For most people, version numbers provide a sort of progress bar. (It's true, the info provided by a progress bar is mostly useless, but most people will want that instead of no feedback). It is up to Alexandre to figure out this progress bar, on whatever terms. A version number like 0.98.4 does provide a lot more "warm & fuzzy" (and a little bit more information), than a 020402 version which provides _no_ information whatsoever. In fact, just by looking at such version you can't figure: -- if the project made any progress at all -- how much progress was made (if we assume some did occur) -- the psychological gage of the maintainer on how close we are to some meaningful goal. -- Dimi.

Jan. 28, 2002

RE: Sooo quiet...

by Jeremy White

> I'm slightly against changing the versioning scheme before 1.0. > After 1.0 we probably want to have so sort of different versioning > especially since we might release different versions of the DLL:s > independently of each other. However I don't think there is much > use of having that pre 1.0. > It's funny, I've spent the last two years trying to convince Alexandre we should have an 0.9, but now I think I've reversed my original opinion and think we should stick with our current scheme until 1.0. Also, I think what's most important about 1.0 is not 1.0 itself, but it is the promise inherent in 1.1 - that 1.1 will do everything 1.0 did, and a little more. To that end, I agree that we should finalize the Wine server protocol, and it sure wouldn't hurt to have a nice regression system in place as well. Jer

Jan. 28, 2002

RE: Sooo quiet...

by Patrik Stridvall

> ... I feel like starting a flamewar, just to get some > traffic on this list :) Yes!!! Flamewar!!! No retreat!!! No surrender!!! > Speaking of which, I figured I should rattle Alexandre's cage :) Well, I guess he will have fun with all the outstanding patches. I think he has never had so many. :-) > So here I go: > > Wine's been around for 8 (_eight_) years (how time flies)! It is my > understanding that we're approaching the 1.0 status. I say, > let's change > the versioning scheme, just to give the outside world a feeling of > progress. Really, I think the current scheme kindda hurts us on a PR > level. > > We can start with something like 0.90.0. This should give us plenty > numbers to the upcoming 1.0, don't you think? Unfortunetely there won't be any flamewar as far as I'm concerned since don't care very much either way. :-) But if anybody is intrested in my opinion anyway here goes: I'm slightly against changing the versioning scheme before 1.0. After 1.0 we probably want to have so sort of different versioning especially since we might release different versions of the DLL:s independently of each other. However I don't think there is much use of having that pre 1.0.

Jan. 28, 2002

Re: Sooo quiet...

by Eric Pouech

> ... I feel like starting a flamewar, just to get some > traffic on this list :) that's true... we really miss some good ones (licence issues, regression test suite...) ;-) > Wine's been around for 8 (_eight_) years (how time flies)! It is my > understanding that we're approaching the 1.0 status. I say, let's change > the versioning scheme, just to give the outside world a feeling of > progress. Really, I think the current scheme kindda hurts us on a PR > level. > > We can start with something like 0.90.0. This should give us plenty > numbers to the upcoming 1.0, don't you think? IMO, what's important behind version numbers isn't the version in itself, but rather: 1] the goal you want to reach 2] the milestones between where you stand and 1] speaking on 1], it's has been discussed a bit before, but no clear definition has been put up. you can either describe Wine 1.0 in terms of: a) what should Wine 1.0 do? in other words, which apps to you want it to run? b) what should Wine 1.0 be able to do? in other words, the functions you want to be implemented. this functional vs technical controversy isn't new. Some folks were more interested in the a) approach. It's what Transgaming did (does) with a target on games (as applications). Some others may suggest (O|o)ffice applications (it seems CodeWeavers folks have been busy on this matter lately ;-) Some other (including Alexandre) were more in favor of the technical approach. This would include finishing the major hurdles. IIRC the discussion at that time, I think most of them have been removed - address space separation: mostly done (even if some USER issues still need to be debugged) - window management rewrite: still in progress - TrueType handling: at least done with Huw latest patches and using XRender (on Xfree >= 4.0.0) Alexandre biggest argument at that time was to stabilize the wineserver protocol definition, so we could upgrade user's side component in a rather stable manner. Anyway, on a more pragmatic term, let's see what needs to be done: from the a) view: - let most of the installers work. This would require some OLE tweaking. Transgaming has part of it, but isn't ready yet for submission from the b) view: - stabilize the wineserver protocol (there's still a few pending issues to be added). - put up a decent regression test in place (framework AND tests) - Unicode support (wide, has to be precised a bit) - finish the window management issues - let the documentation be in sync with the code - fix a guzillion bugs A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 28, 2002

DOSfs - removable media drives.

by Keith Matthews

I noticed earlier today that DOSfs is not correctly handling removable media drives. In particular floppies will get a permissions error message regardless of the actual permissions if there is no media in the drive. Presumeably Jazz type drives would do the same. I have made the assumption that the fact that there is no media in the drive needs to be stored and have added a new value to the drive flags for this. If someone knows better that it cannot be used or clashes with something I have not spotted then please say so. ================================================================ Index: files/drive.c =================================================================== RCS file: /home/wine/wine/files/drive.c,v retrieving revision 1.64 diff -u -u -r1.64 drive.c --- files/drive.c 2002/01/13 01:44:00 1.64 +++ files/drive.c 2002/01/28 16:41:26 @@ -7,6 +7,7 @@ * Label & serial number read support. * (c) 1999 Petr Tomasek <tomasek(a)etf.cuni.cz> * (c) 2000 Andreas Mohr (changes) + * (c) 2002 Keith Matthews (changes) * */ @@ -508,21 +509,95 @@ #define DRIVE_SUPER 96 int fd; off_t offs; + struct stat dev_data; + uid_t user; + gid_t group; if (memset(buff,0,DRIVE_SUPER)!=buff) return -1; - if ((fd=open(DOSDrives[drive].device,O_RDONLY)) == -1) + + if (!DOSDrives[drive].device) { - struct stat st; - if (!DOSDrives[drive].device) - ERR("No device configured for drive %c: !\n", 'A'+drive); - else - ERR("Couldn't open device '%s' for drive %c: ! (%s)\n", DOSDrives[drive].device, 'A'+drive, - (stat(DOSDrives[drive].device, &st)) ? - "not available or symlink not valid ?" : "no permission"); - ERR("Can't read drive volume info ! Either pre-set it or make sure the device to read it from is accessible !\n"); + ERR("No Device Configured for drive %c: !\n",'A'+drive); PROFILE_UsageWineIni(); return -1; } + + if (( stat(DOSDrives[drive].device,&dev_data)) == -1) + { + if (errno == ENOENT || errno == ENOTDIR || errno == ELOOP || errno == ENAMETOOLONG ) + { + ERR("Device ('%s) Configured for drive %c: is not a valid device path!\n",DOSDrives[drive].device,'A'+drive); + } else if ( errno == EACCES ) + ERR("Permissions problem on device for drive %c: !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + } else + { + user = getuid(); + group = getgid(); + if ( user == dev_data.st_uid) + { + /* We are running as the device owner - check those perms */ + if ( (dev_data.st_mode & S_IRUSR) == 0 ) + { + /* owner does not have read perms - stupid but */ + ERR("Permissions problem on device for drive %c: - user does not have read access !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + } + } else if ( group == dev_data.st_gid ) + { + if ( (dev_data.st_mode & S_IRGRP) == 0 ) + { + /* group does not have read perms */ + ERR("Permissions problem on device for drive %c: - group does not have read access !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + } + + } else if ( (dev_data.st_mode & S_IROTH) == 0 ) + { + /* not owning user or group and no perms */ + ERR("Permissions problem on device for drive %c: - effective user does not have read access !\n", 'A'+drive); + PROFILE_UsageWineIni(); + return -1; + + } + } + + if ((fd=open(DOSDrives[drive].device,O_RDONLY)) == -1) + { + if (DOSDrives[drive].type == DRIVE_REMOVABLE ) + { + /***************************************************************************** + * OK, we've checked just about everything we can, it's a removeable media + * device, so assume no media since that gives same response + * + * Wrong if not running as root and user does not have read to device but + * we've already checked for that above + * + **************************************************************************/ + + DOSDrives[drive].flags = DOSDrives[drive].flags | DRIVE_NO_MEDIA; + return 0; + +/* ++++++++++++++++ should we be down here for CD's also ? also what about Jazz drives etc ?+++++++++++++++++++++++ */ + + } else { + /**************************************************************************** + * + * Not removeable media device - must be permissions problem + * + ***************************************************************************/ + ERR("Couldn't open device '%s' for drive %c: ! (%s)\n", DOSDrives[drive].device, 'A'+drive, + "no permission"); + ERR("Can't read drive volume info ! Either pre-set it or make sure the device to read it from is accessible !\n"); + PROFILE_UsageWineIni(); + return -1; + + } + } + Index: include/drive.h =================================================================== RCS file: /home/wine/wine/include/drive.h,v retrieving revision 1.8 diff -u -u -r1.8 drive.h --- include/drive.h 2000/12/12 00:44:43 1.8 +++ include/drive.h 2002/01/28 16:41:57 @@ -19,6 +19,7 @@ #define DRIVE_CASE_PRESERVING 0x0008 /* Drive fs is case preserving */ #define DRIVE_FAIL_READ_ONLY 0x0010 /* Fail opening read-only files for writing */ #define DRIVE_READ_VOL_INFO 0x0020 /* Try to read volume info from the device? */ +#define DRIVE_NO_MEDIA 0x0040 /* no media in drive */ extern int DRIVE_Init(void); extern int DRIVE_IsValid( int drive ); -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration

Jan. 28, 2002

Sooo quiet...

by Dimitrie O. Paun

... I feel like starting a flamewar, just to get some traffic on this list :) Speaking of which, I figured I should rattle Alexandre's cage :) So here I go: Wine's been around for 8 (_eight_) years (how time flies)! It is my understanding that we're approaching the 1.0 status. I say, let's change the versioning scheme, just to give the outside world a feeling of progress. Really, I think the current scheme kindda hurts us on a PR level. We can start with something like 0.90.0. This should give us plenty numbers to the upcoming 1.0, don't you think? -- Dimi.

Jan. 28, 2002

Compilation error

by Christian Schmitt

Hello, i have a strange problem compiling the newest wine version (20020122). The compilation process stops with an error message concerning freetype: make[2]: Entering directory `/usr/src/wine-20020122/dlls/gdi' gcc -c -I. -I. -I../../include -I../../include -I/usr/local/include/freetype2 -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:56: parse error before `library' freetype.c:56: warning: type defaults to `int' in declaration of `library' freetype.c:56: warning: data definition has no type or storage class freetype.c:74: parse error before `FT_Face' freetype.c:74: warning: no semicolon at end of struct or union freetype.c: In function `AddFontFileToList': freetype.c:81: `FT_Face' undeclared (first use in this function) freetype.c:81: (Each undeclared identifier is reported only once freetype.c:81: for each function it appears in.) freetype.c:81: parse error before `ft_face' freetype.c:89: warning: implicit declaration of function `FT_New_Face' freetype.c:89: `ft_face' undeclared (first use in this function) freetype.c:94: warning: implicit declaration of function `FT_IS_SFNT' freetype.c:95: warning: implicit declaration of function `FT_Done_Face' freetype.c:138: `FT_STYLE_FLAG_ITALIC' undeclared (first use in this function) freetype.c:139: `FT_STYLE_FLAG_BOLD' undeclared (first use in this function) freetype.c: In function `WineEngInit': freetype.c:193: warning: implicit declaration of function `FT_Init_FreeType' freetype.c: At top level: freetype.c:230: parse error before `OpenFontFile' freetype.c:231: warning: return-type defaults to `int' freetype.c: In function `OpenFontFile': freetype.c:232: `FT_Error' undeclared (first use in this function) freetype.c:232: parse error before `err' freetype.c:233: `TT_OS2' undeclared (first use in this function) freetype.c:233: `pOS2' undeclared (first use in this function) freetype.c:233: warning: statement with no effect freetype.c:234: `FT_Face' undeclared (first use in this function) freetype.c:234: parse error before `ft_face' freetype.c:237: `err' undeclared (first use in this function) freetype.c:237: `ft_face' undeclared (first use in this function) freetype.c:243: warning: implicit declaration of function `FT_Get_Sfnt_Table' freetype.c:243: `ft_sfnt_os2' undeclared (first use in this function) freetype.c:262: `ppem' undeclared (first use in this function) freetype.c:267: warning: implicit declaration of function `FT_Set_Pixel_Sizes' freetype.c: In function `WineEngCreateFontInstance': freetype.c:288: dereferencing pointer to incomplete type freetype.c:289: dereferencing pointer to incomplete type freetype.c:317: dereferencing pointer to incomplete type freetype.c: In function `WineEngAddRefFont': freetype.c:330: dereferencing pointer to incomplete type freetype.c:331: warning: control reaches end of non-void function freetype.c: In function `WineEngDecRefFont': freetype.c:339: dereferencing pointer to incomplete type freetype.c:342: dereferencing pointer to incomplete type freetype.c: In function `GetEnumStructs': freetype.c:353: dereferencing pointer to incomplete type freetype.c:355: dereferencing pointer to incomplete type freetype.c:356: dereferencing pointer to incomplete type freetype.c: In function `WineEngGetGlyphOutline': freetype.c:469: `FT_Face' undeclared (first use in this function) freetype.c:469: parse error before `ft_face' freetype.c:470: `FT_UInt' undeclared (first use in this function) freetype.c:472: `FT_Bitmap' undeclared (first use in this function) freetype.c:472: parse error before `ft_bitmap' freetype.c:478: `glyph_index' undeclared (first use in this function) freetype.c:480: warning: implicit declaration of function `FT_Get_Char_Index' freetype.c:480: `ft_face' undeclared (first use in this function) freetype.c:482: warning: implicit declaration of function `FT_Load_Glyph' freetype.c:482: `FT_LOAD_DEFAULT' undeclared (first use in this function) freetype.c:494: `ft_glyph_format_outline' undeclared (first use in this function) freetype.c:506: `ft_bitmap' undeclared (first use in this function) freetype.c:509: `ft_pixel_mode_mono' undeclared (first use in this function) freetype.c:512: warning: implicit declaration of function `FT_Outline_Translate'freetype.c:517: warning: implicit declaration of function `FT_Outline_Get_Bitmap' freetype.c: In function `WineEngGetTextMetrics': freetype.c:531: `FT_Face' undeclared (first use in this function) freetype.c:531: parse error before `ft_face' freetype.c:532: `TT_OS2' undeclared (first use in this function) freetype.c:532: `pOS2' undeclared (first use in this function) freetype.c:532: warning: statement with no effect freetype.c:533: `TT_HoriHeader' undeclared (first use in this function) freetype.c:533: `pHori' undeclared (first use in this function) freetype.c:533: warning: statement with no effect freetype.c:534: `FT_Fixed' undeclared (first use in this function) freetype.c:534: parse error before `x_scale' freetype.c:536: `x_scale' undeclared (first use in this function) freetype.c:536: `ft_face' undeclared (first use in this function) freetype.c:537: `y_scale' undeclared (first use in this function) freetype.c:539: `ft_sfnt_os2' undeclared (first use in this function) freetype.c:545: `ft_sfnt_hhea' undeclared (first use in this function) freetype.c:558: warning: implicit declaration of function `FT_MulFix' freetype.c:581: `FT_STYLE_FLAG_ITALIC' undeclared (first use in this function) freetype.c:586: warning: implicit declaration of function `FT_IS_FIXED_WIDTH' freetype.c:587: warning: implicit declaration of function `FT_IS_SCALABLE' freetype.c: In function `WineEngGetOutlineTextMetrics': freetype.c:602: `FT_Face' undeclared (first use in this function) freetype.c:602: parse error before `ft_face' freetype.c:604: `TT_OS2' undeclared (first use in this function) freetype.c:604: `pOS2' undeclared (first use in this function) freetype.c:604: warning: statement with no effect freetype.c:605: `TT_HoriHeader' undeclared (first use in this function) freetype.c:605: `pHori' undeclared (first use in this function) freetype.c:605: warning: statement with no effect freetype.c:606: `FT_Fixed' undeclared (first use in this function) freetype.c:606: parse error before `x_scale' freetype.c:613: `ft_face' undeclared (first use in this function) freetype.c:615: `family_nameW' undeclared (first use in this function) freetype.c:621: `style_nameW' undeclared (first use in this function) freetype.c:648: `x_scale' undeclared (first use in this function) freetype.c:649: `y_scale' undeclared (first use in this function) freetype.c:651: `ft_sfnt_os2' undeclared (first use in this function) freetype.c:658: `ft_sfnt_hhea' undeclared (first use in this function) freetype.c:704: `cp' undeclared (first use in this function) freetype.c:714: `spaceW' undeclared (first use in this function) freetype.c: In function `WineEngGetFontData': freetype.c:785: `FT_Face' undeclared (first use in this function) freetype.c:785: parse error before `ft_face' freetype.c:786: `TT_Face' undeclared (first use in this function) freetype.c:787: `SFNT_Interface' undeclared (first use in this function) freetype.c:787: `sfnt' undeclared (first use in this function) freetype.c:787: warning: statement with no effect freetype.c:788: parse error before `len' freetype.c:789: `FT_Error' undeclared (first use in this function) freetype.c:791: `ft_face' undeclared (first use in this function) freetype.c:794: `tt_face' undeclared (first use in this function) freetype.c:794: parse error before `ft_face' freetype.c:795: parse error before `)' freetype.c:798: `len' undeclared (first use in this function) freetype.c:807: `err' undeclared (first use in this function) make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/usr/src/wine-20020122/dlls/gdi' make[1]: *** [gdi/libgdi32.so] Error 2 make[1]: Leaving directory `/usr/src/wine-20020122/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install. I don't know what to do to solve this problem. I tried "./configure --disable-freetype" to no avail. I use Xfree86 4.1.0 (self compiled) on a Debian 2.2r2 system. Can anybody help me with this issue? I need a way to disable freetype or another solution. I hope somebody can help me. Bye Chris -- Linux - Cause life is too short for reboots

Jan. 28, 2002

Fwd: Total Annihilation

by Daniel Davis

Hi guys, I sent this to the wine-users list but didn't get any response so I thought maybe you could answer this. I am simply trying to figure out why Total Annihilation keeps terminating with a code 21. I would prefer to know where the list of errors is so that I can solve these on my own without needing to pester people all the time. :-) Daniel ---------- Forwarded Message ---------- Subject: Total Annihilation Date: Sun, 27 Jan 2002 13:40:38 -0500 From: Daniel Davis <planetes(a)cfl.rr.com> To: wine-users(a)winehq.com Hi everyone, I just started tinkering with wine on my system and everytime I try to run Total Annihilation it dies with a return (error) code 21. Is there a list of return codes anywhere in wine that can help me determine where this program and any others I try to run in the future are dying? Daniel -------------------------------------------------------

Jan. 28, 2002

Re: Pajama Sam's unmanaged window

by Ori Pessach

Hi, With three small changes to menu.c, tooltips.c and window.c, things I'm getting much better results with Pajam Sam et al, without getting WM decorations on tooltips and context menus. The changes are: - Changed is_window_managed()'s default return value to TRUE - In tooltips.c, TOOLTIPS_NCCreate(), I set the WS_EX_TOOLWINDOW bit in the tooltip's dwExStyle field. This, I believe, is the right thing to do regardless of WM considerations, since MSDN specifies that tooltip windows have that bit set. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl…) - In menu.c, I replaced CreateWindowA() with CreateWindowExA(), passing WS_EX_TOOLWINDOW as the first parameter. I'm not so sure about this one. I don't know whether Windows does this (Win16 surely doesn't), and if it doesn't, it might break apps that examine those bits. With these changes, Pajama Sam works correctly, except for the KDE panel problem. I tested another app (WinRAR) for tooltip and context menu behavior, and it worked fine. I'd be happier if somebody else tested this, too, before submitting the patch. If someone with a Windows machine could check the dwExStyle bits on menus somehow, that would be nice. I'll do it myself, as soon as I can get my hands on the necessary software. (Windows, mostly). Anyway, here's the patch: Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.135 diff -u -r1.135 menu.c --- controls/menu.c 2002/01/03 02:35:23 1.135 +++ controls/menu.c 2002/01/28 05:51:10 @@ -1618,10 +1618,12 @@ } /* NOTE: In Windows, top menu popup is not owned. */ - menu->hWnd = CreateWindowA( POPUPMENU_CLASS_ATOM, NULL, - WS_POPUP, x, y, width, height, - hwndOwner, 0, GetWindowLongA(hwndOwner,GWL_HINSTANCE), - (LPVOID)hmenu ); + menu->hWnd = CreateWindowExA( WS_EX_TOOLWINDOW, + POPUPMENU_CLASS_ATOM, NULL, + WS_POPUP, x, y, width, height, + hwndOwner, 0, GetWindowLongA(hwndOwner,GWL_HINSTANCE), + (LPVOID)hmenu ); + if( !menu->hWnd ) return FALSE; if (!top_popup) top_popup = menu->hWnd; Index: dlls/comctl32/tooltips.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/tooltips.c,v retrieving revision 1.40 diff -u -r1.40 tooltips.c --- dlls/comctl32/tooltips.c 2002/01/04 21:27:34 1.40 +++ dlls/comctl32/tooltips.c 2002/01/28 05:51:11 @@ -2114,10 +2114,14 @@ TOOLTIPS_NCCreate (HWND hwnd, WPARAM wParam, LPARAM lParam) { DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); + DWORD dwExStyle = GetWindowLongA (hwnd, GWL_EXSTYLE); dwStyle &= 0x0000FFFF; dwStyle |= (WS_POPUP | WS_BORDER | WS_CLIPSIBLINGS); SetWindowLongA (hwnd, GWL_STYLE, dwStyle); + + dwExStyle |= WS_EX_TOOLWINDOW; + SetWindowLongA (hwnd, GWL_EXSTYLE, dwExStyle); return TRUE; } Index: dlls/x11drv/window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.30 diff -u -r1.30 window.c --- dlls/x11drv/window.c 2002/01/21 18:41:27 1.30 +++ dlls/x11drv/window.c 2002/01/28 05:51:19 @@ -71,8 +71,9 @@ /* windows with caption or thick frame are managed */ if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) return TRUE; if (win->dwStyle & WS_THICKFRAME) return TRUE; + /* default: not managed */ - return FALSE; + return TRUE; } _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Jan. 28, 2002

Re: A new SDL back-end we've been toying with

by Gavriel State

There would be no appreciable differences. As I said, this was mostly something we were just toying with. -Gav Hetz Ben Hamo wrote: > > Hï Gavriel, > > Could you provide 2 screenshots please - one with this SDL driver and the > same - without SDL please? > > Thanks, > Hetz > > On Sunday 27 January 2002 06:49, Gavriel State wrote: > > Hi everyone, > > > > We just put this together for some testing, and thought that someone might > > find it handy. I'm not submitting it to wine-patches, since we haven't > > tested it on the most recent winehq tree, but it should be pretty easy to > > integrate in. It's not 100% complete by any means, but it has both GDI > > bitmap and DDraw support. We can vouch that it runs some of the DDraw > > samples, but beyond that, who knows. > > > > That said, the SDL driver should be a useful alternative to the ttydrv > > for testing purposes. > > > > -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Jan. 28, 2002

CodeWeaver's patches

by Dimitrie O. Paun

Hi people, As you already know, I've signed up for the task of breaking down CW's patches (office[12].diff), for the common controls (dlls/comctl32/*) I have finished doing that with one exception: the ListView. This one will require a lot more work due to the fact that it was extensively modified. I will work on the listview.c file this week, as I have some of my own changes that I need to cleanup and submit, as well as CW's changes. -- Dimi.

Jan. 28, 2002