Re: What is a leap second
György, could you check which other includes can be used if winternl.h is absent? Else youll probably have to wait for somebody which has it to compile your test. This is included in the latest platform SDK but it should also be defined in ntddk.h. Ok, could somene rather compile this test and send its results? It will be quite big... nog. timetest.c Description: Binary data
Re: Versions mass-appeal
Ender wrote: - Getting the right set of dlloverrides and registry entries correct for a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed. I'm willing to tackle that (the BiDi stuff is only slowly going, and there may be some unexpected development coming that is outside my hands, so I have SOME free resources available). Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it? - When are the boot time activities taking place? On wine start? On wineserver start? - When are login time activities taking place? - How should a reboot request be treated? Should it be an indication that all these operations should start now, and let other wine programs carry on as usual? Shachar
Re: Versions mass-appeal
Dimi, For somebody with a sore hand, you type an amazing amount. I seem to have caught your my-right-hand-is-hurting bug. Well, actually it is my arm - utterly useless at anything at present, altough I can type if I position it at exactly the right angle... I think everybody here agrees that Wine's biggest problem is the lack of developers. No developers, slow progress, no users, back to no developers. James had an interresting reply to your mail around the time it takes for new developers to break into Wine. As a newbie myself, I have some thoughts on this... Ok, let's face it, Wine is damn hard. I have around 7 years experience in C++/C mostly on the Windows platform, altough I have done quite a number of personal projects under Linux, eg. XML interface into RPM, etc. I suppose Wine falls into this category, altough my contibution is not quite there, yet. The reason why I like Wine so much is because it is extremely challenging. The beast is complex but (as I've read Jeremy White said before) things do take longer than anticipated. You need good understanding of Windows system calls plus Linux coding experience - a difficult combination to find. I think that a lot of people will look at the code, browse the web/bugzilla, be unable to find anything quick to break into the fold and give up. Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). I personally think this is changing with CodeWeavers delivering commercial products based on Wine. As an example: the last time I played with wine was back in 96/97, I decided to take a serious look again after buying CXOffice and really seeing and reading and starting to believe... (Well, I must admit that I have been reading WWN since it's inception as well, just to get some sort of idea, so I haven't been completely out of touch.) So, yes, potentially you are right, but this is definately changing for the better. How do we change this state of affairs? Well, people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases. What both you and James are referring to is making the process more transparent. People need clear deliverables to be able to focus and redirect their engergy towards something. With my newbie hat on, I can say that we don't provide that. Unless you have been around for a longish period of time, you have no real idea as to the state of affairs. I like both your and James' suggestions, in addition I would like to see the following: 1. Making sure that all tasks, big or small are in BugZilla. Make it easy to find - for instance, if I want to implement a DLL next, which one should it be? If you are not very, very familiar with Windows you wouldn't even know which DLL's on a Windows box are supposed to be replaced. 2. Making sure BugZilla is always updated anbd used in the right fashion. If something gets done, close the bug and make a comment. You need a record ort what has been happening. Remember that this is a real usefull developers-only (???) externtion to the website and makes their lives easier. 3. Better developers documentation, especially to get new guys onboard. (Erm, I think that was mentioned...) I have quite a bit more to say, but I seem to have gottent the angle of the arm to the keyboard wrong at this point... So, that is it for now. Greetings, Jaco
Re: Versions mass-appeal
Shachar Shemesh wrote: Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it? If we ask CodeWeavers nicely, I'm sure they might be willing to donate the reboot stuff? Otherwise you will just be re-inventing the wheel. Greetings, Jaco
Re: Versions mass-appeal
You need good understanding of Windows system calls plus Linux coding experience - a difficult combination to find. IMO one is enough to get started. Solid Linux experience + access to MSDN gives a you good start. I had no Windows programming experience whatsoever before I started working on wine's winsock. I think that a lot of people will look at the code, browse the web/bugzilla, be unable to find anything quick to break into the fold and give up. There are such things, but most of them are of course boring. The sexy parts are hard to get started with. But that's no different than with other larger projects. I personally think this is changing with CodeWeavers delivering commercial products based on Wine. Yes, Codeweavers got brilliant reviews. Transgaming is also doing quite a good job. This may encourage users, but does it encourage developers? What both you and James are referring to is making the process more transparent. People need clear deliverables to be able to focus and redirect their engergy towards something. With my newbie hat on, I can say that we don't provide that. Unless you have been around for a longish period of time, you have no real idea as to the state of affairs. What is most urgently needed IMHO is more up-to-date documentation. Wine is changing very rapidly and the docs, even on WineHQ itself, more often than not don't reflect the changes. And the most important part of the docs would be an easy-to-understand, up-to-date and in-depth tutorial of how to debug wine crashes, failures, etc. using different techniques (trace, winedbg, ..). I know there are docs on that but we must make sure that they are up-to-date. It has happened to myself that I ran into some wine problem, wanted to produce a meaningful bug report, and than gave up because the debugger wouldn't run as expected (or described in the docs I had). Setting up wine such that you can do meaningful debugging currently almost requires wine guru capabilities. The wine Wiki is great but there are far too many empty New Item entries. 2. Making sure BugZilla is always updated anbd used in the right fashion. If something gets done, close the bug and make a comment A problem is that many reporters don't know how to use it. (Report bug, receive request for more information, never answer back - this has happened to me with a bug reporter employed in a wine-related company!). The only way to deal with that is to close the bug if it happens. For such situations I'd appreciate clear guidelines for maintainers. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Versions mass-appeal
On Wed, 2002-10-30 at 00:12, Dimitrie O. Paun wrote: Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised Really, it works? Hmmm, I thought it was only running Freecell Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, freak of nature sideshow; something (maybe) cool to talk about, but utterly useless. Being a long time troll and admittedly bad problem reporter, my lack of experience tends to send me down the wrong path, I can tell you what MY impressions of Wine are. My first success with Wine was quite a few years ago, running Agent .99. At that time, it seemed Win16 programs would have a chance, but Win32 wouldn't make it. Since then, I've purchased Crossover products, and been pleasantly surprised by the applications that run under it. I was astonished to see GetRight work 100%, and almost taken aback to see Delta Force (and it's funky Voxtel engine) running under wine. (Ok DF3 doesn't QUITE make it, but DF1 and DF2 are more than I ever expected. Hmm Maybe desktop mode would work..) I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, Wine is ALPHA software sticks in my head. People know what beta software is, and when someone see's Alpha, they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because Alpha is seen as horribly broken. I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number. I wonder if people think CodeWeaver's Wine is THAT much of a different product than WineHQ's Wine.. Just another perspective, I'll be quiet now :) Oh, and www.winehq.com seems to be down (can't connect from RoadRunner or Savvis networks) Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 [EMAIL PROTECTED]
Re: What is a leap second
with the following output on win2k. 9 0 10 0 9 10 This is weird, I would have expected to get an output like: 2002 10 27 8 9 10 with the followingo patch applied... nog. Index: dlls/ntdll/time.c === RCS file: /home/wine/wine/dlls/ntdll/time.c,v retrieving revision 1.20 diff -u -r1.20 time.c --- dlls/ntdll/time.c 12 Sep 2002 22:07:03 - 1.20 +++ dlls/ntdll/time.c 30 Oct 2002 13:06:12 - -89,7 +89,11 int LeapSecondCorrections, SecondsInDay, CurYear; int LeapYear, CurMonth, GMTOffset; long int Days; - LONGLONG Time = *(LONGLONG *)liTime; + LONGLONG Time; + + Time = liTime-s.HighPart; + Time = 32; + Time += liTime-s.LowPart; /* Extract millisecond from time and convert time into seconds */ TimeFields-Milliseconds = (CSHORT) ((Time % TICKSPERSEC) / TICKSPERMSEC); -147,6 +151,7 TimeFields-Month = (CSHORT) (CurMonth + 1); TimeFields-Day = (CSHORT) (Days + 1); } + /** * RtlTimeFieldsToTime[NTDLL.] *
Re: Testing Applications
Kye Lewis wrote: Hi, I've done a lot of testing different applications that I have (and checking on their progress with new wine versions) and I was wondering: Should I report every application that doesn't work as a separate bug? Yes, a seperate bug report for each program is nessesary. It is possible that there are more than one bug report per program. For example the program crashes when I open a certain menu. and there is a display problem with one of the other menus. A couple of things I would suggest before you submitt any bug report. Do I actually use this program on a regular basis? If this is the case then can I reproduce the bug and do I understand the steps that it takes to reproduce it and am I willing and able to do the followup to ensure that the bug is fixed? If the answer is yes then search bugzilla to see if the bug is already reported. If it is then add to the existing bug report. If not then start a new one. rant At this point I have limited time to spend with wine and I have to be selective about where I spend it. I have seen a recent set of bug reports that simply list a fixme that a program has hit without any indication that the program behaved in an incorrect manner. When I see a bug report like that I want to yell at the reporter for wasting my time with a useless bug report. /rant Simply taking a program at random and seeing if it will run is fine in itself I suppose but submitting a bug report implies a certain commitment to getting it fixed. Tony Lambregts
Testing Applications
Hi, I've done a lot of testing different applications that I have (and checking on their progress with new wine versions) and I was wondering: Should I report every application that doesn't work as a separate bug? Thanks, Kye Lewis [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Versions mass-appeal
On Wednesday 30 October 2002 12:57 am, Ender wrote: - No users, because of two things: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed! wierd, I basically never have theese problems, even in cases where the AppDB says it's an issue... what apps need this right now? - Getting the right set of dlloverrides and registry entries correct for a large portion of software is irritating. yes. perhaps we should include a much larger default config with usable defaults for several popular programs (or two config files, one for shared installs, one for wine-only installs)? I'd be happy to contribute my config file, for one, which runs quite a bit of junk. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed. this is a relatively simple task, isn't it? wininit.ini is especially easy; RunOnce is a little trickier, because some RunOnce stuff should probably be censored. Another issue I see is the appearance of certain 8.3 filenames in the registry and the filesystem when running certain installers; this is kind of tricky to fix programmatically, but it could be done as part of a reboot.so-type program, I guess. Another (simpler) option would be to make a log of such problems during registry and filesystem operations, and notify the user to process the log during reboot. Also, during reboots that I've done using explorer.exe, I notice some regsvr32's tend to fail; usually, they can be fixed using various dll overrides to regsvr32; a registry of special per-dll-to-register regsvr dll overrides, and a wrapper to invoke regsvr32 with the appropriate overrides from this registry, could go a long way towards eliminating this. Again, this will only help those doing mixed installations. -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: Versions mass-appeal
On Wed, Oct 30, 2002 at 07:08:08AM -0600, Rick Romero wrote: I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, Wine is ALPHA software sticks in my head. People know what beta software is, and when someone see's Alpha, they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because Alpha is seen as horribly broken. I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number. Well, but I'd still insist that Wine IS Alpha software. After all we've got about 15000 Windows functions, and of course we only implement about 4000 to 5000, and of those that we do support, a ridiculously small number is entirely bug-free. Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM. That this doesn't happen every day can be attributed... well... to the fact that Wine maybe is not entirely Alpha any more, but by no means does that mean it's Beta or even almost finished. Wine is *not* a standard boring John Doe program, it's got a massively more difficult way to reach final stability. With an ordinary program, every little sub-version can easily be implemented to reach utter stability within its sometimes totally negligible goals. Not to mention that with a standard program, *you* define (and *know* !) what this program is supposed to do and how, whereas with Wine... you know the story ;-)
Re: Versions mass-appeal
On Wed, Oct 30, 2002 at 12:21:51PM +0200, Shachar Shemesh wrote: Ender wrote: - Getting the right set of dlloverrides and registry entries correct for a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed. I'm willing to tackle that (the BiDi stuff is only slowly going, and there may be some unexpected development coming that is outside my hands, so I have SOME free resources available). Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it? I've been having a finished implementation of wineboot in my tree for ages. I guess it's about time to get it submitted... - When are the boot time activities taking place? On wine start? On wineserver start? Good question. I guess we once agreed on it being done on winelauncher script startup. (or alternatively really on user desktop login, but I'm not sure whether this is what we want) winelauncher should probably check whether any of the places that register reboot activities need processing, and if this is the case, then first finish a wineboot process, *then* start regular wine apps. All this would have to be resistant against race conditions, of course :-\ - When are login time activities taking place? - How should a reboot request be treated? Should it be an indication that all these operations should start now, and let other wine programs carry on as usual? IMO we need to make sure we only do this when no other wine process is running. Optionally there could be some way to tell Wine to do it immediately, even during a session, though. Sounds like nobody ever watched the wineconf2002 streams, since nobody ever knows about wineboot... -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Versions mass-appeal
Rick Romero wrote: On Wed, 2002-10-30 at 00:12, Dimitrie O. Paun wrote: Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised Really, it works? Hmmm, I thought it was only running Freecell Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, freak of nature sideshow; something (maybe) cool to talk about, but utterly useless. Being a long time troll and admittedly bad problem reporter, my lack of experience tends to send me down the wrong path, I can tell you what MY impressions of Wine are. My first success with Wine was quite a few years ago, running Agent .99. At that time, it seemed Win16 programs would have a chance, but Win32 wouldn't make it. Since then, I've purchased Crossover products, and been pleasantly surprised by the applications that run under it. I was astonished to see GetRight work 100%, and almost taken aback to see Delta Force (and it's funky Voxtel engine) running under wine. (Ok DF3 doesn't QUITE make it, but DF1 and DF2 are more than I ever expected. Hmm Maybe desktop mode would work..) I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, Wine is ALPHA software sticks in my head. People know what beta software is, and when someone see's Alpha, they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because Alpha is seen as horribly broken. I am beginning to believe that wine is not very alpha anymore. It is more likely to run the program than crash and in some situations can be used in a production environment. So while I do not suggest that we immediately drop the alpha designation I would seriously ask what remains to be done to get rid of it. I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number. I wonder if people think CodeWeaver's Wine is THAT much of a different product than WineHQ's Wine.. I think that for mass appeal branding works better. These products are worth the money to the end user and provide a way for them to contribute to wine development. For those users that are willing and able to contribute to the project I welcome them. However most users will simply want it to work and for them the best way is to use one of these products. Just another perspective, I'll be quiet now :) Oh, and www.winehq.com seems to be down (can't connect from RoadRunner or Savvis networks) I also cannot connect. Tony Lambregts
Re: PATCH: ppc fix 2
On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: Hi, Just a bad macro. ciao, marcus Changelog: Fixed LITTLE_ENDIAN_32_READ macro to at least compile. Index: ndr_marshall.c === RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v retrieving revision 1.9 diff -u -r1.9 ndr_marshall.c --- ndr_marshall.c29 Oct 2002 23:07:33 - 1.9 +++ ndr_marshall.c30 Oct 2002 13:21:15 - -59,8 +59,8 #define LITTLE_ENDIAN_32_READ(pchar) \ (MAKELONG( \ - MAKEWORD(*(pchar), *((pchar)+1)) \ - MAKEWORD(*((pchar)+2), *((pchar)+3))) + MAKEWORD(*(pchar), *((pchar)+1)), \ + MAKEWORD(*((pchar)+2), *((pchar)+3 #endif /* oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us? -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: Versions mass-appeal
Ender wrote: - No developers, because of two other issues: Don't forget our friend, the Win32 API. Most people with an incentive to work on Wine are familiar with C, POSIX, etc. The first time they look at Win32 code, the get a splitting headache and decide it's not worth it. People who think that the Win32 API is a thing of beauty (I suppose there must be some) tend to use Windows. -- Ian Pilcher [EMAIL PROTECTED]
Re: PATCH: ppc fix 2
On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: Hi, Just a bad macro. ciao, marcus Changelog: Fixed LITTLE_ENDIAN_32_READ macro to at least compile. Index: ndr_marshall.c === RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v retrieving revision 1.9 diff -u -r1.9 ndr_marshall.c --- ndr_marshall.c29 Oct 2002 23:07:33 - 1.9 +++ ndr_marshall.c30 Oct 2002 13:21:15 - -59,8 +59,8 #define LITTLE_ENDIAN_32_READ(pchar) \ (MAKELONG( \ - MAKEWORD(*(pchar), *((pchar)+1)) \ - MAKEWORD(*((pchar)+2), *((pchar)+3))) + MAKEWORD(*(pchar), *((pchar)+1)), \ + MAKEWORD(*((pchar)+2), *((pchar)+3 #endif /* oh, it's non-i386 only, and I guess I never tested this one... makes sense now, ignore my previous comment. -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: Versions mass-appeal
Ian == Ian Pilcher [EMAIL PROTECTED] writes: Ian Ender wrote: - No developers, because of two other issues: Ian Don't forget our friend, the Win32 API. Most people with an Ian incentive to work on Wine are familiar with C, POSIX, etc. The Ian first time they look at Win32 code, the get a splitting headache Ian and decide it's not worth it. People who think that the Win32 API Ian is a thing of beauty (I suppose there must be some) tend to use Ian Windows. Well, think of Win32 as a user library, just like Motif or QT. So the thing of beauty ( or missing beauty) gets relative... Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Versions mass-appeal
On October 30, 2002 08:56 am, Andreas Mohr wrote: Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM. Andy, this is just crap, and it's the type of crap that we should not perpetuate. There are tons of reasons why this _never_ happens, and you know them. So let's not propagate this type of misinformation that we have already too much out there, and which hurts us undoubtedly. -- Dimi.
Re: Versions mass-appeal
On Wed, 2002-10-30 at 07:56, Andreas Mohr wrote: On Wed, Oct 30, 2002 at 07:08:08AM -0600, Rick Romero wrote: I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, Wine is ALPHA software sticks in my head. People know what beta software is, and when someone see's Alpha, they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because Alpha is seen as horribly broken. I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number. Well, but I'd still insist that Wine IS Alpha software. After all we've got about 15000 Windows functions, and of course we only implement about 4000 to 5000, and of those that we do support, a ridiculously small number is entirely bug-free. But how many apps use 15000 Windows functions? I think it's closer to Beta than Alpha. Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM. The same could be said for anyone opening an email. We all saw the article on the Kmail/Wine user. I don't think it's a good idea to put that info out in the world. Any application can trash your system, to specifically say it can happen with Wine just targets Wine as a poor program. Hence, less users. At some point Wine/Linux needs to break out of the tech community, it's not going to happen if all technically possible 'bad things' are presented right out front. Sometimes you gotta keep your mouth shut :) (Believe me, I have a hard time doing that myself.) Wine is *not* a standard boring John Doe program, it's got a massively more difficult way to reach final stability. I think Wine is about where OS/2's Win16 support was. There were a lot of apps that worked, and a lot that didn't. And yes, OS/2's Win16 would take out the rest of OS/2 too. With an ordinary program, every little sub-version can easily be implemented to reach utter stability within its sometimes totally negligible goals. Not to mention that with a standard program, *you* define (and *know* !) what this program is supposed to do and how, whereas with Wine... you know the story ;-) I thought each API was a little sub-version :P Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 [EMAIL PROTECTED]
Re: PATCH: ppc fix 2
On Wed, Oct 30, 2002 at 07:56:10AM -0600, Greg Turner wrote: On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: Hi, Just a bad macro. ciao, marcus Changelog: Fixed LITTLE_ENDIAN_32_READ macro to at least compile. Index: ndr_marshall.c === RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v retrieving revision 1.9 diff -u -r1.9 ndr_marshall.c --- ndr_marshall.c 29 Oct 2002 23:07:33 - 1.9 +++ ndr_marshall.c 30 Oct 2002 13:21:15 - -59,8 +59,8 #define LITTLE_ENDIAN_32_READ(pchar) \ (MAKELONG( \ - MAKEWORD(*(pchar), *((pchar)+1)) \ - MAKEWORD(*((pchar)+2), *((pchar)+3))) + MAKEWORD(*(pchar), *((pchar)+1)), \ + MAKEWORD(*((pchar)+2), *((pchar)+3 #endif /* oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us? No, if you look at the define, it is not processed on i386 (protected by ifdef). Ciao, Marcus
Re: Versions mass-appeal
On Wed, Oct 30, 2002 at 10:00:08AM -0400, Dimitrie O. Paun wrote: On October 30, 2002 08:56 am, Andreas Mohr wrote: Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM. Andy, this is just crap, and it's the type of crap that we should not perpetuate. There are tons of reasons why this _never_ happens, and you know them. So let's not propagate this type of misinformation that we have already too much out there, and which hurts us undoubtedly. Never ? Never is never a perfectly fitting word... I for one *have* heard in some admittedly rather *rare* cases of data corruption due to Wine (something like deleting the parent directory instead of the program directory due to skipping one level in directory hierarchy in some function due to a problem). -- oops, whole Wine drive content gone (in a worst-case scenario). (also, there's that well-known Explorer renaming issue, which is *not* a Wine problem but happens on Wine due to braindead Microsoft programming) Crap is also a rather bold word (which admittedly I also use quite often - shame on me :). I'd say almost all of my text was based on facts that may happen sometimes, thus it could hardly be called crap. I don't want to spread the perception that Wine is unsafe - in by far almost all cases it's definitely not. But people should keep in mind that for every new program that they install, there might still be a bug lurking in some rarely used function that this program uses, which could in some cases cause some... err... problems with data. But most well-known programs have been tested quite a lot already, so the chance something like that happens with a well-known program is pretty slim to none, of course. And given that even W2K or XP have strange filesystem problems when used with an excessive amount of files sometimes, this leads me to believe that Wine isn't that bad after all... After all: Software == Heap o' Bugs :) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Versions mass-appeal
On October 30, 2002 09:20 am, Andreas Mohr wrote: I don't want to spread the perception that Wine is unsafe - in by far almost all cases it's definitely not. But people should keep in mind that for every new program that they install, there might still be a bug lurking in some rarely used function that this program uses, which could in some cases cause some... err... problems with data. But this is tautology. Wine is no different from any other program. We had SourceSafe corrupt the entire company reporsiotry (before I installed CVS) multiple times, and people use it. And believe me, it's MUCH worse than Wine in corrupting your data. Single out Wine, and saying it can ANYDAY, ANYTIME corrupt your DATA is (1) untrue, as a practical matter, (2) helps no one, hurts us badly. Why say this in a public forum, so clueless Slashdoters can read, and link to it? -- Dimi.
Re: Versions mass-appeal
- No users, because of two things: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed! wierd, I basically never have theese problems, even in cases where the AppDB says it's an issue... what apps need this right now? One example is the Australian E-Tax program mentioned recently - it'll hang on the splashscreen when no Desktop window exists (download: http://www.enderboi.com/misc/etax2002_1.exe) Another example is setup programs for things like Internet Explorer, Microsoft Visual Studio. They'll crash out or just generally not work if various programs (_INSxxx._MP for example) are not set to use Desktop. I believe the QuickTimeInstaller suffers from the same problem, as well as several other bits of software I've tried using recently.. - James 'Ender' Brown Project Leader: http://www.scummvm.org/ Site Founder:http://www.quakesrc.org/ Lead Programmer: http://www.collectivedetective.org/
EMF bug
Hi! I am not sure if this is a bug, or I did something wrong. My collegaues made a little program what shows the bug. It shows an EMF file, but the text boxes appears bad. Two screenshots and the source are included in the tar.gz. Please somebody examine it, and help me if you can. The source, binaries, and screenshots can be downloaded from ftp://ftp.uhulinux.hu/misc/testprg.tar.gz. It needs to be exctracted to the wine c:\ directory Thanks for your help in advance! If needed I can send you wine debug msgs. -- doome
Re: Versions mass-appeal
Andreas Mohr wrote: On Wed, Oct 30, 2002 at 12:21:51PM +0200, Shachar Shemesh wrote: Ender wrote: - Getting the right set of dlloverrides and registry entries correct for a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed. I'm willing to tackle that (the BiDi stuff is only slowly going, and there may be some unexpected development coming that is outside my hands, so I have SOME free resources available). Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it? I've been having a finished implementation of wineboot in my tree for ages. I guess it's about time to get it submitted... I downloaded it once (you did the fatal mistake of mentioning it in one of your emails, and went and searched the archives for it). I couldn't get it to work, though, and I did not delve deep enough. If you have it, please submit it. I'm willing to take ownership of it if you don't want to. - When are the boot time activities taking place? On wine start? On wineserver start? Good question. I guess we once agreed on it being done on winelauncher script startup. Not familiar enough - is that the first startup of wine? (or alternatively really on user desktop login, but I'm not sure whether this is what we want) No, that would require nasty stuff we really don't want. winelauncher should probably check whether any of the places that register reboot activities need processing, and if this is the case, then first finish a wineboot process, *then* start regular wine apps. That's the way Windows does that for SOME of the stuff (most noteably - wininit.ini). Also, NT does it differently (register in the registry etc.). I used to know all that stuff off the top of my head (I did the GTFormat system that installed all of Packard Bell's machines, and I believe still installs all of NEC's - moved on myself) (before mentioning that PB's systems were no good - that was before GTFormat was introduced). All this would have to be resistant against race conditions, of course :-\ - When are login time activities taking place? - How should a reboot request be treated? Should it be an indication that all these operations should start now, and let other wine programs carry on as usual? IMO we need to make sure we only do this when no other wine process is running. Either that, or start sending WM_QUERYENDSESSIONs, the way the original does. Optionally there could be some way to tell Wine to do it immediately, even during a session, though. Sounds like nobody ever watched the wineconf2002 streams, since nobody ever knows about wineboot... I didn't watch the stream. I'm also having some hand problems as well (though am taking care of them, so far rather succesfully - Dimi, call me if you want some tips... ). Shachar
Re: RPC test code?
On Wednesday 30 October 2002 07:21 am, Greg Turner wrote: On Monday 28 October 2002 04:56 am, Jürgen Schmied wrote: 2a) Should the rpc.c real test be the client or the server? I can imagine races either way. Let's say rpc.c is the client. Why not let one process start both (client and server). This process could control both and kill them later... ... or have one executable which can act as supervisor, client or server depending on a command line switch. If started without a switch act as supervisor and start itself again twice with different switches... juergen --- [EMAIL PROTECTED] this is also a possibility, but doesn't this create the need for even more IPC? the big open issue is: how do the test results get back to the actual test program? obviously there are many ways to do it; but doesn't separating things like this just make it harder? Actually, I was leaning towards the idea of having the test program itself be both client and server... but AFAIK there is no wine-compatible way to fork()..? -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: EMF bug
Hi, We've done alot of work on EMF files in the Crossover tree. Specifically, if an EMF used SetWindowExtEx and SetViewportExtEx, it was busted. That work will be merged into WineHQ in the near future. Hopefully that will solve the problem. Mike doome wrote: Hi! I am not sure if this is a bug, or I did something wrong. My collegaues made a little program what shows the bug. It shows an EMF file, but the text boxes appears bad. Two screenshots and the source are included in the tar.gz. Please somebody examine it, and help me if you can. The source, binaries, and screenshots can be downloaded from ftp://ftp.uhulinux.hu/misc/testprg.tar.gz. It needs to be exctracted to the wine c:\ directory Thanks for your help in advance! If needed I can send you wine debug msgs.
EMF bug?
Hi! I am not sure if this is a bug, or I did something wrong. My collegaues made a little program what shows the bug. It shows an EMF file, but the text boxes appears bad. Two screenshots and the source are included in the tar.gz. Please somebody examine it, and help me if you can. The source, binaries, and screenshots can be downloaded from ftp://ftp.uhulinux.hu/misc/testprg.tar.gz. It needs to be exctracted to the wine c:\ directory Thanks for your help in advance! If needed I can send you wine debug msgs. -- doome ___ wine-users mailing list [EMAIL PROTECTED] http://www.winehq.com/mailman/listinfo/wine-users -- Dömsödi Gergely UHU-Linux Csapat
Re: PATCH: ppc fix 2
On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: Fixed LITTLE_ENDIAN_32_READ macro to at least compile. btw, this seems to imply that even with the parentheses fix, it's still not right... is that the case? You seem like somebody who's up on PPC issues. Note that this is only intended to support UINT32's (I'll make that clearer by changing the macro names in an upcoming patch). There is another issue with the DataRepresentation stuff that I didn't think of until this morning. NDR allows several different modes in terms of endianness, float representation, signed int representation, etc. MS takes advantage of this by having different native data representations, based on the platform. Looking at the Platform SDK rpcndr.h, for example, PPC gets big-endian, i386 gets little-endian. Then, it seems, they implement their marshall/unmarshall code in terms of these native representations. I'm deducing this from the MIDL-generated stub code; that code compares the DataRepresentation coming off the wire to the native DataRepresentation; if there's a mismatch, it converts before calling the unmarshall code (currently the conversion functions are unimplemented in wine). What this all means, I think, is that my implementation is wrong for non-i386 platforms. I was hard-coding the native data representation to little-endian (the i386 way). This will work for i386, but for other platforms, it will break against precompiled binaries, because the assumed native data representation is compiled right in to the executable via #define's. To fix, I think I need to have per-platform native DataRepresentations like microsoft, and change the marshall/unmarshall code to use it. Anyhow, just thinking aloud there, and, I guess, hoping that if I'm getting this all wrong, someone will correct me. My original question is the main one: are the semantics of my macro's wrong, or just the parentheses thing? -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: What is a leap second
Hello!
I compiled the following using msvc:
--8---
#include stdio.h
#include windows.h
typedef short CSHORT;
typedef struct {
CSHORT Year;
CSHORT Month;
CSHORT Day;
CSHORT Hour;
CSHORT Minute;
CSHORT Second;
CSHORT Milliseconds;
CSHORT Weekday;
} TIME_FIELDS, *PTIME_FIELDS;
typedef VOID (*RtlTimeToTimeFieldsT)
(PLARGE_INTEGER Time, PTIME_FIELDS TimeFields);
int
main()
{
LARGE_INTEGER RtlTime;
TIME_FIELDS tf;
HINSTANCE hLib;
RtlTimeToTimeFieldsT RtlTimeToTimeFields;
RtlTime.LowPart = 0x20de5700;
RtlTime.HighPart = 0x1c27d90;
hLib = LoadLibrary(ntdll);
RtlTimeToTimeFields =
(RtlTimeToTimeFieldsT)GetProcAddress
(hLib,
RtlTimeToTimeFields);
RtlTimeToTimeFields(RtlTime, tf);
FreeLibrary(hLib);
printf(%d %d %d %d %d %d\n,
tf.Year, tf.Month, tf.Day,
tf.Hour, tf.Minute, tf.Second);
return 0;
}
--8---
with the following output on win2k.
9 0 10 0 9 10
Re: RPC test code?
Am Mit, 2002-10-30 um 16.43 schrieb Greg Turner: Actually, I was leaning towards the idea of having the test program itself be both client and server... but AFAIK there is no wine-compatible way to fork()..? Why don't you just use CreateThread()? I am doing this for the winsock tests and it works just fine. You can use thread-local storage to keep variables separate. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
GetComputerName() question
Why is GetComputerName() an init function, or in other words, why is it important that HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\ComputerName\\ComputerName be set at registry initialization time (in _allocate_default_keys())? I am asking because GetComputerName() IMO returns the wrong value (FQDN rather than NETBIOS name). A real implementation of GetComputerName() would look for the above value in the Registry and use gethostname() only as a fallback, but currently it's the other way around - why ? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RPC test code?
On Wednesday 30 October 2002 11:00 am, Martin Wilck wrote: Am Mit, 2002-10-30 um 16.43 schrieb Greg Turner: Actually, I was leaning towards the idea of having the test program itself be both client and server... but AFAIK there is no wine-compatible way to fork()..? Why don't you just use CreateThread()? I am doing this for the winsock tests and it works just fine. You can use thread-local storage to keep variables separate. Martin I need to cross a process boundary. There is per-process storage in rpcrt4 that I don't want shared during my tests. Single-process RPC's are worthy of their own test, however; I probably ought to test both possibilities. BTW, this is somewhat off-topic, but sometimes the winsock test hangs for me after make testclean; ctrl-c and re-running make test always works, so I wonder if perhaps there is a race condition tickled by the make processing? Next time (if there is one) that I encounter this, I'll attach a debugger and tell you what I see. -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
SetWindowHookEx
My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it won't work right. Any hints/suggestions? -Steve
listview: last column problem
Dimitri, The missing last column in newsbin seems to be caused by this line: | if (!lpColumn || nColumn 0 || nColumn infoPtr-hdpaColumns-nItemCount) |return -1; | ^ removing the marked part of the test result in a couple of error messages: | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 but otherwise runs fine. Do you see any objections removing the test and error message? Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: listview: last column problem
On October 30, 2002 02:01 pm, Rein Klazes wrote: Do you see any objections removing the test and error message? Good catch. Please try this patch: Index: dlls/comctl32/listview.c === RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.325 diff -u -r1.325 listview.c --- dlls/comctl32/listview.c28 Oct 2002 21:21:42 - 1.325 +++ dlls/comctl32/listview.c30 Oct 2002 19:19:35 - -6044,7 +6044,8 TRACE((nColumn=%d, lpColumn=%s, isW=%d)\n, nColumn, debuglvcolumn_t(lpColumn, isW), isW); -if (!lpColumn || nColumn 0 || nColumn infoPtr-hdpaColumns-nItemCount) return -1; +if (!lpColumn || nColumn 0) return -1; +nColumn = min(nColumn, infoPtr-hdpaColumns-nItemCount); ZeroMemory(hdi, sizeof(HDITEMW)); column_fill_hditem(infoPtr, hdi, nColumn, lpColumn, isW); -- Dimi.
Re: SetWindowHookEx
[EMAIL PROTECTED] writes: My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it won't work right. Any hints/suggestions? I'm working on it. Basically it won't work right across processes at this point; if you have a single process it should be OK. It's returning NULL for me, which implies it isn't working. Is there some sort of trace that I can send you to help you out? -Steve
Re: GetComputerName() question
Martin Wilck [EMAIL PROTECTED] writes: I am asking because GetComputerName() IMO returns the wrong value (FQDN rather than NETBIOS name). A real implementation of GetComputerName() would look for the above value in the Registry and use gethostname() only as a fallback, but currently it's the other way around - why ? Because users are not going to edit the registry if their Unix hostname changes so it will always be wrong. Now if the problem is the FQDN then it should be trivial to truncate it to just the hostname. -- Alexandre Julliard [EMAIL PROTECTED]
Re: listview: last column problem
On Wed, 30 Oct 2002 14:21:13 -0500, you wrote: On October 30, 2002 02:01 pm, Rein Klazes wrote: Do you see any objections removing the test and error message? Good catch. Please try this patch: Index: dlls/comctl32/listview.c === RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.325 diff -u -r1.325 listview.c --- dlls/comctl32/listview.c 28 Oct 2002 21:21:42 - 1.325 +++ dlls/comctl32/listview.c 30 Oct 2002 19:19:35 - @@ -6044,7 +6044,8 @@ TRACE((nColumn=%d, lpColumn=%s, isW=%d)\n, nColumn, debuglvcolumn_t(lpColumn, isW), isW); -if (!lpColumn || nColumn 0 || nColumn infoPtr-hdpaColumns-nItemCount) return -1; +if (!lpColumn || nColumn 0) return -1; +nColumn = min(nColumn, infoPtr-hdpaColumns-nItemCount); ZeroMemory(hdi, sizeof(HDITEMW)); column_fill_hditem(infoPtr, hdi, nColumn, lpColumn, isW); Works fine. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: SetWindowHookEx
[EMAIL PROTECTED] writes: My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it won't work right. Any hints/suggestions? I'm working on it. Basically it won't work right across processes at this point; if you have a single process it should be OK. -- Alexandre Julliard [EMAIL PROTECTED]
Re: What is a leap second
with the following output on win2k.
9 0 10 0 9 10
This is weird, I would have expected to get an output like: 2002 10
27 8 9 10
with the followingo patch applied...
nog.
Eeek, sorry about that. I forgot a WINAPI in the typedef, see my new
version in the attachment...
The following output is more in line with your expectations:
2002 10 27 8 9 10
I have also attached the output of timetest2.c after some adjustments
to make it compile on my box which is missing winternl.h. (I didn't
take the time to download the SDK.)
However, I don't follow the part about appling patches. I have
compiled the code using msvc and executed the code on windows 2000.
/peda
#include stdio.h
#include windows.h
typedef short CSHORT;
typedef struct {
CSHORT Year;
CSHORT Month;
CSHORT Day;
CSHORT Hour;
CSHORT Minute;
CSHORT Second;
CSHORT Milliseconds;
CSHORT Weekday;
} TIME_FIELDS, *PTIME_FIELDS;
typedef VOID (WINAPI *RtlTimeToTimeFieldsT)
(PLARGE_INTEGER Time, PTIME_FIELDS TimeFields);
int
main()
{
LARGE_INTEGER RtlTime;
TIME_FIELDS tf;
HINSTANCE hLib;
RtlTimeToTimeFieldsT RtlTimeToTimeFields;
RtlTime.LowPart = 0x20de5700;
RtlTime.HighPart = 0x1c27d90;
hLib = LoadLibrary(ntdll);
RtlTimeToTimeFields = (RtlTimeToTimeFieldsT)
GetProcAddress(hLib, RtlTimeToTimeFields);
RtlTimeToTimeFields(RtlTime, tf);
FreeLibrary(hLib);
printf(%d %d %d %d %d %d\n,
tf.Year, tf.Month, tf.Day,
tf.Hour, tf.Minute, tf.Second);
return 0;
}
#include stdio.h
#include windows.h
typedef short CSHORT;
typedef struct {
CSHORT Year;
CSHORT Month;
CSHORT Day;
CSHORT Hour;
CSHORT Minute;
CSHORT Second;
CSHORT Milliseconds;
CSHORT Weekday;
} TIME_FIELDS, *PTIME_FIELDS;
typedef VOID (WINAPI *RtlTimeToTimeFieldsT)(PLARGE_INTEGER Time, PTIME_FIELDS TimeFields);
#define testtime(HighTime, LowTime) \
RtlTime.HighPart = HighTime; \
RtlTime.LowPart = LowTime; \
RtlTimeToTimeFields(RtlTime, tf); \
printf(%04d %02d %02d %02d %02d %02d\n, tf.Year, tf.Month, tf.Day,\
tf.Hour, tf.Minute, tf.Second);
/* The year to which to test */
#define TargetYear
/* Taken from dlls/ntdll/time.c */
#define EPOCHYEAR 1601
#define TICKSPERSEC1000
#define SECSPERDAY 86400
#define MONSPERYEAR12
static const int MonthLengths[2][MONSPERYEAR] =
{
{ 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
};
int IsLeapYear(int Year)
{
return Year % 4 == 0 (Year % 100 != 0 || Year % 400 == 0) ? 1 : 0;
}
int
main()
{
int Month, Year;
UINT64 time = 0, tmp;
LARGE_INTEGER RtlTime;
TIME_FIELDS tf;
HINSTANCE hLib;
RtlTimeToTimeFieldsT RtlTimeToTimeFields;
hLib = LoadLibrary(ntdll);
RtlTimeToTimeFields =
(RtlTimeToTimeFieldsT)GetProcAddress
(hLib, RtlTimeToTimeFields);
for(Year = 0; Year = (TargetYear - EPOCHYEAR); Year++) {
for(Month = 0; Month MONSPERYEAR; Month++) {
tmp = MonthLengths[IsLeapYear(Year + EPOCHYEAR)][Month] * SECSPERDAY;
tmp *= TICKSPERSEC;
time += tmp;
testtime(time 32, (time 0x));
}
}
FreeLibrary(hLib);
return 0;
}
timetest2.zip
Description: Zip archive
Re: SetWindowHookEx
[EMAIL PROTECTED] writes:
It's returning NULL for me, which implies it isn't working. Is there some
sort of trace that I can send you to help you out?
Oops you are right, this should fix it:
Index: server/hook.c
===
RCS file: /opt/cvs-commit/wine/server/hook.c,v
retrieving revision 1.1
diff -u -r1.1 hook.c
--- server/hook.c 29 Oct 2002 00:41:42 - 1.1
+++ server/hook.c 30 Oct 2002 19:51:20 -
@@ -227,7 +227,8 @@
set_error( STATUS_INVALID_PARAMETER );
return;
}
-if (!(thread = get_thread_from_id( req-tid ))) return;
+if (!req-tid) thread = (struct thread *)grab_object( current );
+else if (!(thread = get_thread_from_id( req-tid ))) return;
if ((hook = add_hook( thread, req-id - WH_MINHOOK )))
{
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Treeview Notifications Fix (update)
On October 30, 2002 03:34 pm, Dustin Navea wrote: Well after some more debugging, I think that it is a problem with the SendMessageA function itself, not with any of the arguments being passed to it. I think you are chasing the wrong problem... -- Dimi.
XBox
Could someone do something to make the need for this hardware disappear and save the world of people who love proprietrary video game consoles? There is already a tool that converts xpe files into exe. Only the bios and the improved DirectX must be re-engineered and the rest will be done by a Geforce4 (or 5) and a 2Ghz CPU.
Treeview Notifications Fix (update)
--- Dustin Navea [EMAIL PROTECTED] wrote: Hey everyone, after about 3 hours of adding traces to treeview.c, I have found the line that is causing all of my headaches! in /wine/dlls/comctl32/treeview.c: in function TREEVIEW_NOTIFYFORMAT i = SendMessageA(GetParent (infoPtr-hwnd), WM_NOTIFYFORMAT, (WPARAM)infoPtr-hwnd, NF_QUERY); SendMessageA is returning 2 (NFR_UNICODE) on the StarCraft installer window. This is incorrect, the return should be 1 (NFR_ANSI). I don't know of any way to get it to return 1 myself as I dont know windows API, so I am asking for some help. can anyone that has some free time and knows the WM subsystem help me out? Please add yourself to CC on bug 1073. Well after some more debugging, I think that it is a problem with the SendMessageA function itself, not with any of the arguments being passed to it. SendMessage is too complex for my knowledge, so I will definitely need some help here... -Dustin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: splitting msvideo/msvfw32
Eric Pouech [EMAIL PROTECTED] writes:
+case DLL_PROCESS_ATTACH:
+if (!GetModuleHandleA(MSVFW32.DLL) !LoadLibraryA(MSVFW32.DLL))
+{
+ERR(Could not load sibling MSVfW32.dll\n);
+return FALSE;
+}
Note that this is not necessary. The 32-bit dll is always loaded
before the 16-bit one (otherwise we couldn't reference symbols in
it).
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: rpc_H_PL1
Greg Turner [EMAIL PROTECTED] writes:
diff -ur -x CVS -x 'bigdif*' ../wine.test/dlls/rpcrt4/rpc_binding.c
./dlls/rpcrt4/rpc_binding.c
--- ../wine.test/dlls/rpcrt4/rpc_binding.c2002-10-29 12:59:02.0 -0600
+++ ./dlls/rpcrt4/rpc_binding.c 2002-10-29 13:28:39.0 -0600
@@ -865,14 +865,21 @@
* Exists in win9x and winNT, but with different number of arguments
* (9x version has 3 arguments, NT has 2).
*/
+#ifdef WINNT
+RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE Binding, RPC_BLOCKING_FN
BlockingFn)
+#else
RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE Binding, RPC_BLOCKING_FN
BlockingFn, unsigned long ServerTid )
+#endif
{
This can't work, we are not going to build two versions of Wine with
different #ifdefs. We should simply decide which version we support
(NT would probably be preferable) and get rid of the #ifdefs in the
header.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Versions mass-appeal
On Wed, 30 Oct 2002, Keith Matthews wrote:
[...]
Stressing the number of calls in the MS API is another important point
to make, thanks to Andreas for providing an updated figure.
For more API stats you can check out the following page (and
disclaimer):
http://fgouget.free.fr/wine/winapi_stats-en.shtml
While I'm writing I will just mention some other links relevant to the
'Wine perception' aspect:
* Contributing to Wine
Trying to present ways to get started helping Wine. More work is
needed on this section and it needs to be made much more visible.
http://www.winehq.com/about/index.php?contrib
* Why Wine is so important
Many people have a primitive 'say no to Windows software' attitude
because they do not understand why Wine is important.
http://www.winehq.com/about/index.php?why
* Debunking Wine Myths
These myths are quite common and detract to Wine's image
http://www.winehq.com/about/index.php?myths
Here's my thoughts on getting more developpers:
* I think step one is fixing Wine's perception issues by improving the
Web site to make the above more visible, add screenshots and make it
easier to navigate.
* Step two is to add more resources geared towards new developpers to
make it easier for them to get started (e.g. taslets bug list, finish
the conformance testing guide, update the developer's guide, etc.).
* Step three is to be more outgoing. Do a better job at describing the
tasks that need to be done for instance. Let people know that we need
help, that with done much with less than one tenth the number of
developpers that the Linux kernel has. Someone suggested making Wine
presentations at local LUGs. I think that's a goog idea too.
I have done some work on the above items (all committed) but I'm not a
technical writer so it takes me a lot of time to write documentation and
I'm rarely happy with the result. And free time is in very short supply
currently. Plus I'm not familiar with PHP which would be required for
some of the Web site changes (again a time issue). So please, if anyone
feels like updating the web site or writing documentation, go ahead.
Wine needs you!
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
$live{free} || die ;
Re: Versions mass-appeal
On October 30, 2002 01:57 am, Ender wrote: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed! IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option. - Getting the right set of dlloverrides and registry entries correct for a large portion of software is irritating. [snip] We should aim at delivering a 0.8/0.9/1.0 that does not require native DLLs to run apps. And so, there should be no need for dlloverrides... - The amount of cross-dependency in WINE code makes it very hard for a newbie developer to try and debug a problem in an application he uses. This also means that to trace most of this inter-dependency you need to debug so many parts that the amount if debug info becomes pretty difficult to work with. So to begin with, you need a good idea of WINEs internal structure and DLL cross-calling before you even start to play with it. That is true, but we're much better than 5 years ago. MUCH, MUCH BETTER. The DLL separation, and sticking t Win32 API have simplified Wine programming enormously, to the point where most Windows programmers can help on Wine right off the bat. The project is huge, what do you expect? :) -- Dimi.
Re: Versions mass-appeal
On October 30, 2002 04:50 pm, Lionel Ulmer wrote: I wholeheartedly disagree here.. I only use (and only ever will) use Desktop mode in Wine. It's the same (for me) as using Tabbed browsing in Mozilla : you have all the related mess in one window :-) Sorry Lionel, but You Are Wrong (tm)! :) By your rationale, all KDE apps should start up their own desktop, all GTK apps another desktop, and so on. This way lies madness. An app, is an app, is an app. I don't give a flying !#$ if it's a Qt, Gtk, Python, Perl, Java, Wine, wxWindows, you-name-it app. I don't want every toolkit, library, etc. to invent their own universe with their own little desktop. It would be crazy. You feel the need to group apps to cleanup your workspace: fine, instruct your WM to do it! This does not belong in the toolkit! -- Dimi.
No more Office 11 for Win98/ME
Hallo, e.g. on www.heise.de there is the news that MS announces to drop support for Win98/ME for the next office version. That's probably a point in time when many people will look for alternatives. Hopefully Wine and Linux are in good shape then. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Versions mass-appeal
IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option. I wholeheartedly disagree here.. I only use (and only ever will) use Desktop mode in Wine. It's the same (for me) as using Tabbed browsing in Mozilla : you have all the related mess in one window :-) I agree that it seems to be a hack for now because of the one application = one desktop window 'feature' but well, Alexandre promised this to be fixed for 1.1 :-)) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Versions mass-appeal
On Wed, 30 Oct 2002, Dimitrie O. Paun wrote: On October 30, 2002 01:57 am, Ender wrote: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed! IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option. I think desktop mode is useful in some circumstances like when you want to prevent an application from taking over the whole screen (typically installers or the PowerPoint viewer). Unfortunately it is currently broken in that if a process runs in a desktop and calls CreateProcess, the new process is run in a new desktop. That's really not the way it should work. But I would rather see this fixed than scrap desktop mode entirely. Of course desktop mode is much less important than good behavior in managed mode. But getting managed mode to work really well will require some cooperation from the window manager which means we need the people who understand the issue to contribute to the window manager standards. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Utilisateur (nom commun) : Mot utilisé par les informaticiens en lieu et place d'idiot.
Re: Versions mass-appeal
Dimitrie == Dimitrie O Paun [EMAIL PROTECTED] writes: Dimitrie On October 30, 2002 01:57 am, Ender wrote: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed! Dimitrie IMO desktop mode exists only because our integration is not Dimitrie very good. It should die sooner, rather than later, it's just Dimitrie a big hack. So we should rather focus on getting apps to work Dimitrie in non-desktop more, rather then resurrecting the silly Dimitrie desktop option. Well, my opinion on desktop mode is another one. It's not silly. Two examples: - any program in non-desktop mode switching to full screen (hey, a lot of programs like installer do that) and crashing later without a proper setup of the debugger. No most users are left in a situation they can't easily solve, as they don't know that they still can switch consoles and kill wine... - any application poping up endless series of new processes, each process grabbing keyboard focus. In a good desktop mode I would expect the real focus not to switch from the outside to the desktop. As now each process spawns it's own new desktop, focus is switched anyways. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Versions mass-appeal
That I understand. But still the fucntionallity does not belong in Wine. You should start a new desktop environment around Wine (say WDE), just like Qt, and GTK have their own DEs. Well, yes, if I wanted to ONLY use Windows applications I could do something like that. But a part from using Xnest or hacks like that (VNC comes to my mind too) I do not see how I could do what I want to do without support in Wine itself. And well, what exactly is your problem with Desktop ? That it complexifies Wine too much ? From what I know from the code, it does not add that much complexity. I would even agree from removing it from the docs / man pages if it pleases you as long as it is kept in the code :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Versions mass-appeal
An app, is an app, is an app. I don't give a flying !#$ if it's a Qt, Gtk, Python, Perl, Java, Wine, wxWindows, you-name-it app. I don't want every toolkit, library, etc. to invent their own universe with their own little desktop. It would be crazy. You feel the need to group apps to cleanup your workspace: fine, instruct your WM to do it! This does not belong in the toolkit! Well, you and I seem to have very different opinion on Wine. For you, it's a way to run a particular application. For me, it's like a virtual PC running Windows on my Linux box (ie more like a VMWare or a terminal server / Metaframe approach). For me, running 'explorer' (or whatever is called the Windows WM) in a desktopped Windows session and actually have the 'Start' button in the lower right corner of the window to start Windows applications would be the way I would prefer running Wine. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Versions mass-appeal
On October 30, 2002 05:12 pm, Lionel Ulmer wrote: For me, running 'explorer' (or whatever is called the Windows WM) in a desktopped Windows session and actually have the 'Start' button in the lower right corner of the window to start Windows applications would be the way I would prefer running Wine. That I understand. But still the fucntionallity does not belong in Wine. You should start a new desktop environment around Wine (say WDE), just like Qt, and GTK have their own DEs. -- Dimi.
Re: Versions mass-appeal
On October 30, 2002 05:05 pm, Uwe Bonnes wrote: - any program in non-desktop mode switching to full screen - any application poping up endless series of new processes This focuses on the wrong problem. A Wine app is just that: an app. If this is a problem, the WM must allow you to deal with them. You solve this way a general problem in an elegant way, not only a Wine-specific hack. -- Dimi.
Re: Versions mass-appeal
On October 30, 2002 05:01 pm, Francois Gouget wrote: I think desktop mode is useful in some circumstances like when you want to prevent an application from taking over the whole screen (typically installers or the PowerPoint viewer). While it may be useful in strange circumstances, it's not the right thing to do. How would you invoke it? What about other non-Wine apps that are taking over the screen? Should they have a desktop mode? And if we go down this path, what next: use ptrace to enhance Wine's security?!? -- Dimi.
Is it me or is winedbg --debugmsg -all not honored
Hallo, did I miss something or is it me or is the registry entry ( as advertised in winedefaults.reg) [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug] Debugger=winedbg --debugmsg -all %ld %ld not honored any more ( since some time). The relay log is cluttered with about 150k lines of debugger start relay output :-( Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Versions mass-appeal
On October 30, 2002 05:27 pm, Lionel Ulmer wrote: Well, yes, if I wanted to ONLY use Windows applications I could do something like that. But a part from using Xnest or hacks like that (VNC comes to my mind too) I do not see how I could do what I want to do without support in Wine itself. So you consider Xnest and VNC hacks, but Wine's desktop mode OK?!? This is very strange, in the Unix spirit I would have thought those are the right approach for what you want to accomplish (pseudo-virtual machine). -- Dimi. P.S. And no, there is no reason for WDE to be restricted to Windows apps only.
Re: rpc_H_PL1
On Wednesday 30 October 2002 03:01 pm, Alexandre Julliard wrote:
Greg Turner [EMAIL PROTECTED] writes:
diff -ur -x CVS -x 'bigdif*' ../wine.test/dlls/rpcrt4/rpc_binding.c
./dlls/rpcrt4/rpc_binding.c ---
../wine.test/dlls/rpcrt4/rpc_binding.c 2002-10-29
12:59:02.0 -0600 +++ ./dlls/rpcrt4/rpc_binding.c2002-10-29
13:28:39.0 -0600 @@ -865,14 +865,21 @@
* Exists in win9x and winNT, but with different number of
arguments * (9x version has 3 arguments, NT has 2).
*/
+#ifdef WINNT
+RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE
Binding, RPC_BLOCKING_FN BlockingFn) +#else
RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE
Binding, RPC_BLOCKING_FN BlockingFn, unsigned long ServerTid )
+#endif
{
This can't work, we are not going to build two versions of Wine with
different #ifdefs. We should simply decide which version we support
(NT would probably be preferable) and get rid of the #ifdefs in the
header.
OK, will do... I love that MS just creates new, similar API's with the
same names as the old ones... for a company that apparently loves
backward compatibility more than stability, what are they thinking?
--
gmt
The purpose of government is to rein in the rights of the people
--President Bill Clinton, MTV interview, 1993
Re: Versions mass-appeal
On Wed, Oct 30, 2002 at 05:27:48PM -0500, Dimitrie O. Paun wrote: On October 30, 2002 05:01 pm, Francois Gouget wrote: I think desktop mode is useful in some circumstances like when you want to prevent an application from taking over the whole screen (typically installers or the PowerPoint viewer). While it may be useful in strange circumstances, it's not the right thing to do. How would you invoke it? What about other non-Wine apps that are taking over the screen? Should they have a desktop mode? And if we go down this path, what next: use ptrace to enhance Wine's security?!? Since apps going 'full screen' is much more common in W$ than unix, maybe wine should have an option to lie about the screen size? That way an app that requests 'full screen' (probably in order to get 800x600 pixels) won't grab the entire 1600x1200 (or larger) X display. David -- David Laight: [EMAIL PROTECTED]
Re: Versions mass-appeal
So you consider Xnest and VNC hacks, but Wine's desktop mode OK?!? This is very strange, in the Unix spirit I would have thought those are the right approach for what you want to accomplish (pseudo-virtual machine). Well, I said 'hacks' because for VNC it's not really what it was meant to do (except, of course, if one would write a VNC-protocol driver for Wine to be able to connect directly to a VNC server). This is less true for Xnest, but it is relatively unacceptable for performance reasons (for one, you add yet another process that needs to be scheduled in the equation plus it certainly will never run OpenGL in direct rendering mode). Basically, you mean that you consider Tabbed browsing in Mozilla a 'hack' too because it should be your WM's job to do that for you ? P.S. And no, there is no reason for WDE to be restricted to Windows apps only. But I would want it to be. I do not want to change WM for my Linux applications, only for my Windows one. I do *NOT* want *ANY* integration between the Windows application run with Wine and my Linux applications (so I may be completely at odds with what CodeWeavers is trying to do, but oh well, I am used to have strange ideas :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Versions mass-appeal
Uwe Bonnes wrote: Dimitrie == Dimitrie O Paun [EMAIL PROTECTED] writes: Dimitrie On October 30, 2002 01:57 am, Ender wrote: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed! Dimitrie IMO desktop mode exists only because our integration is not Dimitrie very good. It should die sooner, rather than later, it's just Dimitrie a big hack. So we should rather focus on getting apps to work Dimitrie in non-desktop more, rather then resurrecting the silly Dimitrie desktop option. Well, my opinion on desktop mode is another one. It's not silly. Two examples: - any program in non-desktop mode switching to full screen (hey, a lot of programs like installer do that) and crashing later without a proper setup of the debugger. No most users are left in a situation they can't easily solve, as they don't know that they still can switch consoles and kill wine... - any application poping up endless series of new processes, each process grabbing keyboard focus. In a good desktop mode I would expect the real focus not to switch from the outside to the desktop. As now each process spawns it's own new desktop, focus is switched anyways. Yes desktop is broken but it is the best way that I have to debug programs. Without desktop a lot of programs want to take over the whole screen and although there may be other ways of debuging these programs this is the best way that I know of. It need to be fixed not gotten rid of. My 2 bits Tony Lambregts.
Re: Versions mass-appeal
On October 30, 2002 09:11 am, Uwe Bonnes wrote: think of Win32 as a user library, just like Motif or QT. So the thing of beauty ( or missing beauty) gets relative... Very good point. This is another angle I wanted to approach: we are currently perceived by some as a 'evil thing' which allows MS-stuff to creep into Linux. We should make it clear that Wine is: 1) a PE loader This is good! PE is a valid format, just like ELF. There are advantages to have it supported in Linux. 2) A (large) toolkit/lib/etc. There, we are in the same bucket as Lesstif, Qt, GTK, etc. We are a Unix thing as much as all the other cherished libs. -- Dimi.
Re: Is it me or is winedbg --debugmsg -all not honored
Uwe Bonnes [EMAIL PROTECTED] writes: did I miss something or is it me or is the registry entry ( as advertised in winedefaults.reg) [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug] Debugger=winedbg --debugmsg -all %ld %ld not honored any more ( since some time). The relay log is cluttered with about 150k lines of debugger start relay output :-( Works fine here. Note that the debugger does print a few things before it gets a chance to handle the -debugmsg option, but that definitely shouldn't be 150k lines. -- Alexandre Julliard [EMAIL PROTECTED]
Re: XBox
On Wed, 2002-10-30 at 12:10, Dirk wrote: Could someone do something to make the need for this hardware disappear and save the world of people who love proprietrary video game consoles? There is already a tool that converts xpe files into exe. Only the bios and the improved DirectX must be re-engineered and the rest will be done by a Geforce4 (or 5) and a 2Ghz CPU. I'm sure an Xbox emulator will eventually come along, assuming there aren't a few already in the works; they, however, under Linux at least, would have to implement DirectX calls; it would be interesting to frequently contact those developers as they would face many of the same issues of implementing DirectX as the newly formed Wine DX group will. I don't know of any emulators that support Xbox architecture, but I don't think wine should be the project to do so, not unless an Xbox game runs under (normal) Windows. -- Chris Thielen [EMAIL PROTECTED]
Debugging advice
Hi there; I feel like I'm nearly there with porting this game to run with winelib, a version checked out from winehq CVS about a week ago. Because I wanted my build system to be cross-platform, and WINE only as a stop-gap, I'm using the Jam build system and so can't directly take advantage of winemaker. Plus I would rather learn and document how the build process works manually, since I can't find this information anywhere else. Anyhow I now have the 400-odd source files compiling happily against my wine header files once I'd excised the need for Direct3D. I have a directory full of object files with external references to Win32 functions and a WinMain function. So to do the final linking step I've used (based on watching the example winemine build process): $WINE/tools/winebuild/winebuild \ -fPIC -DSTRICT -D_REENTRANT \ -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ -lwinmm -ldisplay -ldispdib Source/LSNClient.exe.c and then compiled linked LSNClient.exe.c to the rest of the object files with the -shared flag, which leaves me with a shared library. Sideline: am I correct in thinking that winebuild's job is to scan the supplied object files for Win32 dependencies and construct the necessary glue code to load the needed .dll.so files? What's the reason that the linking process can't correspond more closely to normal linking, i.e. where I could just supply -lddraw -lwine to my program to produce a final binary? I then run ../wine/wine LSNClient.exe to try to run the game, and get this error: err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found - 16-bit dll or version conflict. err:module:PE_fixup_imports Module (file) display.dll (which is needed by Y:\Work\Nemesis\LSNClient.exe) not found Any idea what might be going wrong, or how I could diagnose it? More generally, the natively compiled .exe runs okay (if grindingly slowly, and with a couple of display glitches) under the binary loader, but I assumed that if I could produce a native version I'd be avoiding a lot of overhead and make my debugging job easier since I could use familiar GNU tools to debug my portability code as I wrote it. What efficiency gains will I make compiling a native shared library exe with gcc as opposed to just compiling with Visual C and running it under the normal WINE binary loader? I'm interested in how the latter works efficiently, so any advice in this direction would be appreciated-- I've thought on more than one occasion that maybe I should skip the WINE stop-gap and port it to SDL all at once, but the idea of being able to gradually wean the game off Win32 is appealing. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
richedit
Hello, is somebody working on the richedit dll? I encountered 3 unknown RTF control words and wanted to add them but I got scared by the overzealous use of #define's in rtf.h . My first impuls was exchange that with some enum's, but i thought i better ask here before i do the work in vain. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg13131/pgp0.pgp Description: PGP signature
Re: Debugging advice
Matthew Bloch [EMAIL PROTECTED] writes: $WINE/tools/winebuild/winebuild \ -fPIC -DSTRICT -D_REENTRANT \ -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ -lwinmm -ldisplay -ldispdib Source/LSNClient.exe.c display and dispdib are 16-bit dlls, you shouldn't import them. Sideline: am I correct in thinking that winebuild's job is to scan the supplied object files for Win32 dependencies and construct the necessary glue code to load the needed .dll.so files? What's the reason that the linking process can't correspond more closely to normal linking, i.e. where I could just supply -lddraw -lwine to my program to produce a final binary? That's because of differences between the ELF and PE binary formats. For instance, each Windows dll is in its own namespace, while ELF dlls share a single namespace; so we need to do linker tricks to simulate the PE behavior. What efficiency gains will I make compiling a native shared library exe with gcc as opposed to just compiling with Visual C and running it under the normal WINE binary loader? There are basically no efficiency gains, there is no overhead in running a PE exe compared to a native one. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Debugging advice
On Thursday 31 October 2002 01:14, you wrote: Matthew Bloch [EMAIL PROTECTED] writes: $WINE/tools/winebuild/winebuild \ -fPIC -DSTRICT -D_REENTRANT \ -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ -lwinmm -ldisplay -ldispdib Source/LSNClient.exe.c display and dispdib are 16-bit dlls, you shouldn't import them. Still does the same thing whether I include then on the winebuild cmd line or not. Could you explain what the error message loaded .so but dll ... not found means? What does display.dll do? What efficiency gains will I make compiling a native shared library exe with gcc as opposed to just compiling with Visual C and running it under the normal WINE binary loader? There are basically no efficiency gains, there is no overhead in running a PE exe compared to a native one. Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here. thanks, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: richedit
On Thu, 31 Oct 2002, Michael Stefaniuc wrote: Hello, is somebody working on the richedit dll? I encountered 3 unknown RTF control words and wanted to add them but I got scared by the overzealous use of #define's in rtf.h . My first impuls was exchange that with some enum's, but i thought i better ask here before i do the work in vain. Isn't enum a C++ specific feature? If so then we cannot use it in Wine. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
Re: Debugging advice
On Thu, 31 Oct 2002, Matthew Bloch wrote: [...] There are basically no efficiency gains, there is no overhead in running a PE exe compared to a native one. Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here. But if you compile Winelib dlls as regular ELF libraries the application won't run so there is not much point. Besides, if you are using threads you cannot use gdb either because the Win32 threading is incompatible with gdb. So you are stuck with winebuild and winedbg. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
Re: richedit
Le mer 30/10/2002 à 20:44, Francois Gouget a écrit : On Thu, 31 Oct 2002, Michael Stefaniuc wrote: Hello, is somebody working on the richedit dll? I encountered 3 unknown RTF control words and wanted to add them but I got scared by the overzealous use of #define's in rtf.h . My first impuls was exchange that with some enum's, but i thought i better ask here before i do the work in vain. Isn't enum a C++ specific feature? If so then we cannot use it in Wine. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner No, it's part of standard C. http://www-ccs.ucsd.edu/c/types.html#Enumerations Vincent
Re: Versions mass-appeal
Well, you and I seem to have very different opinion on Wine. For you, it's a way to run a particular application. For me, it's like a virtual PC running Windows on my Linux box (ie more like a VMWare or a terminal server / Metaframe approach). *cough* Wine Is Not an Emulator :) - Ender
Re: Versions mass-appeal
On October 30, 2002 10:34 pm, Jeremy White wrote: However, I strongly agree with Lionel - since we have desktop mode, we should keep it as an option. Free software is all about choice. Yes, but that choice does not refer to to the choice of cramming every feature together. :) Virtually all reasonable uses of the desktop thing that I heard of is just to limit the size of the window. For that, it's way better to support a --maxsize option, which is per wine invocation. Only Lionel has this strange desire to run Wine as a virtual machine, which is fine, but it's not where Wine is going. If you are really big on the VM idea (why, beats me), we should separate that functionality out as a winedesktop executable. -- Dimi.
Re: Versions mass-appeal
Dimitrie O. Paun [EMAIL PROTECTED] writes: If you are really big on the VM idea (why, beats me), we should separate that functionality out as a winedesktop executable. Don't tell anyone, but that's exactly how the desktop option will have to be implemented to work with multiple processes. -- Alexandre Julliard [EMAIL PROTECTED]
So lets say we do it
That is, Lets assume for the sake of argument that Alexandre likes my 0.8 idea so much, that he releases Wine 0.8 with much fanfare next Monday (so we have a good audience), and the news reaches Slashdot where a message with a link to http://www.winehq.org is posted, in good CmdrTaco fashion... And so, let's see what's going to happen: 1. 90% of /.ers will click on the link, and WineHQ gets Slashdotted! :) 2. People will look for the typical left-side menu: Home About Status Development Download Screenshots *BZZT* We don't have any. 5% will drop off here. 3. Then they'll visually search for the word Screenshot *BZZT* We don't have any on front page. 30% will drop off. *I* drop off here when I visit other projects, for crying out loud! So let's assume that by a miracle they'll discover the screenshots: do they make them drool? No, we loose another 15%. Damn, that's tough! Let's see what happens to the rest: 4. Let's download, and try it out Do we have officially sanctioned binaries (at the very least .rpms for RH, and .deb for Debian)? No. *BZZT* We loose another 30%. Again, *I* don't care about stuff that doesn't come as a binary .rpm for my RH system. I used to, not anymore. Fine, some will install what they download. What next? Hm, this Wine thing just sits there, it's not that simple. We need to read some docs. Back to the site. 5. Look at the docs Oh, we have some. We hate to read docs, but Wine is cool, so we swallow the pill. Only to find out it's out of date!!! What a piece of #$%! *BZZT* Another 10% drop off. Thats 90% drop-off before they really tried it out! The rest 10%, go on. So, what do we do with it? 6. Look for a list of Win-apps that we can run Is there something on the site? No. Blah, too much hassel... *BZZT* Another 5% go. (Don't even mention app-db, it's *way* too complicated!) So the 5% left, install wine, install a Win-app, and play around. Great, it works! They start learning the utilities, etc., but those are in flux, and we change them, and they get PO-ed. Another percent, or two leave the fold... -- Dimi. P.S. A story-like TODO (with embedded rationale) for 0.8.0 :)
