Re: Bootprocedure again
On 2002.02.23 23:49 [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2002, David Elliott wrote: application. Save yourself a lot of trouble trying to figure out where to place a hook in wine and simply write it into a completely seperate program. You can then have wine actually run that program with a CreateProcess call or similar at whatever point. The code to do this should NOT be in the wine emulators source code itself, nor do I believe it should be linked in with it. Well, if it is a Winelib program, it would be linked with it, sort of, and loaded by it, but I think that is not what you mean here, is it? Err, by the code to do this I was still referring to the code that does the bootup procedure. And I don't believe that it should be linked to the emulator. It can and will have to be linked to winelib (thus making it a winelib program) but it should definitely not be linked in with the emulator portion of wine. The emulator may use a CreateProcess to call it during startup, but I would prefer a shell script. [SNIP] distributors of Wine to implement the actual policy and only provide the mechanism. This is what Alexandre has been saying, and I am saying the same thing. Policy decisions do not belong in Wine, even as configuration options when it can be helped. If you feel you absolutely MUST have this run every time a wine program is started or every time a wine program finishes (maybe this would be better) then write a shellscript like so: #!/bin/sh wine $@ wine_movefiles This is so simple, why would you even waste your time trying to hack it into the boot code for wine? -Dave Right. I like that. Yeah.. I think that this is a reasonable solution and we let the distributors figure it out from there. -Dave
Re: About that eeevil library naming decision...
On 2002.02.25 15:05 Andreas Mohr wrote: On Mon, Feb 25, 2002 at 11:47:31AM -0800, Alexandre Julliard wrote: Andreas Mohr [EMAIL PROTECTED] writes: Maybe we should use libwinecore_XXX.so and libwinedll_XXX.so for the naming scheme. That'd be pretty reasonable and cleaner/better than the current approach IMHO, as it'd clearly separate core/dll functionality in a good way. The separation will be done by putting dlls in a separate directory (usually /usr/lib/wine) which is a lot cleaner than creating 150 files in /usr/lib, no matter how they are named. But some people DON'T separate it. (for various reasons, which might only be evident in the future) Furthermore, having tons of hopelessly chaotically named libraries is everything but clean. Andi... if Wine DLLs eventually go into a /usr/lib/wine then you cannot possibly argue that anybody in their right mind would put them in /usr/lib. I don't see any distributors putting the libraries in /usr/lib/xmms/* into /usr/lib, do you? Wine dll path won't be added to /etc/ld.so.conf. But in any case the plan is that dlls in /usr/lib/wine are named without the lib prefix to make it clear you can't link to them. Fact is that a LOT of people/distributors still add it to ld.so.conf. We are not talking about libraries that people would want to link to in the normal UNIX sense. We are basically talking about what amounts to plugins for the wine emulator (in some sense). Therefore when wine is able to load the DLLs from a specific wine library directory then nobody is going to install them into /usr/lib, if they do then that is their own damn problem for being stupid. Anyway, I didn't know about the omit lib plan yet. That'd actually be a rather usable choice, since that'd really eliminate the conflicts. But are you sure that you can just omit the lib prefix on *all* supported environments ? Does it really matter? If they are in a seperate plugins type directory then who cares if the lib is ommitted or not. -Dave
Re: Clarification on my call for license change
ARGH!!! Why am I sending this.. I /SHOULD/ know better than to feed a troll I dunno, if you can't beat 'em, join 'em (goatse.cx link included :-). On 2002.02.16 04:51 Brett Glass wrote: At 09:02 PM 2/15/2002, David Elliott wrote: Given the choice of CodeWeavers releasing no code at all, or releasing under the LGPL, which do you prefer? [SNIP] The bottom line is that if the biggest contributor to the project wants to go LGPL then you can bet their tree will be better. This sounds very much as if you would like to allow CodeWeavers to determine the entire future of the project regardless of what anyone else thinks. Is this correct? Brett, I don't have to allow them to do anything. With your blessed BSD license they have every right to create an LGPL fork already. I am only stating the obvious. If CodeWeavers uses its rights under the BSD license to relicense under LGPL then even if no-one else developed on their LGPLed tree, chances are it would still work better than the BSD tree. If the rest of the developers see this, my guess is they'll just start developing on that tree as well. Why reinvent the wheel when LGPL is at the very least a reasonable license for everyone except for you. I've said it before, and I'll say it again: We won't cry if you don't contribute. Yes, CodeWeavers has contributed quite a lot of code to WINE. But it is not clear that CodeWeavers, with its current business model, is likely to remain in business no matter what license WINE uses. And, ironically, there are compelling arguments that CodeWeavers is likely to go under faster if the (L)GPL is adopted. Why? Because the company will no longer be able to serve its clients' best interests. Instead, it will have to disclose to potential clients (at least if it's being honest) something like the following: Because WINE is licensed under the LGPL (thanks to us), and the code we write for you will be licensed under the LGPL, all of your competitors will be able to take advantage of the code even though you're footing the bill for its development. We won't do anything for you that gives your product an exclusive feature or some other competitive edge. Good luck in the marketplace! I do not think that this would get CodeWeavers many customers. So, they'll either have to lie, withhold material information (i.e., fail to disclose the full implications of the (L)GPL), or lose the lion's share of their business. Brett, you obviously haven't read any of Jeremy's mail. If you did you didn't understand it or couldn't/didn't believe it. Jeremy has stated that he already requires that his contracts give any code he does back to Wine as if Wine were LGPL. If this is your tired-old argument that no-one could possibly write non-(L)GPL software having looked at LGPL/GPL code you can go turn it sidewise and shove it right up your ass. See http://www.goatse.cx/ for an example. Wait.. I think that's down, try http://www.conhugeco.org/goatse.cx/ for an even better example (link found via Google(tm)). You'll notice that that page contains detailed pictures of how this can be accomplished. Thus, the most likely outcome is that CodeWeavers will go belly-up. I hate to seem like a prophet of doom, but unless they're snatched up by someone like Red Hat this is the most likely prognosis. (Red Hat is likely to fail in the long term as well, but due to its large market cap it will take longer to exhaust investors' money.) No rocket science here -- just basic business principles. Great, but chances are that even if CodeWeavers does go belly up by the end of the year they will have mostly finished Wine before doing so. Worse still, if it is allowed to determine the license by fiat, CodeWeavers will leave great damage behind. It will have irreparably consigned WINE to a license that will forever limit its application. True, but CodeWeavers won't be forcing outsiders to develop on their LGPL fork, it's just what will logically happen. IMHO, this is not at all a good way to go. If one looks forward rather than backward, it's quite clear that WINE should remain under a truly free license. Only in your mind. Almost everyone else has expressed that they really don't care one way or the other. And the number of people who would rather go LGPL seems to far outwheigh the few that absolutely would not want LGPL. And furthermore assuming the votes are weighted according to contribution, then your vote at best has a factor of 0 and at worst has a negative factor because you have done nothing but waste everyone's time with your repeated ill-conceived arguments that have added absolutely nothing to the discussion. -Dave
Re: Clarification on my call for license change
On 2002.02.16 10:50 Roger Fujii wrote: Aric Stewart [EMAIL PROTECTED] wrote: The simple of it is.. you, Patrik, would not buy a Wine distribution form us. Why would you? You are a developer, and a wine developer on top of that. What seems to be the most commercially successful mode on top of opensource is to have an opensource base and have a value-add component - but I have yet to see a successful mode that has no propriatary component. At the moment, this is true. Most of the open source companies have at least some proprietary software built on top of an open source foundation. Right now the market for open source software is small. Most of the people who know about open source software aren't willing to pay for support because they can just support themselves. If/when open source has more market share selling open source software with your only value-add being product support may become much more viable. I think that in fact it will become much more viable. The key is that in order to make this model work you need to be selling to a market that is unable or unwilling to provide their own support. As mentioned before, Red Hat may not be doing great, but if you take into account that they have a very small viable market (that is, the people actually willing to pay for support) then they are doing pretty damn well. It is these sorts of people and companies that we want to target. And financially Patrik's money for his license or even the money form all the wine developers would be nearly insignificant compared to a 100+ seat site license. uh, how can you sell a N-seat site license with something that is covered by *GPL (since this would be a violation of the license)? If your model is to sell by seat, I would like you see the reasoning between the difference of a 10 seat license and a 100 seat license with the *GPL. If you are selling support then you can most definitely sell per-seat. You cannot expect to sell a free product without some sort of value added. That value can be a proprietary component or can be support for free components or can be other stuff that no-one as yet thought of. If your business model is to sell only what your customers can get for free then you are really, really, really, stupid. As a developer who has worked on far too many proprietary Wine trees and seen all the fights the Jeremy has gone through. I want to be assured that i can give my code back to the wine community. As I said before, if a copyleft is all that is needed, choose a copyleft that makes SENSE. LGPL may be convienient, but I have seen no rational argument in having the *GPL's brand of copyleft (other than it's widely used). I think the mozilla project would be a good place to look... This is a very valid argument. Although realize that they are now MPL/LGPL/GPL triple licensed. And the only reason I could see for having the MPL in there was so Netscape can take the code and release closed-source versions. This doesn't really work well for Wine as the codebase is not owned by a single entity. If you have a copyleft license that you feel would make more sense for Wine than the LGPL, please discuss it with us. -Dave
Re: Wineconf attendance
On 2002.02.13 20:36 Alexandre Julliard wrote: Gavriel State [EMAIL PROTECTED] writes: Since various people have been saying I'll go if you go, I just want to let people know that Ove and I will both be going to the Wineconf. In case it helps other people decide, I confirm that I'll be going too. Wish I could make it, but I am on the east coast, not the west. Maybe I'll bring my fencing equipment and we can settle the licensing debate properly with a duel. 8-) Works for me. I'll bring a shotgun ;-) No no no... you need a pistol for that. Like in Indiana Jones (forget which one, warning: if you haven't seen them, STOP NOW, rent all 3, and come back) where the guy comes up to Harrison Ford waving his sword all around. Harrison Ford looks down at the gun for a second, looks back at the guy, and just shoots him. :-) -Dave
Re: Wine's path VS host path
On 2002.02.14 22:08 David D. Hagood wrote: [EMAIL PROTECTED] wrote: Pity you couldn't use some other environment variable. The entire unix Yes, but make must also be able to find the tools, hence they are in the path (I am using Linux's binfmt_misc with the appropriate settings so that the programs are directly executable). compiler would look in, say MYPATH, a shell script could easily set that how it liked. If I had the source, it would already be running natively. However, in this case I don't - the compiler is for a DSP, and is most definitely Closed Source *nix current directory is another possibility you should consider. If The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option. wineserver -p Great! One down, one to go. I'll add that to the initial setup shell script. Perhaps, one fine day when I'm not trying to get a 160G drive to play nice in my computer, and I've taken the time to get ADPCM working in Wine, I can add some sort of additional path environment logic in. How about this: Wine reads your ~/.wine/config in as a registry file. When you start the wineserver you get the server started up. The first invocation of wine reads the config file into the registry. Thus the Path = is actually stored in the registry and can thus be changed by using the regtool. Assuming upon startup of any program it reads the environment variables out of the registry and sets them from that, then you should be able to use the regtool to append the appropriate path from your script. Then when you run the compiler it will have the proper path. This is of course assuming that the wineserver remains persistent and thus further invocations of wine processes do not reread in the config file and overwrite what you have done to the path. I /think/ this will work.. no guarantee. Lemme know if it does. And **I** would actually rather release under LGPL, thankyouverymuch. -Dave
Re: ldconfig : ..... .so is not a symbolic link
On 2002.02.15 11:48 [EMAIL PROTECTED] wrote: [SNIP] Not only that, but make uninstall make install is broken. I thought that would fix it, but I had to install the wine binary by hand, and the result is exactly the same. Where there were symbolic links before are now copies. Besides wasting file space, though, I don't see it does any harm. You get this mail by the latest Wine, ldconfig warnings and all. Hmm... To make uninstall: rm -rf /opt/wine-cvs To build and install: ./cofigure --prefix=/opt/wine-cvs make depend make make install To run: Be sure /opt/wine-cvs/bin is on your PATH and that /opt/wine-cvs/lib is in your /etc/ld.so.conf.. that's IT.. why WOULDN'T you put Wine in it's own prefix under /opt or /usr or wherver you please. Solves all of these problems. Besides.. make uninstall is a broken concept anyway.. Who the hell would want to keep the sourcetree of a program around just so they could uninstall it properly? Not I. -Dave
Re: OT: Wine build system tech info
On 2002.02.13 23:41 Alexandre Julliard wrote: [SNIP] Actually an advantage of a makedep tool is that you generate all the dependencies for a directory in one step. This means that you only need to parse each include file once, even if it is included from multiple .c files. This can easily be an order of magnitude faster than preprocessing each file individually (though with recent gccs you can use gcc -MD to generate dependencies while compiling the file, which is even more efficient; sadly it's not portable). Ah yes.. good point. I'll probably wind up using Wine's makedep for my project then. If I recall though, it had issues with includes that were only included if something was specifically defined. Maybe I should take another look at it. X11's makedepend still chokes on #if's with logical operators and also likes to generate dependencies for the system headers too which just fills up the makefile with tons of dependency info. Maybe I can find some time to look through and extend Wine's makedep to be a bit more usefull for projects other than Wine. Or maybe I should read a bit more documentation on it first. :-) -Dave
Re: Wine license change
On 2002.02.14 15:25 Plato wrote: [BIG SNIP] P.S. For the last time, please do not reply to me directly: only to the list. PLEASE! Actually, the ettiquette on this list is to hit Reply All and thus post both directly to the people involved in the discussion and also to the mailing list. Personally I prefer this, and I was actually about to write an e-mail to Brett bitching about him replying to one of my mails, twisting my words around, and sending it only to the list. I filter the list based on the headers from the list server. So if the mail came through the list it goes into the wine-devel mailbox. However when you send a mail both to me and cced to the list I get two copies.. one in my normal inbox which I can read and reply to immediately, and one which is in with the rest of the stuff in the mailbox for the list. There have been lots of discussions about this in the past, so please don't flame someone (even if he is a flamer in all senses of the word) for doing what everyone else on the list does. -Dave
WineCorp (was Re: Wine license change)
On 2002.02.13 13:52 Ian Schmidt wrote: [BIG SNIP] To put this back on topic, I don't see any immediate benefits from a LGPL license. If we knew what the threat to Wine Jeremy hinted at was, it might make for a more informed discussion. I also liked Gav's idea about WineCorp a lot as a compromise, and I'd love to see more dicussion of that and less licensing flaming. Agreed. In my private mail to Alexandre I mentioned that we need some sort of Wine Foundation. Apparently Gav has the same idea and at least one other person (you) seems to like it too. Personally while I can't say if the LGPL would be absolutely wonderful for Wine I don't think it'd be horrible and thus I'll support whatever is chosen. The main problem with LGPL is that once we go there we can never go back. Well, we can if all the people who made LGPL contributions agree to a license change, but unlike the last license change where this was possible because there wasn't anybody (to my knowledge) attached to the old license, there may very well be contributors to an LGPL codebase who would NOT want to release under X11. Thus what we really need is some entity that will always have an unlimited license to the complete wine codebase to do with it as it decides. I question assigning copyrights away from myself and to anyone else, is there some reason why signing an unlimited use license wouldn't be acceptable (and thus developers would still retain their own copyright) or is that effectively how it works anyway? Wine cannot stay X11 free-for-all forever. Reminds me of one of Roger Ebert's columns about the movie It's a Wonderfull Life. Because the movie is now public domain, anyone can use the original print for whatever purpose. This includes colorizing it and then selling the colorized version for a lot of cash (thanks Ted... yeah right). The colorized version is a bastardization of the movie and is one of those cases where you almost wish that copyrights didn't expire. Especially considering that the director and the much of the cast were still alive to see this horrible, horrible thing. Wine is very much in the same position here. While we are not quite public domain we are so close that any distinction is a moot point. However, the X11 license has the great advantage that it is extremely flexible. So flexible that anyone who wanted to could take the tree and release it under any other license. If we were to switch the tree to LGPL we would loose this advantage and would essentially be locked into terms that will always be at least as restrictive as the LGPL. If we were to set up some sort of Wine Foundation, or WineCorp as Gav calls it, then we could require contributors to license their code to WineCorp with unlimited rights knowing that WineCorp is established to act in the best interest of the Wine project. Perhaps a board could vote on whether to allow companies like TransGaming or Lindows to make a binary release and perhaps they could set conditions to the contracts. In order to get these types of licenses the companies would have to at least fork over some cash which would be used to cover the costs of running WineCorp. I would suggest that WineCorp be legally incorporated as a non-profit organization. Looking at some of the more popular BSD-type licensed projects, many of them have this sort of non-profit set-up. Apache would be the one that springs to mind immediately, I'm sure there are others. Anyway, I think I have written enough for now. I am really interested in discussing this, and I hope that by writing this I will have sparked some sort of discussion among the rest of the developers. I'm hoping the reason Gav didn't get very much response is more because everyone was waiting for the next guy to respond and not because no-one would be interested. -Dave
Re: Wine license change
On 2002.02.13 12:44 Steve Langasek wrote: On Wed, Feb 13, 2002 at 10:29:03AM +0100, Patrik Stridvall wrote: [BIG SNIP] Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library. In that case, I can't see any reason the LGPL would forbid what you describe. Yes, and this is what Patrick and I have been arguing (together, not against each other) about. We both believe that the LGPL would still allow independent functions of a DLL to be implemented by a non-LGPL library linked to the code. Patrick, IIRC, states that because of this the LGPL offers almost no protection, and because it brings with it several other issues that overall it is bad for Wine. Personally I feel that even though it is very, very minor protection that there's a good chance that it's just enough to be worth it. However, I'm really not interested in debating the LGPL.. I'm more interested in seeing what peoples thoughts are on my Wine Foundation and Gav's WineCorp ideas (the same thing, different name). To me this seems like a more ideal solution than a change of license to LGPL. -Dave
Re: Copyright, derivative works, and truly free licensing (Was: Wine license change)
On 2002.02.13 01:08 Brett Glass wrote: At 09:06 AM 2/11/2002, Steve Langasek wrote: I'm sure the FSF would be a nasty litigant, if you refused to settle after infringing the copyright of any of their source code. Since the FSF doesn't hold the copyright on any of the code in Wine, however, that objection isn't particularly relevant to the present case. Yes, it is. The FSF also encourages OTHER litigants to be nasty, both via the propaganda in its licenses and by offering to bankroll them and give them free legal services. In short, the FSF hopes to turn programmers against their colleagues with the goal of destroying the industry. Once again Brett, you have stated the obvious. The FSFs stated goal, I believe, is to make all software Free Software and rid the world of the practice of treating software as intellectual property. This is not the goal of everyone who wishes to use the LGPL license for their software. In fact, I think the majority of people who use an FSF license don't buy into all of the rhetoric from the FSF. If Wine went LGPL and a developer wished to enforce the LGPL license I'm sure the FSF would be more than happy to help. And you are probably right that they would encourage it. But the bottom line is that it's still in the copyright holders' hands. Your notion that the Wine developers are the FSFs sheep is absolutely appalling. I for one, and I think everyone else on this list as well, have had enough of this blatant anti-FSF rhetoric of yours. I think everyone has gotten the point by now and by continuing your argument you are only serving to further distance yourself from the Wine developers. Nobody likes a troll. If you have something else to say other than Wine must stay with the X11 license because only then is it truly free software and the FSF must die, then please do so. If not, then please shut up. -Dave
Re: OT: Wine build system tech info
On 2002.02.13 04:47 Vassilis Virvilis wrote: Halo wine-devel people, Although I understand you probably enjoy one of the best or worst f^H debates of all times (who said wine devel is immune to flamewars after all? :-) I would like to pose a somewhat off topic question but still quite technical. Actually, this is probably more ontopic than any of the license flames have been. Need to remember to put on the asbestos underwear before reading this list anymore. As part of a private investigation I noticed that both WINE and LINUX kernel build systems have a mkdep utility which generates in clude file dependencies. What I am looking for is to understand the reasons behind this decision for the two very popular projects instead the recipe suggested by GNU make documentation. THANK YOU! Off the subject of Wine, but relative to this particular discussion, I have been working on a project at work and I briefly investigated Wine's makedep system, and then noted that X11 has its own makedepend command (which is actually installed onto the system). What I have done right now is to use the X11 one to handle my dependencies. I really don't like this as it chokes on some of the #if defined(SOMETHING) || !defined(SOMETHING_ELSE) type constructs in wxWindows code. It also seems to like to do deps for all the system headers as well (well, you can specify ONE system directory it won't do deps against, but that's lame). Trying to rip Wine's makedepend out was even worse. I tried it first since when I thought make depend the first thing that came to mind was all the times I've typed that compiling wine every few days at least. At least the X11 makedepend had a good manpage. Here is what GNU MAKE suggests as the preferred way to handle dependencies. #-Makefile Start TARGET=a SOURCES=a.c b.c CFLAGS=-ansi -pedantic -Wall OBJECTS=$(SOURCES:.c=.o) DEPS=$(SOURCES:.c=.d) %.d:%.c set -e; $(CC) -MM $(CPPFLAGS) $ \ | sed 's/\($*\)\.o[ :]*/\1.o $@ : /g' $@; \ [ -s $@ ] || rm -f $@; $(TARGET): $(OBJECTS) include $(DEPS) #-Makefile End This method has the several disadvantages: Before we get to the disadvantages I'd really like to point out that the .d targets would seem like a more reasonable way of working with make. Considering that you can be sure you won't need to update the dependency info (the .d file) unless the source has changed this will actually save you time when rebuilding the project over and over again. i) It is GNU specific (unportable): a) Needs accumulative dependencies. That means a.o:a.c a.o:a.h does not override the first entry but it means a.o:a.c a.h Assuming you depend on the standard target to make a .o from a .c (or have defined your own) then there should be no need to have the a.o: a.c line in the makefile itself and thus the a.o: a.c a.h style line can be put in the dependency info (like wine's make depend) b) It requires the include statement c) It requires that MAKE will reload the Makefile as soon as it realizes that the Makefile or any of included file has been changed. These to can be gotten around by going back to an actual make depend target that must be run before doing a make. For a non-GNU make you would just make all of the .d files and then append all of their contents to the makefile as per a usual make depend. d) It uses compiler specific features. Man, that's a shame that more compilers don't support that. Actually, it seems to just invoke the preprocessor to do this, so one could theoretically just use the GNU cpp to generate the dependency info without using the rest of gcc. ii) Speed. a) Files has to be parsed twice during compilation. Of course. With any dependency system you are going to have to parse all of the source files to generate the dependencies and then actually compile them. What is the problem? By compilation I assume you mean the build of the whole project, not the compilation of one individual source file. b) Slight changes to config.h may result in unnecessary, uncontrolled compilations. Umm yeah, ./configure; make depend; make; touch config.h; make and watch it all recompile. --- I would like to know if there are any other reasons that is not listed here and or if any of the reasons listed above is more significant than the others. I think it's more of an issue that a dependency system is pretty trivial to implement with the exception that doing it means time was spent that could otherwise have been spent programming. I don't think the fact that GNU has a standard for makefile dependencies is going to convince Alexandre to change the tree. Nor do I think Linus will be convinced to change the Linux tree. However for my own projects I'll keep
Re: Dr. Seuss, licensing, and WINE
On 2002.02.08 15:03 Brett Glass wrote: At 12:28 PM 2/8/2002, John Alvord wrote: Seems to me that contributers should have most of the say I'm not only a user but a potential contributor, as I frequently fix bugs in the open source code I use and maintain for others. I also recommend products to end users and install them on end users' systems. I will not be able to contribute to, fix bugs in, or recommend WINE if it is under an FSF license. The impact of a license change will reach far beyond the contributors. Yeah, so? Who owns the copyright on the code.. oh yeah THE CONTRIBUTORS. Most of the contributors have been with Wine for some time now and originally put their code under the original Wine license which was very restrictive and poorly written. The decision to go to X11 was in fact made in part because it meant we had no restrictions whatsoever but could add them to new code at any point. Specifically discussed way back when was moving to LGPL at a later point. I have been very thankful for WINE, because it has in some cases allowed me to escape the grip of the megalomaniacal Microsoft. But if WINE is (L)GPLed, all users, contributors, and software vendors who might like to promote it will be in the grip of the equally megalomaniacal FSF. A fork is the only thing that can prevent this, and again, I would strongly encourage one if it appears that the FSF is about to commandeer the project by persuading a subset of the contributors to impose its license upon everyone else. Sounds to me like you've been thankful for Wine not because it is free software, but because you are getting a free lunch. the megalomaniacal Microsoft??? Please. And then this bullshit (call it like I see it) about the FSF commandeering the project? The FSF has not been bugging us to change to LGPL. The last time we were involved with the FSF (actually, specifically Stallman) we went with the X11 license which meant that we were compatible with the (L)GPL. While Stallman stated his opinion at the time that he thought an FSF license would be a better choice because it would offer us more protection he also conceeded that X11 was a good choice given the circumstances. And why wouldn't he? Why in the hell does the FSF care if we are X11 or LGPL. Either way all of their projects can use our code! Another thing that worries greatly is Jeremy's message stating that he has been consulting with Eben Moglen, of the FSF, about licensing. Asking the FSF's advice about licensing is akin to asking the IRS to prepare one's taxes: It will act in its own interest, not yours. The FSF's sole goal is to destroy commercial software developers, and so it will naturally do anything it can to accomplish this aim, even if the results are also devastating to the WINE project. It does not appear that CodeWeavers has consulted with anyone who does consulting and writes code under truly free license. I've already recommended, in a previous message, that they consult Perry Metzger of Wasabi Systems, who can demonstrate to them that a truly free license is greatly beneficial. (The fact that NetBSD is truly free is, in fact, one of Wasabi's strongest selling points for its software and services.) Give me a break dude. Yes, the FSF wants all software to be free and wants to rid the world of commercial software altogether. Why is this such a new idea to you? Did you think that this was some kind of secret agenda? Quit with the conspiracy theories. Everybody already knows what the FSFs purpose is. As for your advice to Jeremy on how to run his business, I'm sure he'd love to say this to you but wouldn't: stick it where the sun doesn't shine. While most people like you have all these wonderful business plans with no real thought whatsoever put into them, Jeremy is out there actually doing what you don't have the nuts to do. How would you feel if I told you how to run YOUR business? The argument that NetBSD is truly free is good. You're right.. it's like getting a free lunch. It is also of great concern that CodeWeavers has stated that it will begin to add code to the source tree under LGPL. By thus contaminating the tree, it will force its decision upon the other developers. The company's code should not be committed if it does not contribute it under the MIT/WINE license. Umm, no. Alexandre maintains the official tree and has stated on many occasions that only X11 licensed code will be accepted. This has not changed and will not change unless the majority of developers agree that a license change is a good thing. Going back to your mail which started this thread you make some comments about how you cannot even look at (L)GPL code if you are a commercial developer. This is even more bullshit. Do you really think the wine developers were born yesterday? That same comment (and in fact almost all of your comments) have been posted on slashdot for
Re: Dr. Seuss, licensing, and WINE
On 2002.02.09 04:29 Patrik Stridvall wrote:
If people don't understand that some people are decent and
contribute back
regardless of whether they are forced to or not, but others
are not and
require a feedback loop to force this behavior, then they
don't understand
how the world works and we're just wasting time.
That is not one of the problem, as far as I'm concerned
I fully agree that there will be companies that will be,
how should I put it, less honourable. There ALWAYS are in
ALL markets.
I was trying to bring it home to Dimitrie that not everyone is bad as he
seemed to suggest.
As I sidenote I would like to say that I believe that
the LGPL for reasons stated in last debate will not be enough
to stop less honourable companies from doing less honourable
thing.
You might believe me or you might not, as all people arguing against
me last time. Be that as it may, that discussing is dead and I
will in the future concentrate on If the LGPL means what you
say it does, we don't want the LGPL.
Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL
actually WOULD allow one to implement proprietary code simply by releasing
small wrapper functions as LGPL code.
As in:
DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz)
{
return someotherdll_FooMicrosoftApi(bar,baz);
}
Which would be LGPL, and the someotherdll_FooMicrosoftApi would be under a
different license.
With this situation the stated purpose of the LGPL is still upheld. The
stated purpose is to allow one to continue to update the parts of the code
that are LGPL while still being able to link with proprietary components.
Thus TransGaming does not hurt. Lindows really doesn't hurt either, and
the users of Lindows win because should they need to update the LGPL
components of Wine they can do so and still continue to link to Lindows
binary only components.
Now you may consider this not enough to stop the less honourable
companies. Yeah, you're right. Lindows can continue to build upon wine,
add their own stuff, and release a product. The only difference is that
now they can't just fold all the wine code into the binary.. they have to
allow the user to update the wine code. That is the purpose of the LGPL.
Unlike the GPL which tries to make all software free software, the LGPL
tries to keep free software as free software, and proprietary software as
proprietary software.
Now let's say we take the stricter interpretation that you cannot do the
above. That is bad I think.
How about going to LGPL and add a clause that clarifies that the above is
in fact allowed?
I think it's more of an issue of people thinking too much in
black/white
terms and people that lean strong towards one side or the other.
Yes. Perhaps they are not nessarily thinking in black and white
but their arguments are often presented that way.
I'm not entirely blameless on that point either, I will try
to do better in the future.
Look no further than the US political system for a good
example. You have
the Republicans and the Democrats. Generally they take every
issue to
opposite ends of the extreme such that 99% of congress is at
one extreme
or the other, but 99% of the population wants neither extreme.
Exactly, but that is because:
1. They want votes so they can do that they feel is right.
2. The ignorant masses are not likely to understand subtle
differences in opionion.
When the voters give any of them support, the problem is that
they didn't really support the extreme views they presented,
but they are forced to do it anyway in order of not being
accussed of betraying the will of the voter.
You can thank the liberal media for that one. :-(
Especially see MSNBC. What a crock of shit that is.. figures, it being a
MS product and all :-). The reporters on that station are just horrible.
They ask a question and when they get a totally straight answer that they
don't agree with they just ask it again and again changing a few words to
make it seem like it's a different question.
In the cases of Wine. I hope that the people working with the
Wine project are not among the ignorant masses and thus really
are able to understand the subtle differences between different
positions.
Yeah, so far it only seems like the people who caught this story on
slashdot are among the ignorant masses. :-/
Essentially we could go on forver about X11/BSD vs. GPL. It's been
discussed to death already folks. What we need are reasonable
compromises. Of course you need to have people willing to
compromise to
do that. I suspect most developers are with the exception of
the view
vocal BSD people and the few vocal LGPL all the way people.
I myself am
certainly not at either extreme.
Even if perhaps some people won't believe me. I not really
an extremist. I try to take a pragmatic view of the world.
I believe that GPL has its place, LGPL has it
Re: Dr. Seuss, licensing, and WINE
On 2002.02.09 05:32 Plato wrote: On Sat, Feb 09, 2002 at 03:50:09AM -0500, David Elliott wrote: On 2002.02.08 15:03 Brett Glass wrote: [...] taxes: It will act in its own interest, not yours. The FSF's sole goal is to destroy commercial software developers, and [...] Give me a break dude. Yes, the FSF wants all software to be free and wants to rid the world of commercial software altogether. [...] I think it is worth pointing out the the Free Software Foundation does *not* want to rid the world of commercial software. Stallman has, however, stated that he would like to rid the world of *proprietary* software. Whoops, sorry, you are correct about that. However to the person I was replying to commercial==proprietary. Red Hat Linux is a commercial product, but not proprietary (to give an example). Though I think Red Hat does have a few proprietary products they work on. There is an incredibly important difference. Please do not use the terms interchangably. See http://www.gnu.org/philosophy/words-to-avoid.html#Commercial http://www.gnu.org/philosophy/software-libre-commercial-viability.html Been there long ago.. just kinda forgot. -Dave
Re: Wine license change
On 2002.02.09 15:55 Brett Glass wrote: At 08:11 AM 2/9/2002, J.Brown (Ender/Amigo) wrote: John Carmack made an intresting point, he releases ID softwares older releases under the GPL. Why? Because after originally releasing an engine after a BSD-esque license, a project done some very major work to the engine... and then lost it in a harddrive crash. So his -main- reason for using the GPL is to prevent work done in the community from being lost. He really should take the time to back up his drives. ;-) But, assuming that he wishes to use this rather unusual backup mechanism, why would the GPL be any better at this than a BSD-style license? Yeah, i didn't quite get that argument either. There are of course other points. The LGPL is the GPL without the restrictions which prevent useful commercial use. Alas, this is not true. The latest version of the LGPL -- which RMS dubs the Lesser GPL -- imposes many restrictions which make commercial use difficult if not impossible. For example, it requires that software including the library be provided not just as a finished product but as a series of object files which can be lined with a newer version of the library. Not only is this a maintenance and logistics nightmare; because it exposes the symbol tables, it makes reverse engineering of the code trivial. This is by design. Yes, the purpose of LGPL is to force proprietary components to be in seperate relinkable object files. Again, this is not new information-- just like saying the FSF is trying to keep people out of the proprietary software business is not new information. The only symbols you'll have to export from these proprietary objects will be the exports, I'm sure you could come up with a way to make sure the internal symbols don't get shown to the world since you are such a great proprietary software developer. And don't be concerned about looking at LGPL code either. I too develop proprietary software and I develop some of that software using free (LGPL) libraries. There is nothing preventing me from looking at the source to these libraries I am using. I am not infected with the (L)GPL and thus unable to write proprietary software. So far in every case (well, actually settlement) involving the GPL it has been a very clear violation of somebody linking their software with GPL software, or knowingly incorporating GPLed code into a product. That is clearly not allowed by the GPL. However linking LGPL components with proprietary components /is/ allowed so long as you provide a way to continue to modify the LGPL components and relink them with the proprietary components. This is, in effect, the stated purpose of the LGPL. Why is this so hard for you to understand? -Dave
Re: Dr. Seuss, licensing, and WINE
On 2002.02.09 06:39 Patrik Stridvall wrote:
You might believe me or you might not, as all people arguing against
me last time. Be that as it may, that discussing is dead and I
will in the future concentrate on If the LGPL means what you
say it does, we don't want the LGPL.
Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL
actually WOULD allow one to implement proprietary code simply
by releasing
small wrapper functions as LGPL code.
Yes, but you was one of the few. Alexandre in particular seemed
to believe it depended on some strange notation of whether it
was intentional or.
In some ways it is. Many times when entities are violating some license
or law a decision is partly based on what exactly their intentions were.
Although I would not like to rely on this and I think clarifying what and
what is not allowed is better than leaving it up to good intentions.
As in:
DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz)
{
return someotherdll_FooMicrosoftApi(bar,baz);
}
Which would be LGPL, and the someotherdll_FooMicrosoftApi
would be under a
different license.
With this situation the stated purpose of the LGPL is still
upheld. The
stated purpose is to allow one to continue to update the
parts of the code
that are LGPL while still being able to link with proprietary
components.
Exactly. However I see no reason particular reason why even
less honourable companies wouldn't release the wrapper code
to the us whether they were forced to or not. It is in their
intrest to make it easy for Wine to use their library so they
can limit the support for clueless users for example.
This even if LGPL allowed it, is not a strong argument for LGPL.
In this case it would only primarily the confusion on whether this
is allowed, for little gain.
Thus TransGaming does not hurt. Lindows really doesn't hurt
either, and
the users of Lindows win because should they need to update the LGPL
components of Wine they can do so and still continue to link
to Lindows
binary only components.
Exactly, but they will be able to do that without the LGPL.
It is in the respective companies intrest to make it so.
If that is so, then why aren't they doing it already?
Now you may consider this not enough to stop the less honourable
companies. Yeah, you're right. Lindows can continue to
build upon wine,
add their own stuff, and release a product. The only
difference is that
now they can't just fold all the wine code into the binary..
they have to
allow the user to update the wine code. That is the purpose
of the LGPL.
Unlike the GPL which tries to make all software free
software, the LGPL
tries to keep free software as free software, and proprietary
software as
proprietary software.
Yes. But that is NOT an argument for using LGPL as I have said above.
Sure it is. The LGPL's purpose in life is to make sure the users of the
program can continue to recompile the code that was LGPL to begin with.
Now let's say we take the stricter interpretation that you
cannot do the
above. That is bad I think.
How about going to LGPL and add a clause that clarifies that
the above is
in fact allowed?
Why confuse the company lawyer even more?
Even if I would be inclined to agree, I would rather let the FSF lawyers
draw up a completely new license lets call it, hmm, MGPL (Middleware
GPL),
for use in, hmm, what should I call it, say two-ended libraries that Wine
IMHO really is.
This MGPL should clarify that it is legal to plug-in proprietary
application/libraries in both ends while code the middle that is
the Wine source code should have some copyleft like protection and
additional that sublicening the code as LGPL is allowed.
Note however I'm not really proposing this but it might be a reasonable
compromise. Perhaps something for the LGPL camp to chew on.
What you describe sounds to me like what I am describing. A modified and
clarified LGPL. Essentially when you start adding or deleting from the
LGPL you are in fact making a new license. You are saying the same thing
I am.
[SNIP]
[Quote Dennis Miller: Y'know.. I don't want to get off on a rant here...]
When the voters give any of them support, the problem is that
they didn't really support the extreme views they presented,
but they are forced to do it anyway in order of not being
accussed of betraying the will of the voter.
You can thank the liberal media for that one. :-(
Well, that is just the symptom.
The ignorant masses are the real problem IMHO.
Unfortunately, there is no serious alternative to democracy,
so I'm a loss what to do. :-(
True. Actually, I think the media is more of a symptom of politicians
catering to them for years now. Look at the administration now. They
don't take any shit and just tell it like it is. Bush may not be an
excellent speaker but he seems to
Re: I see no reason to change the license
On 2002.02.09 13:52 Sean Farley wrote: Thinking it over. I see no benefit for a change to the LGPL. The main reason was to force companies to give WINE their changes and/or additions to the code. As several people have pointed out, they can get around this by writing API wrappers. Doing so they will have removed the only reason the LGPL was proposed in the first place. It would be quite easy to keep in sync with the WINE code base. A PERL script (or whatever) could be written to output a wrapper file. Another script could be used to make changes to any future code base to make use of the wrapper calls. As someone who did this for my last company (JAVA API using JNI calls to mirror their own C library), I can say this will take a minimal amount of work. They would only need to release the changes they made to the code (just the wrapper calls). I don't see this as a problem. At least as a user of this companies product and a developer of Wine I could still modify the non-proprietary parts and use them with the proprietary parts instead of having to either take an all-free source/binary release or an all-proprietary binary-only release. If you want to force the code out of others, a much stricter license than the LGPL or even the GPL will be required. Can anyone recommend one and have it still be open source? I don't think we want to force the code out of others. Well, some people do, but that pretty much requires GPL which is not an option at all and shouldn't even be considered to remotely be an option. Mainly what I'd like to be able to do is keep the proprietary stuff seperate from the free parts of wine. The LGPL accomplishes this and this is the LGPL's purpose, nothing more. Of course if Lindows is nothing more than simple little one line bugfixes all over the place in Wine then LGPL would make it difficult for them. If they rewrote large portions then LGPL makes it easier for them. -Dave
Re: Dr. Seuss, licensing, and WINE
On 2002.02.09 19:36 [EMAIL PROTECTED] wrote: On Sat, 9 Feb 2002, David Elliott wrote: This is simply not true. This is very much Wine's problem. If I need some of Lindows's functionality to run my program but would still like to be able to hack on other parts of Wine then I, as a developer and user, am screwed. Now hang on! Mind, I won't spend any money to find out, but what is lindows exactly? Did they undo all the dll separatrion and make a single monolithic static-linked executable, or is it (stripped?) binaries lindows and linserver and a whole bunch of (stripped) elf-pe dll's and lindows-lib executables? If so, either they will interoperate with Wine, or we can make them do so, even if we have to add another entry to loadorder (builtin, so, lindows, native). While it is true that you can still work on the DLL as a whole if there aren't parts you need from Lindows it still means you can't work on other functionality in the same DLL as one where you need at least part of the Lindows implementation. Ought to be easier to reverse engineer than native windows dlls, too. :-) Yeah, I bet you're right on that. -Dave
Re: Wine license change
On 2002.02.09 18:31 Brett Glass wrote: At 04:06 PM 2/9/2002, David Elliott wrote: Yes, the purpose of LGPL is to force proprietary components to be in seperate relinkable object files. I wouldn't call this its purpose, just one of its many requirements. The purpose of the FSF is to eliminate all commercial software and compromise programmers' livelihoods (as Stallman specifically writes in many places, including his GNU Manifesto). Really The FSF's purpose is to elimnate all proprietary software Who'da thunk it? Is there someone who doesn't know this.. it's written all over the website.. jesus, you act like it's some big secret. The only symbols you'll have to export from these proprietary [Snip] Not proprietary, but commercial. No, proprietary. You can both sell and develop free software as a commercial entity. End of discussion. Everything CodeWeavers has put into Wine is commercial, but it is not proprietary. I see you seemed to concede my point that you only need show the symbols you are exporting. And don't be concerned about looking at LGPL code either. I too develop proprietary software and I develop some of that software using free (LGPL) libraries. There is nothing preventing me from looking at the source to these libraries I am using. Yes, there is. If you write anything like it -- ever -- the owner of the copyright on the code you have perused can claim that what you wrote is a derivative work and demand that you forfeit all rewards from it. This is one of the many hidden booby traps in the GPL and LGPL. This is classic FUD. Fits the definition perfectly. Fear, Uncertainty, and Doubt. As the licenses' viral spread has continued, the FSF and other zealots have gradually gotten bolder and bolder. While they have not played this card yet, they can -- and will -- if they see it as being to their advantage in their war against commercial software developers everywhere. The FSFs purpose and goals are irrelevant. The Wine developers purpose and goals are what is relevant. I see you are clearly interested in not helping Wine, but instead making sure that Wine stays both free software and free for you to fold into proprietary products. -Dave
Re: Dr. Seuss, licensing, and WINE
On 2002.02.09 19:18 Patrik Stridvall wrote: David Elliott wrote: On 2002.02.09 06:39 Patrik Stridvall wrote: [SNIP] In some ways it is. Many times when entities are violating some license or law a decision is partly based on what exactly their intentions were. Although I would not like to rely on this and I think clarifying what and what is not allowed is better than leaving it up to good intentions. Yes, but in the case of copyright it doesn't really make much sense. For determining the punishment for any infringment, yes. For determining whether something infringes, no. And sure I guess hiding behind fair use is harder if you intent is bad. Sorry, should have clarified that more. It is true that intent is used in the punishment phase, usually not the actual trial. However does the Joe Hacker in my earlier example that used a propriety library to avoid dual booting and shared it with fellow hobbyists have intent to infringe? This is pointless to discuss. I don't want a license where no one can possibly link wine with binary components. The LGPL does not prohibit that. [SNIP] Thus TransGaming does not hurt. Lindows really doesn't hurt either, and the users of Lindows win because should they need to update the LGPL components of Wine they can do so and still continue to link to Lindows binary only components. Exactly, but they will be able to do that without the LGPL. It is in the respective companies intrest to make it so. If that is so, then why aren't they doing it already? 1. Lack of time. 2. Lack of insight what their users might want. 3. Lack of concerned users. I'm sure you can find more reasons. Because the current license allows them to get away with it. [SNIP] Sure it is. The LGPL's purpose in life is to make sure the users of the program can continue to recompile the code that was LGPL to begin with. OK. Reformulate. There is no reason to force this to happend, since it is likely to happend eventually anyway. See below. No, there is EVERY reason to enforce this. [SNIP] Even if I would be inclined to agree, I would rather let the FSF lawyers draw up a completely new license lets call it, hmm, MGPL (Middleware GPL), for use in, hmm, what should I call it, say two-ended libraries that Wine IMHO really is. This MGPL should clarify that it is legal to plug-in proprietary application/libraries in both ends while code the middle that is the Wine source code should have some copyleft like protection and additional that sublicening the code as LGPL is allowed. Note however I'm not really proposing this but it might be a reasonable compromise. Perhaps something for the LGPL camp to chew on. What you describe sounds to me like what I am describing. A modified and clarified LGPL. Essentially when you start adding or deleting from the LGPL you are in fact making a new license. You are saying the same thing I am. As you wish, this is of no moment. See below. [SNIP offtopic stuff about politics] Of course, the ignorant masses really gets what they deserve. I primarily think it is unfortunate that I live in the same world as them. hehe :-) [SNIP more stuff about politics] Yeah, doesn't that suck. Kind of like people use proprietary software so they get what they deserve. We can't stop them from using it as that limits the freedom's of the proprietary software companies and the users who want to use that software. However what we can do is remove the need to use proprietary software. Wine is a first step towards this. Yes, but I never think the need for proprietary software will disappear. Obviously not in the grand scheme of things. But basic day to day tasks like just being able to use your computer should not require proprietary software. I would extend basic tasks to basic word processing and web-browsing functionality. Your typical Linux distribution is already at that point. The only thing missing is the ability to continue to run the Windows based programs that offer extended functionality. Wine fills that need and will help to transition users to a more reasonable and open platform. Wine is such an important product and yet most of the developers don't really care about its future. Moving users from Windows to some proprietary Windows clone isn't really helping. [SNIP] We should collectively think of the different scenarios and ask one very important question: Do we /really/ want to prevent this scenario from happening? Ah, I forgot that very important question. I intend to supply it but somehow it got lost. But perhaps the question: 1. Do you consider his or her behavior morally or ethically defendable? sums it up pretty well as well. Sounds kind of like my.. do you think it should be allowed question, although put
Re: Wine license change
This is the end of this discussion as far as I am concerned. I am not going to cry my eyes out if you don't recommend Wine because it may be LGPLed. And I'm getting really sick of fuelling Troll Wars 2002. -Dave
Re: Dr. Seuss, licensing, and WINE
On 2002.02.08 14:48 Dimitrie O. Paun wrote: On Fri, 8 Feb 2002, Sean Farley wrote: Just relax and take deep breaths. :) As should we all. It's difficult, because I see, once again, how the discussion deviates to mostly irrelevant topics. Quite frankly, I am very dissapointed with the current debate: -- I provide arguments which details the feedback mechanism generated by each license. What do I get back: nobody stops companies from contributing back under BSD or it is possible that companies will still contribute back under BSD, and crap like that. If people don't udnerstand that a system survives not on political will but on feedback loops built-in the system, they don't understand how the world works, and we're just wasting time. Small correction: If people don't understand that some people are decent and contribute back regardless of whether they are forced to or not, but others are not and require a feedback loop to force this behavior, then they don't understand how the world works and we're just wasting time. -- instead of focusing the discussion on what's important for Wine, we get incredible FUD as people will be afraid to link against the LGPL. -- we get arguments of the form: it is possible that... But of course is possible, for crying out loud!!! Everything is possible, but we should be concerned with what's _probable_! I'll stop here, because I'm too upset to continue, to be honest... I think it's more of an issue of people thinking too much in black/white terms and people that lean strong towards one side or the other. Look no further than the US political system for a good example. You have the Republicans and the Democrats. Generally they take every issue to opposite ends of the extreme such that 99% of congress is at one extreme or the other, but 99% of the population wants neither extreme. Essentially we could go on forver about X11/BSD vs. GPL. It's been discussed to death already folks. What we need are reasonable compromises. Of course you need to have people willing to compromise to do that. I suspect most developers are with the exception of the view vocal BSD people and the few vocal LGPL all the way people. I myself am certainly not at either extreme. -Dave
Re: Fix for MoveFileExA
On 2002.01.31 16:02 Gerhard W. Gruber wrote: [snip] OK. I just downloaded it. I hope I know how to open bz2. :) I assume that was a joke. [snip] Why is the To: field or the Reply-To: not set to the mailinglist instead of the poster? hehehee READ THE ARCHIVES! We need to have an FAQ on this somewhere on the website. -Dave
Re: DESTDIR support for make install
On 2002.01.31 17:52 Joerg Mayer wrote: On Thu, Jan 31, 2002 at 02:33:53PM -0800, Alexandre Julliard wrote: But make install prefix=/home/myaccount/rpms/tmp should do exactly the same thing, unless I missed something. You can run make with one prefix and make install with another one, that's a feature. I didn't know about this feature, but it works fine :) Thanks! Ciao Jörg You're still missing out on even more features though. The newer versions of RPM have configure and make install macros. When you use the configure macro it calls ./configure with a bunch of predefined parameters like the prefix and the etc directory and the manpages and info directories and so on. You then run make (usually wouldn't need any parameters.. although in wine's case don't forget to make depend before a make). Then when that is all said and done you use the makeinstall macro which runs make install with those parameters from the configure macro set with the RPM BuildRoot before them all. I believe Wine's makefiles should already be well behaved enough to handle that. Only issue I can remember is that a few weeks ago I grabbed wine out of CVS and compiled it on my work box and I could have sworn that when I did a make install that it compiled wineconsole again during that. I think that only happened during the first build of the tree (which is always going to be the case for an RPM). So you might want to look into that. Fortunately, this was not for an RPM, simply build as myself and install as myself into the /opt/wine-cvs directory which I own. -Dave
Re: Bug in MoveFileEx
On 2002.01.31 18:37 Gerhard W. Gruber wrote: I just played around with Thandor trying to install it and see what the differences are between Win98 and Wine because I noticed a slightly different behaviour. Now I discovered that MoveFileEx is not even available in Windows 98 but wine supplies it nevertheless. I suspect that the Setup doesn't check the windows version, but rather calls MoveFileEx and if that fails with not implemented returncode continues with other code to supply the functionality. I wrote a small test app to confirm this and this returns an error code when calling MoveFileEx on a native win98 whiel wine executes it. Okay, so wine supplies the MoveFileEx function (like NT) for all versions. If you had read the archives you'd know that the chances of hell freezing over are greater than the chances of version specific behavior being added to Wine. If MoveFileEx actually works and puts the info in the registry the NT way, then the only problem you'd have is if an application happened to actually check the windows version and use that to decide if it should call MoveFileEx or write to WININIT.INI directly. I suspect that most applications are going to behave like you suggest. That is that they will call MoveFileEx and if it succeeds then they will assume the file is going to get replaced (which see below for how Wine will do that). If MoveFileEx fails then they will add an entry to wininit.ini. That's not a problem because Wine's call should always succeed. Now, for the latter case where the app checks the windows version. Well, if it happens to write directly to WININT.INI instead of calling MoveFileEx, then no big deal. We will have code that reads both WININIT.INI and the NT-style registry entries. Considering that on Windows 9x/ME the WININIT.EXE program takes care of this, might I suggest that we create a winelib application (placed in the programs/ directory of the sourcetree) that reads in the registry entries and the WININIT.INI flle and process the entries and deletes them. Such a program I think would be aptly named simply wininit. Now the trick is to somehow actually get the user to run the wininit winelib program when needed. Personally I feel that this is secondary. It could simply be accomplished by a wrapper shell script. The important thing is to get the functionality described above implemented, and document that when an installer asks for a reboot you should close all wine applications and run the wininit command to cause the files to be copied. Of course with Wine more than likely you will not need to close anything and can simply run wininit while other unrelated processes are still running. I assume whatever Andi's program does would probably be similar to what I am describing. -Dave How shall I fix this? Shall I simply call GetVersion() to determine if MoveFileEx should be allowed or is there a different way with wine to determine which functions are available for which version (a global variable or such)? I looked through the sources but I couldn't find anywhere something where a versioncheck has been used to switch code but then again I don't know much functions where I know for sure that they are available in one version and not in the other. -- Bye, Gerhard If you think education is expensive, try ignorance.
Re: A new SDL back-end we've been toying with
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
Re: MS' hidden API
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
Re: Fwd: Total Annihilation
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
Re: Sooo quiet...
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
Re: Questions for developing functions
On 2002.01.20 03:36 Gerhard W. Gruber wrote: I have already posted this in the NG but I was told that this would be more appropriate here. One of my questions is how wine developers actualy develop their functions. I'm aware that some functions are (rather) easily determind just because of their name (i.e. CreateFile). Other functions can be derived from reading the documentation but there is quite a number of functions that arenot documented and some are not even mentioned anywhere (like functions in the rpcnt.dll). Now I wonder how you go about this. My approach would be to disassemble such functions and see how they work. Of course I know that in some countries this will be illegal while it is not in others. If I live in a country where this is legal would it still be a problem for the maintainer if I submit a function that is written based on the method I used to get the knowledge to write it? How do you circumvent that problem that you might infringe copyright as reverse engineering is usually prohibited by the licence where this licence is actually legally binding. Well, if the code you contribute could be considered a derived work of the code you disassembled then you'd have problems. But for instance if you disassembled for the purposes of figuring out how many arguments the function takes and what not but didn't actually directly write your code based on the disassembly, then you should be in the clear as far as that is concerned. Now, as for the breaking of the license agreement on your software. That mostly concerns you as you are the person under the license, not the Wine project. So if you feel like you would get into legal trouble by even disassembling something to simply see what types of parameters it takes, then I would suggest that you didn't do it. However if you feel that you would not get into legal trouble, and assuming you don't create your implementation directly from the disassembly (i.e. you reimplement from scratch, but just use the disassembly to get some ideas of function parameters) then you should be very much in the clear, and so should the wine project. Another question is concerning the function CreateDispTypeInfo. I'd like to work on Hotline which uses this function. As I noticed, this function is stubbed but not implemented and the last time it was worked on was somewhere in 2000, so I'd like to know if somebody is working on this. If I start work on it, do I have to submit this info somewhere in order to avoid duplicate work? Hey man, if no one responds in this mailing list within a reasonable timeframe then probably no-one is working on it. Just have a go and if someone else beats you to it without saying anything you can always do a peer-review of the code and see if maybe something should be done different. Two pairs of eyes are better than one. -Dave
Re: Questions for developing functions
On 2002.01.20 12:46 Gerhard W. Gruber wrote: On Sun, 20 Jan 2002 11:38:48 -0500, David Elliott [EMAIL PROTECTED] wrote: Well, if the code you contribute could be considered a derived work of the code you disassembled then you'd have problems. But for instance if you disassembled for the purposes of figuring out how many arguments the function takes and what not but didn't actually directly write your code based on the disassembly, then you should be in the clear as far as that is concerned. Of course I primarily use that insight to get information on what arguments are used. I don't intend to make a 1:1 representation of the binary code to C. :) Now, as for the breaking of the license agreement on your software. That mostly concerns you as you are the person under the license, not the Wine project. So if you feel like you would get into legal trouble by even disassembling something to simply see what types of parameters it takes, then I would suggest that you didn't do it. However if you feel that you would not get into legal trouble, and assuming you don't create your implementation directly from the disassembly (i.e. you reimplement from scratch, but just use the disassembly to get some ideas of function parameters) then you should be very much in the clear, and so should the wine project. Thanks. :) Remember though.. I am not a lawyer, and I am not Alexandre Julliard. Hey man, if no one responds in this mailing list within a reasonable timeframe then probably no-one is working on it. Just have a go and if someone else beats you to it without saying anything you can always do a peer-review of the code and see if maybe something should be done different. Two pairs of eyes are better than one. OK. Sorry to bother you with this, but I'm just starting out, so I don't know much about the procedure on how to contribute a bit. :) I'd also hate to start investingating when a few days later a patch is thrown at the list that does what I just started out to do. :) I also think that it wasted time on behalf of wine if many developers work on the same things and leave other areas to its own. No, it's not a bother.. the fact that you just posted saying that you were gonna work on it is desirable. -Dave
Re: common controls updown patch
On 2002.01.18 00:57 Shane Shields wrote: On Thursday 17 January 2002 4:13, you wrote: The remainder of any even number divided by two is 0, the remainder of any odd number divided by two is 1. Knowing this doesn't: len+=(len%2); make more sense. Leave the comment as is for clarity if you wish. -Dave thanks Dave, its also a lot more elegant and will work faster too. i will generate a patch for it to be applied on top of the first one. as my biggest strength is visual basic things like this dont come to me straight away. im hmm... VB... yeah.. BASIC in general tends to lend itself to crappy programs, always has, always will. However BASIC on a PCjr was my first language, so I guess it was okay to start with. Except for the fact that BASIC is so screwed up it screws with your mind and it takes a long time to realize that almost no other programming language does things like BASIC. Might I suggest Python if you are in the process of learning programming. Python is an extremely elegant language, interfaces well with C code, and has several GUI toolkits. I think the default toolkit is Tk (yuk) but wxWindows has a python version you may want to check out. The real wxWindows (C++) is just amazing for ease of GUI programming, I assume the Python version is probably easy to use too. still trying to work out what this means (delta 0 ? 1 : -1) its got me stuck. im currently looking at the wine install script as it doesnt find the windows registry when installing wine with an existing windows installation. As Dimitrie said, that means if delta is negative then 1, if positive or 0 then -1. The general form is booleanexpression?then:else Shane To drink the WINE of success you must first seek the sayings of source. hehe.. how true. Do you know the author of that quote? We should put it on the webpage. -Dave
Re: common controls updown patch
On 2002.01.14 14:45 Shane Shields wrote:
hi all
this is just a little patch to fix the UPDOWN_GetArrowRect function where
the
midpoint is calculated by adding 1 to odd numbers. before it just added 1
to
every number now it tests for odd numbers before adding.
Shane
Thanks Dan for the tips
Changelog:
Shane Shields [EMAIL PROTECTED]
updown.c UPDOWN_GetArrowRect function
added odd number checking
--- ./dlls/comctl32/updown.c.orig Mon Jan 14 20:35:07 2002
+++ ./dlls/comctl32/updown.c Sun Jan 13 17:28:18 2002
@@ -1,4 +1,4 @@
-/*
+/*
* Updown control
*
* Copyright 1997 Dimitrie O. Paun
@@ -176,14 +176,16 @@
* round the uneven numbers by adding 1.
*/
if (dwStyle UDS_HORZ) {
-len = rect-right - rect-left + 1; /* compute the width */
+len = rect-right - rect-left; /* compute the width */
+if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */
if (incr)
- rect-left = rect-left + len/2;
+ rect-left = rect-left + len/2;
else
rect-right = rect-left + len/2;
}
else {
-len = rect-bottom - rect-top + 1; /* compute the height */
+len = rect-bottom - rect-top; /* compute the height */
+if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */
if (incr)
rect-bottom = rect-top + len/2;
else
The remainder of any even number divided by two is 0, the remainder of any
odd number divided by two is 1.
Knowing this doesn't:
len+=(len%2);
make more sense. Leave the comment as is for clarity if you wish.
-Dave
Re: user32.TrackMouseEvent
On 2002.01.15 11:37 Rein Klazes wrote:
hi,
to implement user32.TrackMouseEvent:
Changelog:
dlls/comctl32/ : commctrl.c
dlls/user/ : user32.spec
windows/: input.c
include/: winuser.h
Move the implementation of comctl32._TrackMouseEvent to
user32.TrackMouseEvent and call this function in accordance
with the specs.
Man, it must not be my week.
I did the exact same thing two days ago ('cept I put the TME stuff into
windows/tme.c instead of adding it to input.c).
Was part of making IE work as mentioned in my last mail regarding the
stumbling block I hit with DPA that Aric has figured out.
That'll teach me to leave patches sitting around in my tree for a couple
days.
-Dave
Re: DOSFS_ToFCBFormat Bug Fix
On 2002.01.14 13:21 Francois Gouget wrote: On Mon, 14 Jan 2002, Ove Kaaven wrote: On Sun, 13 Jan 2002 [EMAIL PROTECTED] wrote: Change Log: files/dos_fs.c [EMAIL PROTECTED] Fixed bug in DOSFS_ToFCBFormat which caused * to parse as *. instead of as *.* This sounds like intended behaviour. Under real DOS, * really means *.. The user must type *.* to get all files. (This is the stuff that used to confuse DOS users converting to Linux - *.* no longer meant all files...) Strange because if I open a 'dos box' in Win95 or NT4, and I type 'dir *' I get a list of all the files, including those that have an extension like autoexec.bat. Yup! With long filenames windows treats the extension like UNIX does. That is a dir * will in fact show all files in the directory when command.com is running under windows. When it's not running under windows a dir * is equivilent to a dir *. As for dir *.* showing filenames not containing a dot... well, I think this is because short names are still around and therefore when you look up the file as an 8.3 name *.* does match it because a file named FOOBAR will have the shortname equivilant to FOOBAR. Anybody know what happens under NT if you turn off short name generation, then make a file named foobar and then do a dir *.* in that directory? I am guessing MS has this figured out and when the windows APIs see *.* they convert it to a simple *. Of course I could be wrong and it may in fact simply not show the file since *.* would not match it by standard wildcard rules as it has no shortname with an implicit dot and the longname doesn't contain a dot. Should be simple enough to test. Load up NT or 2k, mod the reg to disable short filenames, reboot, make the file then do a dir /x (I think it is /x) to show both long and short filenames and verify it does not have a SFN. Then dir *.* and see if it finds it. -Dave
Re: How about sponsoring from IBM?
On 2002.01.11 14:49 Roland wrote: At 07:57 PM 1/11/02 +0100, Joerg Mayer wrote: It looks like IBM spends its money on the products they themselvs use heavily, as well as training and making the name of Linux more popular (aka advertising/PR). Hmm, I think 10 Million on WINE would do more advertising on the long run by attracting Windows Users and spreading the word, then the same amount spent on ads. If you really want to make Linux popular, running Windows software is the way, think about all the apps and games!!! hahahhahahahahaahahahahahahaha Sorry, ROTFLMAO, see below. I may have missed it but I haven't seen IBM spend money on a Linux(related) project just to further the project. If they wanted to spend $10e7 just to improve programs/tools just for the good of it I would be sad to see this money spent on wine. I'd like to see it spent on the development/improvement of *native* Linux apps that fulfill the need of current Windows users. Well, you have two options: 1. Spend money on thousands of native Linux apps to capture the Windows users. 2. Spend money on ONE native Linux app(WINE) to make it run thousands of Windows apps and attract the corresponding users. I think option 2 is the more intelligent and cheaper option. Read up on your computer history a bit son. OS/2 ran Windows apps, and from about version 2 upwards ran all DOS and Windows stuff perfectly (except for the Win32s stuff). I am sure IBM does /not/ want to make the same mistake again. However WinOS/2 actually was running Windows 3.x. In fact, the technology was extremely similar to SCO Merge (which now has offspring-- Win4Lin). One nice thing it could do that win4lin could not was actually put toplevel windows onto the desktop directly (though they still had the win31 look). This would look similar to running Wine in non-desktop and non-managed mode, although the windows actually were managed by OS/2. Some people would argue that had IBM comitted to supporting Win32 stuff that OS/2 would still be around. Of course the bottom line is that the way they were doing this meant MS got the money for a copy of Windows every time someone bought OS/2. Not good. Wine wouldn't have that problem assuming it would be using all wine DLLs. As for IBM investing in Wine. I suppose there are a couple things they could do. For one, they could somehow use the $10e6 you suggest but who would they pay it to. What might be more helpful is if some of the guys and gals that wrote OS/2 would help out with Wine. They would probably be extremely familiar with Win32 seeing as how OS/2 was originally a joint MS/IBM project which MS got out of when they hacked Win3.0 to support virtual memory on a 386 and decided to make NT. Now while the NT kernel was developed by former VMS guys and gals from DEC, some of Win32 resembles OS/2 because some of those developers went on to work on NT. Which by the way no-one has confirmed that MS ever said it actually stood for New Technology.. more likely it stands for Nice Tits, but that's another story. Anyway, the bottom line is that IBM is not going to start throwing money at stuff. They made that mistake with OS/2 and look where that got 'em. No, IBM spends money when and where it helps their bottom line. Taking down MS does not help their bottom line. Building their own services does help their bottom line. IBM could care less if everyone could run Windows software on Linux. They are in the business of providing the totally integrated system. Running 3rd party stuff is usually not a top priority. Note that IBM has already caught the eye of MS with IBMs ad campaign for moving onto 390 systems running Linux. Some of those internal MS memos recently released are really anti-IBM. Right now I think MS is at the point where they have competitors. They can go after companies using Linux just like they have gone after companies in the past. They are also going after various IT admins who use Linux for certain tasks suggesting that MS software is better for everything. Of course anybody that tells you that one system is better than all others is full of shit, but hey, it sounds good to some managers who don't want to listen to the people they have working for them. Let 'em waste their money on MS. When it breaks, let 'em waste more money on moving it back to what worked. MS is going to shoot itself in the foot soon enough, no need to bring out your own shotgun. -Dave
Re: The most likely way to get IBM to sponsor WINE development
On 2002.01.11 23:01 [EMAIL PROTECTED] wrote: I've been following this discussion with some interest. I am a former Iris/Lotus/IBM employee, and I now run the Winecentric pages www.winecentric.com, basically a faq on how to run Lotus Notes and other programs under WINE. I have had unofficial conversations with Lotus product development managers; they have reacted to customer requests for the Lotus Notes client on Linux by doing their own testing, and they even publish an official page outlining how to run Lotus Notes with WINE. They don't offer customer support (that would cost millions). The best way to get IBM to sponsor WINE development is to persuade them to port their flagship applications to Linux. IBM/Lotus have a long history of using API translators to port products across platforms, including Lotus Notes and SmartSuite. Hmm, I almost forgot about that in my other mail.. When IBM ported the Lotus stuff to OS/2 they /DID/ write Open32 to do this. However Open32 is not (and was never supposed to be) the full API. Thus why Odin exists. Originally designed to build on top of Open32 I think they gave up on that goal long ago and started borrowing code from Wine. In fact, lately one of the Odin developers mentioned he would be willing to release any part we of it we would like to the Wine project under the Wine license. Might be worth a look. If they were persuaded to port, say, VisualAge for Java and SmartSuite, using Winelib, we'd gain some new applications plus (hopefully) IBM would contribute any Winelib enhancements back. Yes, this is how they could probably best help the Wine project, their business, and Linux in general. Remember that IBM is all about providing the best experience for the customer (at least making it seem like they are :-). They also seem to be all about embracing (but not smothering) open standards. And furthermore above all they seem to be about interoperability. IBM had made numerous mistakes trying to lock people into IBM stuff but couldn't do it successfully (MS has really beaten them here, much to IBMs disappointment I am sure). OS/2 was basically nothing more than an attempt to lock everyone into IBM computers running IBMs OS. That follows on the heels of IBMs long history of locking people into IBM tech. I think the absolute failure of OS/2 was really the turning point for IBM. Now IBM seems more interested in not being a slave to anyone and not making anyone a slave to them. I think this is why Linux is so important to them. Ah well, it'll be interesting to look back at this mail in 5 years or so and see what has happened. Probably MS will have completely dominated everything except for the people who are using Linux because they like it and always have (i.e. the people on this list for the most part). Of course you know what they say... the bigger they are... the harder they fall. -Dave
Re: IBM, Notes, Wine and (necessary) version numbers for wine
On 2002.01.12 09:20 [EMAIL PROTECTED] wrote: Hi there, One of the better ways to show the potential to IBM would be to find one of their apps that *does* work under WINE and get it demoed to their management. Although it sounds like some of them are already (internally) using Notes under Linux? Let me use your message to speak about a feature of the wine developement model that's starting to annoy me: using date-version instead of a proper version number for the snapshot. I know I'm in no position to get annoyed by anything, since Iìve contributed no code or useful hints so far :-), but I'd really like to see this change. We all know Wine is evolving rather fast, and every 'n' months a major subsystem gets rewritten to be able to implement it the right way, windows speaking, or because the old implementation was only partially complete. That's not a problem, since this way wine becomes better and bettter. Where the problem is, however, is that I can't know when these changes, that usually bring forth major breakages in some/many applications, are done. I've been following wine-devel and wine-cvs and, back in June (IIRC) when the windows handling code was changed, I wasn't too surprised when Lotus Notes stopped working (and it's still broken in many ways, window repainting for example). Too bad SuSE people didn't follow the lists, and going from version 7.2 to version 7.3 of their distro, they upgraded their wine rpm package from 20010326 to 20010731. With the new version, notes doesn't start at all... I ask: isn't it about time to use version numbers, like in the linux kernel? I now you are working toward 1.0 release, but I guess some 0.6.x (stable) 0.7.x (unstable), 0.8.x (stable again) coudn't hurt, and this kind of versioning give hints to people on where to go and what to download if they want something stable or if they want the newest. Absolutely not. Check the archives, I think this has been discussed before. Wine is a relatively small developer community. No one here is interested in creating a code fork and doing only bug fixes in one branch to try to make a stable release while doing the major development in another tree. What we want to do is do major development on one tree, period. That is at least until we feel that Wine is even CLOSE to finished at which point we will work towards a 1.0 release. I think it's important to let wine users understand if the package they are about to install is a stable, well tested version, or an extremely new, developemental and untested version. In my opinion, some snapshot (like the April 2001 one) are definitely beta quality, so I think it's useful to let people know this, especially at a time like this when the Lindows people are saying we fixed wine, going from alfa to release!... I'd really like to know from which snapshot they started... Personally I would not consider a completely broken hacked together USER* that happens to work of beta quality. We would be wasting our time fixing bugs in the old versions. Let some company do that (i.e. Lindows). Ciao, Roberto Hmm, is that a blatant reference to the movie The Waterboy w/ Adam Sandler.. or just pure coincidence. P.S. I hope to be more useful in future, since I'm starting my own business that will be based rather heavily on Linux, and this way I hope I'll be able to search and destroy the most annoying bugs I find.. :-) Good luck. -Dave
Re: Lindows screenshots AND THE WINE LICENSE
On 2002.01.10 12:25 Roland wrote: [snip] But there are more dangers for the WINE license. It would be possible for a company like Lindows hire away all WINE developers, effectively hijacking the project. Alternatively if Lindows becomes a success it will be able to hire more programmers and keep improving their own version of WINE, so that it would always be much better than the free WINE. I wonder why this didn't happen to FreeBSD. First of all, licensing has been discussed to death and will remain as MIT for the forseable future. Although I note you are not arguing this.. just throwing this out. Personally I would not want to work for a company that took free software, fixed or hacked around some major bugs, and sold it for $100 a copy. While I couldn't speak for the other Wine developers I feel that many of them would not be willing to do this. Look at CodeWeavers and TransGaming. CW sells the service of porting an application from Windows to winelib. For their business to function properly they need a Wine which works well. It is true that since they contribute most of their modifications back (with some very minor exceptions) someone /could/ compete with them. However, if you were a company who was going to contract out the porting of your windows application, who would you trust? Some newcomer to the field with no reputation or a company who employs top Wine developers? And in the event that someone does enter the market successfully... well, more power to them. Jeremy has stated several times that contributing CW modifications back to Wine is actually in his best business interest as it means he does not have to deal with a totally overmodified tree and instead reaps all of the benefits of free software including people who build on his work and contribute that to the Wine project. According to Jeremey, moving to a GPL license could potentially help CodeWeavers (see previous mails in the list archives). TransGaming sells the service of enhancing Wine to run popular games. Contributing all of their modifications back to Wine would mean no one would want to buy their product when they can get Wine for free. Contrast this with CW who have already been paid for the work (or at least have a contract to be paid). However, TransGaming does still release their source under a non-free license which at least gives the user some freedom. For TG, moving to the GPL would be very disastrous to their business model, well, there was some debate on how disastrous it would be, but it would harm them in some ways. Now look at Lindows. Basically they want to take the work that many people have spent a lot of time creating and essentially steal it for their own benefit. I am gonna laugh though when Wine is actually good enough that their modifications have no value over Wine. Plus, it's not exactly as if Lindows is a new idea. MANY people have proposed this exact same idea (including myself I think). Let's look at what exactly Lindows has done: 1. They added the Windows programs menu into the KDE menu. Big deal, trivial. 2. They made KDE look as much like Windows as possible. Again... big deal. 3. They fixed some bugs with Wine. Or at least hacked around them (more likely) to make popular applications work. Trust me.. getting MS Office 2000 working is no big shit. Neither is IE. Both of these programs almost work with a few crashes and a few native DLLs. Assuming they are using wine dlls then one thing I assume they did was fix the common controls stuff to look right. This part is not trivial, but not unreachable either. Is $100 really worth it? I thought that was a joke when I saw it. They've been developing this for what.. a few months, half a year maybe? It still crashes, and I'll bet if this goes on the market and office crashes a lot of people are going to bitch about the stability of Linux, when really it's because they are using alpha software (Wine). Sorry about the rant, just had a few things I wanted to say. -Dave
Re: Changes regarding wnaspi32 layer ?
On 2002.01.10 14:06 Martin Hoffmann wrote: Mhhh, must have been an issue with a not properly installed Wine on my machine ! As you told me i ran some tests: First with the working 20010731 build ! Then i decided to switch to cvs from 20011226 and did ./tools/wineinstall ! Guess what, it was not reproducable :-/ With the fresh compiled cvs from 20011226 it works, too ... So, i can only imagine that last time i installed a newer version i must have mixed up anything (or had a bad rpm - this time i compiled my own !) Thank you anyway ! For me it's solved... (being happy) Martin Speaking of which, I highly recommend you use CVS and configure with --prefix=/opt/wine-cvs (or something similar). Then add YOUR_PREFIX/bin to your path and YOUR_PREFIX/lib to your /etc/ld.so.conf. Then if you ever need to be sure you have a fresh copy of wine: rm -rf /opt/wine-cvs make install Thanks to Jeremy for this suggestion (in fact, I think the CodeWeavers RPMs do this, or at least did IIRC). It's a hell of a lot better than having wine strewn over /usr/local along with the rest of your programs compiled from source. Glad to hear that you got ASPI working. Especially because I could see no reasonable explanation for why it wouldn't work between the wine releases you gave given that no major updates have been made to ASPI since Andreas Mohr fixed some bugs with the /proc/scsi/scsi parsing in my code among other things. Hehe.. actually, had people not had broken SCSI devices with a space as their first character this would not have been an issue. -Dave
Re: We *really* need a development model change !
On 2002.01.02 14:12 Jeremy White wrote: [big snip] 1. Cygwin installation has *dramatically* improved. Getting a full working toolchain is no longer a big pain in the rear end, it's actually pretty easy. [big snip] Well, as I mentioned the other day... I have recently built a linux cross mingw32 toolchain with the latest released binutils (maybe I should upgrade that, seems the mingw people also use a newer unstable binutils) and the latest released gcc (3.0.3) along with the MinGW w32api and mingw-runtime packages (both version 1.2). There were a few issues such as building with multithread support that crept up into the build process and thus I have some patches for that if anyone is interested. Most of them patch the configure scripts and so on so that it uses threading for the target environment instead of trying to compile posix threads. I will be contacting the MinGW team about this shortly. -Dave
Re: Mixed-mode CD Labels
On 2001.12.30 03:34 Chris Green wrote: If anyone has an odd CD lying around, they can email me the first 65536 bytes of the CD (hopefully no vendor will care about copyright on their volume descriptors!) so I can compare the structure of the volume descriptors - I've got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 count=1' and compress the result before emailing it to me :) hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? Maybe it doesn't make a damn bit of difference, but as the blocksize on cds is 2048 bytes I think it makes more sense to say gimme the first 32 2048-byte sectors. -Dave
Re: Mixed-mode CD Labels
On 2001.12.30 05:10 Chris Green wrote: On Sunday 30 December 2001 20:04, you wrote: got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 count=1' and compress the result before emailing it to me :) hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? Maybe it doesn't make a damn bit of difference, but as the blocksize on cds is 2048 bytes I think it makes more sense to say gimme the first 32 2048-byte sectors. six of one, half-a-dozen of the other :) they give the same data, I just often go for large block sizes and smaller counts - some read-ahead type operations run faster, I find, if you do that. I don't mind either way :) Duh! For some reason I was thinking the other way around... i.e. If you specify the blocksize as less than what the blocksize is (or not on an integer multiple of it) then you run into issues. You are correct, specifying it as 64kiB (gotta love the new SI standards, hehe) would actually increase the reading performance, not decrease it. -Dave
Re: We *really* need a development model change !
On 2001.12.30 15:34 Alexandre Julliard wrote: 2. The scripts are independent from the compilation environment, which allows testing binary compatibility. In C you have to compile the tests under Wine using the Wine headers, which means you can't spot wrong definitions in the headers since the test will see the same definition as Wine itself. The only way around is to build tests under Windows and run them under Wine but this is a major pain. With a script you are guaranteed to run the exact same thing in both environments. Well, if it helps any, I have recently built a linux-cross-mingw32 toolchain as RPMs. For those not running on an RPM distro the specfiles should be easy enough to understand and do manually. For those who are running RH7.2 (and probably 7.1 as well) you can have the binary packages. And for all other RPM distros the source RPMs should build without problems. I have the following RPMs built: i386-mingw32-binutils-2.11.2-0_biscuit_0 i386-mingw32-gcc-bootstrap-3.0.3-0_biscuit_0 (built from the same specfile as the normal gcc but only makes a C compiler good enough to build w32api and mingw-runtime properly). i386-mingw32-w32api-1.2-0_biscuit_0 i386-mingw32-mingw-runtime-1.2-0_biscuit_0 All the rest are part of the gcc build: i386-mingw32-gcc-3.0.3-0_biscuit_0 i386-mingw32-gcc-c++-3.0.3-0_biscuit_0 i386-mingw32-libstdc++-devel-3.0.3-0_biscuit_0 i386-mingw32-gcc-g77-3.0.3-0_biscuit_0 i386-mingw32-gcc-java-3.0.3-0_biscuit_0 (unfortunately it didn't compile the java runtime, so this one is useless until I figure that out) If anyone is interested in this I can probably put it in kernelrpm.sourceforge.net temporarily before I contact the MinGW team and see if they would be interested in hosting these files on their sourceforge site. Please note that this is not just a simple compile. I had to do quite a bit of patching (well, figuring out what to patch was the issue, the patches are tiny) to get it to build and work properly even including thread support. I also have compiled wxMSW with this compiler and successfully built and tested the minimal, mdi, and taskbar test programs. Of note is that the MDI program does not show any icons in the toolbar when run under Wine, but works perfectly under Windows (95osr2 in Win4Lin). Is anyone aware of this, might be related to IE5.5 displaying black squares instead of icons in its toolbar, and would be significantly easier to debug as I built all of this with debugging info (assuming winedbg can read it), plus you'd have the full sourcecode from wxwindows.org. -Dave
Re: Windows screensaver.
On 2001.12.23 11:10 Gleb Natapov wrote: Hello all, Perhaps this was asked before, but I didn't find the answer. Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this? Well, there are a few issues: 1. Loading wine takes forever on my box (although this will be fixed in about a week when I get a dual-athlon setup). Not an ideal solution to the speed problem in my mind.. but works for me. 2. You can already run most screensavers using: wine using wine /path/to/screensaver.scr /s An .scr file is essentially just an .exe that has been renamed. The /s switch tells the screensaver to actually run as a screensaver. Without it it will open up the configuration properties for the screensaver. 3. You'll notice that when you run the screensaver like this that it will appear on top of all other windows and when you move the mouse it will go away. That is, the screensaver itself takes care of putting itself above all other windows and will dismiss itself when it gets an event such as mouse move or button press or whatever. XScreenSaver doesn't work this way. You'll notice that most of the commandlines in your .xscreensaver file have the -root option. That means draw in the root window which if you run that by itself (i.e. outside of xscreensaver) you'll notice that it will in fact draw to the root window (i.e. your desktop background). Also, moving the mouse around does nothing... the program simply draws stuff on the screen and absolutely does not handle dismissing itself like a win screensaver. XScreenSaver creates a virtual root window on top of everything which it then runs the screensaver program in. That way the screensaver program still thinks it is just drawing in the root window, but in reality it is drawing on top of everything. XScreensaver also takes care of dismissing the screensaver when you move the mouse. I believe it does this by sending it a signal of some sort, although I am not entirely sure. You really ought to read its documentation to get all the specifics on this. However, you /can/ add a line that runs wine to run the screensaver in your .xscreensaver file. In fact, I just tried this. If you run in demo mode you get the expected behavior, it won't go away until you click a button. If you set it as your screensaver and do a normal blank (i.e. not lock) then it'll go away when you move the mouse. However, if you do a lock screen it'll clear the screen to black when you move the mouse, ask you for your password (which for some reason it didn't accept the first time, but maybe I just typed it wrong). Anyway, once you type a valid password you are still looking at the screensaver until you move the mouse again. So basically it already does mostly work. One way to decrease the startup time would be to start the wineserver in persistent mode before hand. Then the first time you load the screensaver (or some other windows app) it'll take a while, this is because the first client to connect has to set some stuff up. However, after that the wineserver is running and ready to go so it doesn't take very long for the screensaver to start up. (I just checked this, and that is what happens). One thing you could maybe try to do to decrease this is make a very lightweight wine configuration in a different directory. You can use the WINEPREFIX environment variable to do this. With a bit of configuration you could have a wineserver running permanently listening on a socket in $WINEPREFIX instead of in the usual ~/.wine directory. Also that way when you run windows apps it doesn't affect your other wineserver. As far as fixing the behavior goes, I have a few ideas. Wine supports a Desktop mode where a desktop window is created and all wine drawing is done to that window. You could maybe change wine a bit to allow wine to draw into an already created desktop window (e.g. draw into the root window). That might make things behave a slight bit better. In fact, doing that alone might fix everything. And I also think that doing that should be simple (and maybe there is already a way to do this). Hope that helps you to figure it out! -Dave
Re: Installshield 6 (inter-proc) patches. LGPL hole.
On 2001.12.19 11:43 Dan Kegel wrote: [BIG SNIP] Thanks for explaining what Patrik has been going on about. In summary: Consider a proprietary application which ships as a proprietary library which is statically linked with LGPL libraries at install time in a way that lets users supply new versions of the LGPL libraries. This lets them fix bugs in the LGPL'd code and thus in the proprietary app. The harm you see is that a vendor could, once he found a Winelib function with a bug, simply do his own clean-room implementation of that function, and use it instead of the Winelib version of it, and keep the improvement to himself -- which would also deprive the user of the ability to fix bugs in the proprietary reimplementation of that particular WineLib function. Did I get it right? - Dan Well, you got my argument right. -Dave
Re: Installshield 6 (inter-proc) patches
On 2001.12.19 12:22 Patrik Stridvall wrote: [SNIP] That is my argument that avoids all of Patrick's doctrine of derived work crap and gets right down to the fact that it's trivially easy to make your work fall under the work that uses the library category, so long as it is a seperate object file. That is, to put it in Slashdot terms, a Big Gaping Hole(tm) ..but you are wrong that just because it falls under use, it is clear from the doctrine of derived work. That is the main problem, I have with it. That it might potentially turn somekind of uses into derivation and thus potential infringement of copyright. Nah, see next section. Look at section 5 in the LGPL. If you use (from the header files) only numerical parameters, data structure layouts and accessors, and small macro and inline functions then regardless of whether it would be considered a derived work it remains a work that uses the library. So that's great, after I had pretty much convinced myself that the LGPL was still good despite some minor problems, I now find myself realizing that the LGPL has major holes written into it! Welcome to the club. :-) Seems to me that section 5 pretty much takes care of making sure that things which use the work are not considered derived works. So IMHO the LGPL is basically nullifying the doctrine of derived work. And so I emphasize my original statement now. The only thing the LGPL really prevents is the direct use of the source code. Anyone wanting to release a proprietary implementation of any function can do so fairly easily simply by 1) writing that particular function from scratch, and 2) keeping it in a seperate object file. Agreed. Try reading section 2C of the LGPL and tell me how it's good for commercial companies. To respond to Roger: I fail to see how 2c makes any difference. It only applies to derived works and only means that you have to release the code. Yes, it only applies to derived works, but since it is pretty unclear what a derived work is makes it quite unclear for commercial commpanies what that are legal forced to release or not that can't possibly be good when they are deciding whether to use Wine. I now think I know why GNU does not want people to use the LGPL. It's basically a useless license for all but a certain specific type of project. That specific type of project would be something like glibc. Where the interface is clearly defined and the implementation is good and needs to be free software. Wine is actually very similar in concept to glibc. I remember a few mails back I suggested that the real goal is to make sure the base system is free software because no one can expect people not to write proprietary applications. And I don't think it would be good to not have proprietary applications (unlike RMS's views). However, I consider Wine to be part of the base system since it's really not an application, but basically does for Windows applications what glibc does for POSIX applications: provides a free version of the API. So far the discussion as seemed to center around licensing Wine as a whole. Would maybe licensing certain specific DLLs be a better idea? For example, would licensing the really core libraries as LGPL (i.e. kernel, user, gdi) be a good start? Make each library have its own LGPL license. Or maybe should we keep all the libraries as X11 and make the emulator itself full out GPL? Wine is many many peices. I think to try to place the same license over the entire project is absurd, except in the case of our current X11 license. -Dave
Re: Installshield 6 (inter-proc) patches
On 2001.12.19 12:32 Alexandre Julliard wrote: David Elliott [EMAIL PROTECTED] writes: Now, here's another something to mull over. We've pretty much established that you could statically link something proprietary with something LGPL. One question I have is how much of the library are you allowed to use. Alexandre mentioned that while the CryptoAPI example would be a pretty clean-cut allowed case, a proprietary CreateWindow would not be allowed. His argument was that because it would necessarily use internal functions and data structures that it would be a derived work and thus subject to the license. Actually the fact that they are internal or not doesn't make a difference, I wasn't clear on that point. If your code is linked to the library it is considered a derivative work, and by default the whole has to be released under the LGPL. Now there are cases where you don't need to do that: one is if your app is considered a work that uses the library (section 6), the other is if you are placing your code side-by-side with the library (section 7). So if you don't want your code to fall under the LGPL, you have two choices: one is to put it in some part of your app that only links to the library, but in that case you cannot have other parts of the library depend on your code (this is the square root example). This would work for the crypto API, probably not for CreateWindow since the rest of user32 needs CreateWindow. Okay, that makes a bit more sense. Although couldn't one argue that it still does work since it could fall back to the original LGPL createwindow? The other solution is to put your code side-by-side in the library; but this is only possible if your code is not covered by the license, which means it isn't a derivative work of the library, which in turns means it cannot use any functions or data (exported or not) of the library. This would work for the crypto API as long as you don't use anything from the rest of libadvapi32. Right. -Dave
CryptoAPI (no, this has nothing to do with licensing! YAY!)
A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again. The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves. At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project. At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything. What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely. Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff. As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there? In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded. -Dave cryptoapi_20011219_dfe.diff Description: Binary data
Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
On 2001.12.19 20:08 Alexandre Julliard wrote: David Elliott [EMAIL PROTECTED] writes: What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely. Is this rsabase.dll? If so this is because of a problem with LOAD_LIBRARY_AS_DATAFILE; I have a patch for this somewhere. -- Alexandre Julliard [EMAIL PROTECTED] Actually, rsaenh.dll. I am running IE 5.5 and accessing https://internetbanking.suntrust.com/. Not that this site doesn't work with Galeon anyway, but it seemed like a fairly simple way to test the crypto functionality. Running wine --debugmsg +crypt IEXPLORE.EXE I get: [...] trace:crypt:CryptAcquireContextA (phProv=0x7741b7d4, szContainer=(null), szProvider=Microsoft Enhanced Cryptographic Provider v1.0, dwProvType=1, dwFlags=f000) trace:crypt:CryptAcquireContextA Provider is Microsoft Enhanced Cryptographic Provider v1.0 trace:crypt:CryptAcquireContextA DLL is rsaenh.dll trace:crypt:CryptAcquireContextA Signature is 136 bytes long trace:crypt:CryptAcquireContextA Type is 1 trace:crypt:CRYPTOAPI_LoadCSP ImagePath=rsaenh.dll trace:crypt:CRYPTOAPI_LoadCSP pCspInfo-ImagePath=rsaenh.dll err:crypt:CRYPTOAPI_LoadCSP Could not LoadLibrary 1114 err:crypt:CryptAcquireContextA Could not load CSP trace:crypt:CryptAcquireContextA (phProv=0x7741b7d4, szContainer=(null), szProvider=Microsoft Enhanced Cryptographic Provider v1.0, dwProvType=1, dwFlags=f000) trace:crypt:CryptAcquireContextA Provider is Microsoft Enhanced Cryptographic Provider v1.0 trace:crypt:CryptAcquireContextA DLL is rsaenh.dll trace:crypt:CryptAcquireContextA Signature is 136 bytes long trace:crypt:CryptAcquireContextA Type is 1 trace:crypt:CRYPTOAPI_LoadCSP ImagePath=rsaenh.dll trace:crypt:CRYPTOAPI_LoadCSP pCspInfo-ImagePath=rsaenh.dll err:crypt:CRYPTOAPI_LoadCSP Could not LoadLibrary 1114 err:crypt:CryptAcquireContextA Could not load CSP [...] I just tried running with +crypt,+relay and I get a crash before the main window comes up (with the non-drawn splash screen above everything) in INT21_FindFirstFCB on line 788 which is else pFCB = (FINDFILE_FCB *)fcb; For some reason I cannot use the enter key in the console and trying to paste an enter from another window doesn't work either. So using the debugger does not work, hitting Ctrl-C in the console does work though. Is this a problem other people are having? I would have thought someone would have reported it by now if that was the case. Anyway, if you think the patch you have might help me get RSAENH.DLL loaded and a bit further then I could probably have https sites working in IE shortly. In any case I think if I just look over this code a little bit and make sure there are no absolutely glaring errors there should be no reason not to put it in the tree, even if it can't actually load a real CSP for some other reason. -Dave
Re: Installshield 6 (inter-proc) patches
On 2001.12.18 05:09 Patrik Stridvall wrote: [snip] Dimitrie O. Paun wrote: Stop for a movement and tell me: are you against the letter or the spirit of the LGPL. Asking that question is like asking whether I support the spirit of Communism: From each according to his abilities - to each according to his needs. Well, it sound nice doesn't it? However doing a little deeper analysis I realize that the price for being able to do this is not worth paying. Note however that I'm not equating GPL or LGPL with Communism. It was just an example from real life, that you get more that you wish for. See below. [snip] That's a piss poor example. The statement that something would be from each according to his abilities and to each according to his needs sounds to me at first glance like it would suck. And you don't have to dig too deeply to figure out why that would suck. But maybe that's because I am an American capitalist though and through and that blatantly conflicts with my core values that everyone should do for themselves. And to get off topic, why is that? Because that's what everybody will do anyway, might as well work with that rather than pretend that it is otherwise. This has lead me to another thought. We cannot pretend that people are going to release code back to Wine under the X11 license. However we can realize the obviousness of the truth that given the chance people will take whatever they can and give back nothing in return. Some folks will give back because it may make more sense to do so than to not. But some folks will be more than happy to take the whole codebase for their own good and provide nothing in return. We need to stop living in the dream world that everyone who uses Wine will contribute back. Yes, it is true that Corel, Codeweavers, TransGaming, etc. have given a lot to Wine. None of them was or is required to give anything. If the goal is to let people know that if they want to use Wine then they need to contribute back, then the only choice is to put that into the license. By use I am obviously not referring to simply porting an application using Winelib. I am referring to incorporating source code from wine into their own products. This is exactly what the LGPL was meant to address. I recall Uwe's usual .sig which is: Free Software: if you contribute nothing, expect nothing. Maybe we should have one for wine: Wine: If you contribute nothing, well, there isn't shit we can do about it since we are X11 licensed. -Dave
Re: Installshield 6 (inter-proc) patches
On 2001.12.18 06:13 Geoff Thorpe wrote: [BIG SNIP] The rest of the suggestion I would like to make may seem somewhat surprising; dual license this BSD+adv-clause with the GPL. Not LGPL, but GPL. GPL is an enormous hunk of trouble I know, but under a dual license you're only bound by it if you choose to use it instead of the alternative. Umm, didn't I suggest dual-license Original BSD (w/ Advertising Clause) and LGPL in one of the first mails of this thread Or maybe I was thinking that and never actually sent the mail out. Now why you would want to dual license Original BSD/GPL is beyond me. GPL is just simply not at all suitable for Wine. Honestly, the dual-license Original BSD/LGPL seems very ideal to me. TransGaming could continue business as usual. Any future users of Wine would be required to disclose the fact that they were using Wine (which IMHO is a good thing) and we would still remain (L)GPL compatible since we would also be licensed as LGPL. This dual licensing also has the advantage that it would put Patrick's arguments to rest since I could not see any person or company willing to push the LGPL to the limits simply to remove an advertising clause. Although I am sure Patrick will be more than happy to come up with an ongoing argument against this. The only disadvantage to this method is that it really doesn't give us much protection. The only thing it offers us is that people who want to avoid the LGPL will have to make it known that they did so. If we do go this route, I would highly suggest specifying a very prominent advertising clause. That is to say something like anywhere the application displays information about itself it should include a phrase such as developed with Wine technology, visit http://www.winehq.com/ for information. Examples of places would be splash screens, about boxes, etc. for GUI apps and maybe a line or two output for CLI apps that already display their name in their output. E.g. a CLI tool known as Foo application might display: Foo Application v1.0 Copyright 2001 Bar Corporation Developed using Wine technology, visit http://www.winehq.com/ This would also hold true for something like Lindows. During startup I assume it would display something like Starting Lindows so it should also be required to say something like Developed using Wine technology, etc... Companies or individuals who would prefer not to have the advertising clause can simply abide by the LGPL license. -Dave
Re: Installshield 6 (inter-proc) patches
On 2001.12.18 23:43 Dimitrie O. Paun wrote: On Tue, 18 Dec 2001, Roger Fujii wrote: Dimitrie O. Paun wrote: Technicalities aside, the LGPL spirit seems to be accepted by most people. I have no problems with the 'spirit' of the GPL (or at least, how most (ie, minus rms) people sees it). Excellent. In fact, I disagree with RMS violently, I've read the link you sent me (about the glibc takeover) a long time ago. But this is why we have to separate out intentions from fact. Or semantics from syntax. Or whatever you want to call it. In other words, we can use the LGPL even if we disagree violently with RMS. Just like Linus chose the GPL for Linux, even if he can't even talk to RMS. We've heard no end of discussion of what represents the code, and so on, but in reality (please Patrik :)), Wine is a _well_defined_ piece of software. The problem is that it is *not* a 'well_defined' piece. Is it a library? An app? You run it as an app, but the executable you're running it with thinks it's a library. Or is msword (or whatever you're running) now a library. I can see rational arguments either way. That's a separte problem. Is your claim that we can't use the LGPL because we can't define what Wine is??? If this is _your_ problem, I truely belive that can be solved. And the solution is fairly simple: whatever code uses a DLL's internal functions (that is, functions that are not exported in the DLL's spec files), is said to link directly with Wine and thus is subject to the LGPL licence. In fact, Wine is the simplest project to LGPL because its boundaries are defined by someone else! Moreover, these boundaries are fairly well documented and accepted by most of the software industry. Dimitrie, this is exactly what Patrick and I have been trying to argue against. If you read the LGPL it does state that you can statically link as long as you provide the means for your users to statically link with a newer version. One way to do this would be to provide the object files from the compiler, or a .a file with all of the combined objects that can be relinked with a newer version of Wine. The example we have been using is that you could write a proprietary CryptoAPI and link it with the rest of the advapi32 to come up with a libadvapi32.so which includes CryptoAPI. You can call all the functions in the rest of advapi32 (i.e. the LGPL part) that you want to. So long as you provide a way to update the LGPL components you are in the clear. This is covered by section 7 which states that you may place library functions that are a work based on the library (i.e. the original LGPL ADVAPI32) ... in a single library together with other library facilities not covered by this license. The single library would be the libadvapi32 including the proprietary cryptoapi. In order to do this you must a) provide a copy of the work based on the library not linked with the non-LGPL stuff. and b) give prominent notice as usual. Now, here's another something to mull over. We've pretty much established that you could statically link something proprietary with something LGPL. One question I have is how much of the library are you allowed to use. Alexandre mentioned that while the CryptoAPI example would be a pretty clean-cut allowed case, a proprietary CreateWindow would not be allowed. His argument was that because it would necessarily use internal functions and data structures that it would be a derived work and thus subject to the license. I think what Patrick has been trying to get at is that that is not very clean-cut and that in fact there is little to no precedent on what exactly a derived work is. If Alexandre is indeed correct then we are pretty well protected. If it is at the opposite extreme and anyone could statically link in proprietary versions of functions then we have very little protection and it really makes it not worth it to go LGPL. At least that is what I think Patrick has been trying to say. Let me put it to you the way I see it. Whether a function or data structure is exported or not does not matter. It would be trivial to declare an internal structure or function as exported and thus the proprietary function is simply making use of the library and therefore not a derived work. That is my argument that avoids all of Patrick's doctrine of derived work crap and gets right down to the fact that it's trivially easy to make your work fall under the work that uses the library category, so long as it is a seperate object file. That is, to put it in Slashdot terms, a Big Gaping Hole(tm) Look at section 5 in the LGPL. If you use (from the header files) only numerical parameters, data structure layouts and accessors, and small macro and inline functions then regardless of whether it would be considered a derived work it remains a work that uses the library. So that's great, after I had pretty much
Re: Installshield 6 (inter-proc) patches
On 2001.12.13 18:43 Patrik Stridvall wrote: Patrik Stridvall [EMAIL PROTECTED] writes: Umm. I feared that question would come. The protection the LGPL (or GPL) that Marcus proposed is IMHO largely an illusion when it comes to libraries. Sure we might use a strict interpretion as a weapon in a PR campaign against possible voilators but we don't have the resources to sue somebody and I very much doubt we would succed either. I think you greatly underestimate the power of such licenses. That is what remains to be seem. Many laws doesn't make logical sense anymore or becomes inconsistant in the new brave world and the attempts to adapt them often introduces new problems. The attempts of various courts the interpret the uninterpretable inconsistancies, without realizing it, futuremore adds to the confusion. Expect extreme uncertainty to be the keyword for the immediate future. Patrick, is your glass always half-empty? There is no need to be completely and totally pessimistic about everything. Just look at the archives. Almost every argument you have ever made on this list begins with some statement about the courts being stupid or corrupt or something. Really dude, lay off the slashdot for a while. With that said I'd also like to apologize for saying that (but it still needed to be said). Alexandre is correct that you are greatly underestimating the power of the FSF licenses. Remember, the GPL and LGPL and also the X11, BSD, etc. all give you rights that by law you would not have. AFAIK nobody in the world is currently shipping code (except maybe by mistake) in violation of the GPL or LGPL, despite the fact that it has never been taken to court. True, it does have some power because few wants to be named a bad boy, but that might mean less and less in the future. You are deluded if you think companies who have been in this position were only concerned about PR. Companies are concerned about only one thing: money. Any company that is not conerned about money as priority number 1 is broken. Hell, by law they have to be. The bottom line is that someone decided that the cost of bringing their product into compliance with the (L)GPL one way or another was less than the cost of the alternatives. And nobody in their right mind would base a business on shipping illegal code; even if they believed they could get a judge to agree with them, the risk is simply too great. Small changes in a particular DLL then there is no clear boundaries between their boundaries between their code and ours might be risky, true. However, in your example five companies offered one proprietary version each of five different half important DLLs. They might even have an implementation from scratch with no Wine code at all. I can see no difference between for example their DLL and a Microsoft DLL running under Wine, regardless of Wine being GPL or LGPL or whatever. Yeah, you're absolutely correct. If a company wants to from scratch implement a DLL and sell it then they can. Just don't do it with code from Wine. (but see below) Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL. Hmm, let me think here about what the LGPL states. Let's say Advanced Crypto Systems (made up company, hereafter refered to as ACS) decides they want to write a proprietary implementation of the crypto code in ADVAPI32. The LGPL specifically states that you may statically link LGPL code and proprietary code to form a new library provided you follow the conditions. Basically that means the same as usual, that end-users must be able to replace the LGPL part with a newer/modified version given that the interface remains the same. So ACS would be entitled to provide for example a libadvapi32.so file that could drop into an existing wine installation as long as they also at the very least provided their object code before linking it with the rest of wine which would allow an end-user to compile a newer version of wine and link in the ACS crypto support. ACS could instead provide source code, but it need not be under the (L)GPL. It could be under a license only allowing redistribution to people who have a license for the binary. So basically to answer your question: no, it does not violate the LGPL, though it sure as hell would violate the GPL.. But as Alexandre said, the GPL is extremely inappropriate for Wine, and as such I recommend we drop the GPL issue immediately and focus on LGPL. Any protection that (L)GPL provides is to a large part based on myth and legend. In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open
Re: Installshield 6 (inter-proc) patches
On 2001.12.13 12:41 Alexandre Julliard wrote: Patrik Stridvall [EMAIL PROTECTED] writes: In short: Should the Wine project wait until you release or should it not? That's certainly a question we have to think about, but I think there is a deeper issue: should we continue to release under a license that allows people to use our own code to hurt the project? Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it. LGPL would have been ideal except several people pointed out that because it disallows static linking it would be unsuitable for systems without a dynamic linker (e.g. embedded systems). In hindsight maybe we should have gone with LGPL with exceptions to allow static linking like some other projects have recently done. Although I remember something about if you are going to allow static linking you might as well allow people to do what they will with the code because if you can statically link it you pretty much can do what you will with the code. My concern is not so much about Transgaming, I trust that Gav means to do the right thing, even if I don't entirely agree with his methods. But I'm worried that if Transgaming succeeds, it will set a precedent that others will follow, who may have no desire at all to do the right thing for Wine. What will happen if 5 different dlls are improved and released by 5 different companies under 5 different non-free licenses? This is so true. Of course now that the cat is out of the bag maybe a more pertinent question is what happens if we make new code LGPL or some such? Do we still have companies using Wine code but using the older versions under the X11 license? Then we'd really have a mess. Would dual-licensing under LGPL and original BSD make sense? That way other open source projects could use the code, but closed source projects would have to put in advertising for Wine. Of course really, what is the difference. Is anyone going to care that e.g. Lindows uses Wine. Honestly I don't know what to say. On the one hand you have the FSF licenses geared towards promoting free software development. On the other hand you have the current license geared towards allowing everyone to use the code for whatever. Wine is a reimplementation of an existing API. Do we really want to send the message that in order to use the wine code your program must be free software? Or would we rather stick with the current situation that we'd rather have you using our code than Microsoft's? I cannot come up with a reasonable choice here. Either way has drawbacks. We've been through this before and went with the X11 license. Maybe it's time to rethink that decision... maybe not. All I can say is that I for one would like to know how current developers stand on this issue. Has anyone's thoughts/opinions changed significantly? -Dave
Re: Installshield 6 (inter-proc) patches
On 2001.12.13 21:06 Ori Pessach wrote: On Thursday 13 December 2001 18:44, David Elliott wrote: Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it. LGPL would have been ideal except several people pointed out that because it disallows static linking it would be unsuitable for systems without a dynamic linker (e.g. embedded systems). I think it's worth pointing out that the LGPL doesn't force you to distribute shared libraries. You can statically link your own work with a library covered by the LGPL, as long as you provide object code (or source) of your work, allowing a user to relink the LGPL library with your work. Hmm... I remember the LGPL stating that the end-user must be able to relink the application with a newer version of the library. For some reason I also thought it stipulated that in order to achieve that it must be dynamically linked. Although you are correct from a technical standpoint that someone could distribute an object file that is the app minus the LPGL part which would then allow one to relink with a modified version of the LPGL part. Okay, I just read the license and you are indeed correct. So that pretty much gets rid of the argument that the LGPL is unsuited for embedded systems because of the need to statically link sometimes. You must also allow modifications to your work, and reverse engineering for debugging the modifications. Hmm, in other words no EULA clauses stating you can't modify or reverse engineer the binary. I think that is a very acceptable stipulation. That, at least, is my reading of the license. Ori Pessach Thank you for enlightening me about the LGPL. -Dave
Re: Getting Started
On 2001.12.09 17:15 Oliver Sampson wrote: [SNIP] ot Why is the default behavior for the list to have replies go only to the sender and not to the list? /ot Because that would be ridiculous. The only way to really accomplish that is to add a Reply-To which means that it then becomes impossible to easily reply directly to the author. If you don't add it then all you need to do is hit Reply All which will cause it to send it To: the original author, and Cc: it to the list. So assuming you have your mail filters setup such that mail which went through the list goes into the wine-devel mailbox and other mail is processed as usual then you will get two copies: one directly to you in your inbox and one in the list. Personally I prefer this because I can then reply directly to any pertinent things before I go reading the rest of the list. Like this: MAILDIR=$HOME/mail/incoming :0:wine/announce.lock * ^Sender:.*[EMAIL PROTECTED] wine/announce :0:wine/cvs.lock * ^Sender:.*[EMAIL PROTECTED] wine/cvs :0:wine/devel.lock * ^Sender:.*[EMAIL PROTECTED] wine/devel :0:wine/patches.lock * ^Sender:.*[EMAIL PROTECTED] wine/patches That is part of my .procmailrc file which will filter on the sender line (mail that has gone through the list servers). Note that I do not filter on To or CC line as is stated on the website because then anyone who sent mail directly to me but also cced it to the list, well, it goes into the list, which defeats the whole benefit of getting two copies of the mail. Hmm, come to think of it, maybe someone should put those lines up on the WineHQ website as an alternative method, or in place of the current method. IIRC the website is in CVS, would someone want me to send a patch for this? -Dave
Re: Getting Started
On 2001.12.10 16:57 Oliver Sampson wrote: On Mon, 10 Dec 2001 16:30:04 -0500, David Elliott [EMAIL PROTECTED] wrote: On 2001.12.09 17:15 Oliver Sampson wrote: [SNIP] ot Why is the default behavior for the list to have replies go only to the sender and not to the list? /ot Because that would be ridiculous. The only way to really accomplish that is to add a Reply-To which means that it then becomes impossible to easily reply directly to the author. Well, it's not rediculous. And it's not rediculous when you consider that *every other* list (save one) to which I'm subscribed has the list as the default reply-to. The assumption is that if it's important enough to be asked in public, then the answer should be public also. Why should the assumed answer be private? I'm in a habit of replying to mail, not replying-all to mail, and when I reply to mail on this list, I find that I end up sending it twice. (My assumption is that I'm a typical listserv subscriber.) Rarely, do I want to send an email off-list. Do you (and the majority of the members here) send so many off-list emails in response to on-list emails that having the default reply-to for the list, not be the list itself? Hey, it was just a question. Nah, more like a religious issue actually. I really despise the Reply-To munging on some lists and much prefer the way that it is done on this list (which I believe is also how the Linux Kernel list works, last time I was subscribed to it). The way I see it the reply-to header causes the mail client to do silly things and not including it allows more flexibility in the way messages are replied to. But believe me, when I first joined the list I was in your shoes until I realized that Reply-All is really the way to go. If you think about it, it makes sense: Reply - i.e. Reply to the sender Reply All - i.e. Reply to everyone (which is usually the sender and the list). Furthermore, if you include a reply-to header then: Reply - Replies to the list, not the sender Reply All - Replies to the list twice, once because it replaces the senders address with the reply to, and another time because the list was a receipient of the message. It also breaks anyone who actually uses a reply-to header for a legitimate reason. This argument has been discussed before way back when on this list (or was it LKML?, I think it was this one). Almost the exact arguments I am giving above were presented. Believe me, I used to think like you did until I heard this argument, so maybe that'll set it in for ya. [BIG SNIP] I find filtering on the List-Id: field to be the most accurate and unambiguous. List-Id: Wine Developer's List wine-devel.winehq.com Hmm, Dunno how in the hell I missed that... maybe at one point that wasn't there so the only unique thing I could come up with was Sender:. Anyway, this is the end of this thread by far, please send any responses directly using the Reply button as opposed to the Reply All button. :-P -Dave
Re: error at winelib program
On 2001.10.23 14:34 Guilherme Kunz wrote: Hi, All programs was compiled with winemaker. $ ./dlg32 Segmentation fault (core dumped) $ gdb dlg32 core GNU gdb 5.0 Core was generated by `./dlg32'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libntdll.so...Segmentation fault (core dumped) $ winedbg dlg32 Console: Making console complex (creating an xterm)... xterm: unable to open font vga, trying fixed passed master doesn't match slave name I am using: gcc 2.96 kernel 2.2.19 mfc 4.2 compiled wine by CVS 20011023 Any idea ?? What is the problem with winedbg ?? and gdb ?? i already had tried with gcc 2.95 !! Thank You Was this a clean compile of Wine or a CVS update? Have you changed other system configurations between compiling wine (i.e. upgraded the libc or other library)? If so you should try a make distclean (in any rate be sure config.cache is gone). Also, GCC 2.96 has issues. It is a great version of GCC if and only if you are sure you have the latest release of it from Red Hat. The first 2.96 had some major, major problems. The later releases from Red Hat are plenty good enough to compile the kernel (well, 2.4.x anyway). Although from the looks of it if you have 2.2.19 I am assuming that is the redhat release of that so I am assuming you also would have upgraded gcc. Also note that I think RH has released glibc 2.2.4 for ALL RH 7.x platforms. Upgrade all of this stuff, make distclean, and then ./configure ; make depend make. Also, have you tried debugging a simpler case (i.e. add a NULL pointer dereference at various places in the wine init code (i.e. before it sets up its SIGSEGV handler for winedbg, since that seems to be what is going on here). There was also an issue with debugmsgs sometimes causing a coredump a few days ago which has since been fixed. -Dave
PATCH: add Win95 OSR2 to versions
On 2001.10.23 13:55 Marcus Meissner wrote:
Hi,
There was following change to misc/version.c:
revision 1.44
date: 2001/07/27 23:57:38; author: julliard; state: Exp; lines: +1
-1
Bob Goodwin [EMAIL PROTECTED]
Fix the 16bit win95 version.
This makes for instance InstallShield, that uses DOS3CALLs to check for
win95,
report a Bad Windows Version. (Installer of Monkey Island 3)
Reference wine-devel post is:
http://www.winehq.com/hypermail/wine-devel/2001/07/0085.html
If there is a testprogram, I can still boot Windows 95...
Ciao, Marcus
Changelog:
revert 16bit win95 version back to original value. Fixes
InstallShield installer version check.
Your changelog is incorrect.. That is actually the DOS version you are
changing, not the Windows version.
Furthermore, here is a patch to go along with this that implements
Win95OSR2 version. I have had this in my tree for MONTHS but never
submitted it.
This is REQURIED for some programs because the DOS for OSR2 is 7.1 and the
DOS for Win95 Gold (MSes term for the original relase) is 7.0. I think I
added it specifically so I could run COMMAND.COM (well, at least get past
incorrect DOS version). This goes true for all of the DOS utils from
95OSR2.
Honestly, Win95OSR2 should have been called Windows 96 and released as an
actual product, it is completely different from original win95 in many core
areas (But not in any UI ways, hence MSes logic of well, nobody will notice
the difference by looking at it, better keep it as the same product).
Changelog:
Add Windows 95 OSR2 version info
-Dave
P.S. Sorry about the extra .txt extension, seems that Balsa uses it to
determine whether the file is application/octet-stream or text/plain and I
wanted it to be text/plain (will figure this out later).
Index: version.c
===
RCS file: /home/wine/wine/misc/version.c,v
retrieving revision 1.47
diff -u -3 -r1.47 version.c
--- version.c 2001/10/08 22:30:34 1.47
+++ version.c 2001/10/23 20:50:00
@@ -28,6 +28,7 @@
WIN30, /* Windows 3.0 */
WIN31, /* Windows 3.1 */
WIN95, /* Windows 95 */
+WIN95OSR2, /* Windows 95 */
WIN98, /* Windows 98 */
/* insert Windows ME here as WINME if needed */
NT351, /* Windows NT 3.51 */
@@ -85,6 +86,15 @@
VER_PLATFORM_WIN32_WINDOWS, Win95
}
},
+/* WIN95OSR2 */
+{
+0x070A5F03,
+0xC004,
+ {
+sizeof(OSVERSIONINFOA), 4, 0, 0x4000457,
+VER_PLATFORM_WIN32_WINDOWS, Win95 b
+ }
+},
/* WIN98 */
{
0x070A5F03,
@@ -129,6 +139,7 @@
win30,
win31,
win95,
+win95osr2,
win98,
nt351,
nt40,
Re: RPCRT4 Uuid String functions
On 2001.10.21 18:34 David Elliott wrote: This one should properly implement all of the Uuid*String[AW] functions in RPCRT4.DLL NOTE, this includes a bugfix to the existing UuidToStringA in that it does not allocate enough space to store the string it outputs. (it is short by 2 chars). -Dave Noticed that Alexandre applied my NTDLL patch, but not this one. Hmm, now that I am looking at this I guess the swprintf is defined in NTDLL so I should just use that... WHOOPS, did a lot more coding than I had to. I will rework this to use the much saner method and resend the patch later tonight. Oh well, at least we got a free implementation of wcstoul out of it. :-) If I am on the wrong track here, lemme know. Originally I had thought that something like a printf function would only be declared in MSVCRT and didn't want to import that, but now that I am looking at it it seems that MSVCRT only forwards to NTDLL. Gotta get out of that UNIX mindset and into the windows one I guess. -Dave
Re: RPCRT4 Uuid String functions
On 2001.10.22 18:28 Francois Gouget wrote: On Mon, 22 Oct 2001, David Elliott wrote: [...] Hmm, now that I am looking at this I guess the swprintf is defined in NTDLL so I should just use that... WHOOPS, did a lot more coding than I had to. I will rework this to use the much saner method and resend the patch later tonight. Oh well, at least we got a free implementation of wcstoul out of it. :-) If I am on the wrong track here, lemme know. Originally I had thought that something like a printf function would only be declared in MSVCRT and didn't want to import that, but now that I am looking at it it seems that MSVCRT only forwards to NTDLL. Actually there's quite a few *printf implementations in the Wine tree. Too many I would say. What's more, IIRC most of them are incomplete as they do not support %S and %C (Unicode for ANSI printfs, ANSI for Unicode printfs). I believe this whole thing needs a good cleanup... Ah, I knew I had entered a bug report for that one: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=321 sscanf too may need some cleaning. Any volunteers? Yes. I am good at stuff like this. It's easy, you look at the manpage and implement it, and then go back and put in MS hacks. No design involved there or trying to figure out MSes crappy design since it uses normal POSIX semantics. Besides, a mostly working sscanf/sprintf (both normal and unicode) is kind of a requirement to write these functions correctly rather than rewrite part of sscanf as I did. Gotta get out of that UNIX mindset and into the windows one I guess. Preferably not ;-) :-) True, but on the other hand I believe the higher level libraries should not require calling into POSIX unless absolutely necessary; i.e. being able to take a wine dll, compile it into a PE DLL and use it in real Windows would be kind of a cool thing. Obviously this is not possible everywhere, but for these particular RPCRT4 functions I see no reason why they should require more than what NTDLL provides (since NTDLL seems to provide basically everything, at least if it was completely implemented). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux What's the corrolary to that. Any crappy OS or GUI is indistinguishable from Windows? Should I dare say See KDE for an example. :-/ -Dave
(WHOOPS, forgedaboudit) Re: Fix crash with certain debugmsgs
On 2001.10.21 16:41 David Elliott wrote: [snip] I noticed that most everything else in the file uses get_info() instead of calling NtCurrentTeb()-debug_info directly. And since the issues was that debug_info was NULL and it seems the get_info tackles this by creating it this seemed to be the proper fix. -Dave Looks like someone else noticed this too, and had a slightly better fix -Dave
Re: [PATCH] HOOK_CallHook
Francois Jacques wrote: IMHO, performing code review of the whole tree for missing volatile keywords would be a waste of time compared to do it on a case by case basis. Simply keep in mind that those bugs may happen - especially with "aggressive" compilers such as gcc 2.96. If a bug didn't happen with the previous compiler and does show up with the latest release, it might be a good candidate. But the point is, this is *not* a Wine bug that was just exposed by a new compiler -- this is a compiler bug, plain and simple. Did I write it was a WINE bug? No. It is very clear for me that it *is* a compiler issue. I had three choices a) find a workaround and have people comment on it; b) disable the optimize phase for gcc 2.96 and have the whole community on my back; c) fix gcc. I went for the easy one. Making these variables 'volatile' is not required at all -- 'volatile' tells the compiler that the variables might be changed behind the compiler's back, e.g. due to being asynchroneously modified by a signal handler or something like that. In this particular case, however, the variables are not only not changed behind the compiler's back, they are *never* changed at all! 100% agree. Again, it's a quick-yet-efficient workaround to the compiler problem that just happened to work. While volatile is for variables that are modified by external factors, it was a good way to prevent all the optimization - which was just what I wanted. To be honest, I didn't read the patch and simply assumed this was a simple case of forgetting to add volatile and getting bitten by a compiler that optimizes more agressively. Either way it still is a valid point to be concerned about not only compiler bugs but also new compiler features. Instead of circumventing the compiler bug in this particular case, it might be preferable to find out which optimization phase contains the bug, and write a configure check that switches that phase off if it detects the bug (like we did with the 2.95.2 strength-reduce bug). We'll do some research on the optimization phase. Once we found it, can anybody help us with that autoconf kungfu? That would be a good idea. Of course I don't think the volatile keyword in this case is hurting anything except maybe speed (negligble). Hopefully this can get fixed soon in gcc. Looking at the gcc project page, it seems that 3.0 is very close to be done. -Dave
Re: [PATCH] HOOK_CallHook
Francois Jacques wrote: Group, This patch comes from investigation of a bug that was observed in RedHat 7.0 and not observed in RedHat 6.1. After a debugging session that involved Stephane and I, we found out that it was a compiler issue (which I feared from the start, but wasn't considering it seriously... arghhh). The RedHat 6.1 installation has gcc version 2.91.66 and the RedHat 7.0 installation has gcc version 2.96-2731 (RedHat Linux 7.0) with latest updates from RedHat. What's happening : 1) HOOK_CallHook is being called (notice wParam and lParam arguments)2) Local variables wParamOrig and lParamOrig are set to wParam and lParam values3) Mapping function is called (MapFunc) with the *addresses* of wParam and lParam so those get changed before we call the hook4) After MapFunc is called, wParamOrig and lParamOrig values also changed to the new values of wParam and lParam (!) Explanation : Down to the assembly level code, the compiler doesn't create wParamOrig and lParamOrig on the stack. Instead, it directly use wParam and lParam. Fix : add volatile to wParamOrig and lParamOrig to prevent optimizations on those variables (aka. force their presence on the stack) This kind of begs the question: how many more places in Wine should the volatile keyword be used? I find it hard to believe that this is the only spot in a large very low-level project like Wine. -Dave
Re: The PEACE Project
Patrik Stridvall wrote: I don't know if you know about The PEACE Project: http://chiharu.haun.org/peace/ Now I do. :-) What is PEACE? PEACE is a set of programs to run Win32 apps on NetBSD/i386 (and other ports in the future?) box. I see. What is the difference from other Win32 emulators? Actually, PEACE is Win32-compatible package' rather than emulator' because different from Wine and WABI, And Wine isn't a "Win32-compatible package"? PEACE does not have emulator executable'. EXE files are directly executed from sh or csh. The above is IMHO a rather clintonesque use of the words emulator and executable. They hide the comparable code in NetBSD's dynamic linker instead. Clintonesque?? HAHAHAHAHAHAHAHAHAHAHA That's really good dude! I guess it follows in the tradition of words like "nasty". Not impressed, eventhough we could and probably should do that in the future. I thought there was another kernel module running around that loaded wine for exe files. Used BINFMT_MISC or something? However if we hide the fact Wine is run, many user will not realize that it really is Wine's fault that their Win32 application crashes and say to their friends that Linux is unstable which gives Linux a bad reputation. We don't want that do we? So we probably shouldn't make it transparent at least not as long Wine still is alpha. Should there ever be a kernel module exe loader? IIRC, OS/2s WinOS/2 did not support running Windows (Win16 in this case) apps directly (i.e. from a shell or any program using the API call to run a program). However it did support running them directly from the WPS (GUI) and supported making launchers for them and tweaking a number of properties. To run windows apps from the command line you just ran "win programname". Kind of like you would in DOS back in the Win3.1 days. Kind of like "wine programname" like we have now. Codeweavers is on the right track here, allowing users to launch Windows apps from gnome by creating a file association. DOS programs were a bit different. You could run them from an OS/2 command prompt, but if you did that then you opened them up in a new terminal window. I believe the calling process waited on it too. I am thinking maybe that if you redirected the output of the DOS command to a file then it would not run in its new window, but maybe not. Win4Lin's "dos" command has some options that select whether you want to create a new window (the default) or input/output from stdin/out. This allows commands to be redirected. In this mode you cannot run any programs that require any sort of access to hardware like directly writing into the character buffer. On the upside, you can run sort and expect it to work correctly. Since there are very few DOS programs designed for this you have to explicitly give the option, most users would just want to have a nice window opened where their DOS app can run. PEACE consists of the following 3 components: 1.In-kernel *.EXE loader Can't find the source but can't imagine it is very complicated. Probably somthing similar to what David Howells did for Linux. I thought David's module was implementing the Wine in kernel space (e.g. part 3 of this). This part can be done with or without having Wine in the kernel. 2.Dynamic linker for Windows *.DLLs Hmm, 233 lines of code including comments. Not very revolutionary. Truly not. We have had code to do this forever. 3.Win32 API implementation (i.e. core DLLs) This is supposed to do exact what Wine (Winelib) does. However it currently only implements a very small part of what Wine currently does as they admit... How many Win32 API functions are implemented? Currentry, most APIs are NOT implemented. ... here In short this is just some Japanese guys trying to reinvent the wheel. I would say definitely that this is the case. I really can't understand why they don't cooperate with us in the Wine project instead. I cannot either. I know that there is this whole thing about wanting to write your own code for stuff, but that is usually a waste of time. Furthermore, the Wine project is developed in an extremely open way by a lot of very talented developers. It is a real shame to see someone who could obviously help out the Wine project going out and doing their own program. Anyone can join the wine development team. Simply subscribe to wine-devel and wine-patches and start hacking. Because all patches go through Alexandre before going into CVS every developer has basically equal chances of getting their patch into the tree (assuming that it is following the overall architecture goals of Wine). Actually, I would say wine is an extremely good example of the open source development process. There is also no licensing issue with Wine, it's under such a liberal license that anyone can use it! -Dave
Re: Header file legal issues (was Re: process.h patch)
Patrik Stridvall wrote: The court in that case said: Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement. Hmm, I am not so sure I like all of that. Program code serves two purposes. For one thing it is functional, and for another (and actually for the most part) it has a human readable structure. I think you have missunderstood what the judges meant. The fact the computer programs are functional doesn't take away their copyrightabillity. But copyright only protects the creative expression and then the form of these expressisions are dictated by external factors such as in the courts words "compatibility requirements and industry demands" they are not creative expression and thus not copyrightable. It almost sounded to me as if they were saying that it was purely functional. But then again I didn't read it really carefully. The correct representation is that they are creative but then yield a function. The creative part (the source code) should be copyrightable, but the actual functionality should not be, and it should be perfectly legal to duplicate the functionality of a piece of code so long as you do not actually verbatim copy the copyrighted source code. Protecting the functionality would be an issue for patents and not copyrights. And with the exception of things like the RSA patent, software patents for the most part have not been working. Of course, IIRC the RSA patent is not actually a software patent but a patent on a hardware implementation of the algorithm. Not that fact that the court said "functional" and not "is not a creative expression" is AFAICS largely irrelevant. But I think I can see what you are after, I you have an "optimal" compiler every computer program that are functionally equivivalent will be reduced to the same binary form. However that doesn't rob the source code from copyright, just the binary form. Binaries should only be copyrightable in the sense that doing a verbatim copy (e.g. copy file.exe newfile.exe) should be protected, but if the compiler happens to generate an exact copy, then so be it. Anyway, regardless of whether optimal compilers possible, it still doesn't make copyright of computer programs meaningless, since you really want to be able to change the computer program and an optimal representation of it is not very easy to change. :-) So the creative expression of the source code is really useful and thus promotes progress, so it really should be and indeed is protectable. Yes, source code should in fact be copyrightable. It is a human work just like sheet music or a magazine article or book, etc. Binaries are more questionable, but see above. -Dave
Re: process.h patch
Jon Griffiths wrote: Hi, Hmm, glad to see everyone is alive and well again. :-) Its been a slow week, no? Firstup, on copyright, I think I was misunderstood. When I say they are not copyrighted, I mean the author(s) have _given up_ their copyright explicitly. Each original header file carries the following banner: * THIS SOFTWARE IS NOT COPYRIGHTED * * This source code is offered for use in the public domain. You may * use, modify or distribute it freely. * * This code is distributed in the hope that it will be useful but * WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY * DISCLAMED. This includes but is not limited to warranties of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You can't get more clear than that, I think. Of course it would be good to acklowdge their contribution and let them know their modified code is being used. Cool, sounds good to me! Thus the references are set during compile time and not link time and also would allow you to essentially link to an MSVCRT and a libc within the same program if desired. I believe in most cases you can do this by appending an _ to the name, although not for all cases obviously. The only thing I don't like about this is requiring another library, particularly because the apps code that uses MSVCRT_is then non-portable. With the @ignore directive in your .spec, it is now possible to link with msvcrt and optionally have individual functions resolved to libc, so it shouldn't be required to have a prefix, although it wouldn't hurt to be available. One thing I _don't_ think we need to do is to try to use the headers when building msvcrt and Francois suggested. I think its extra work for no real benefit, bugs show themselves soon enough, and winapi_check catches several kinds of parameter bugs already. I alos dont like having to use a different build command for one dll (ie include he msvcrt header dir). Actually, I also intended to use the headers when building MSVCRT, but that may not be really necessary. Part of the reason for rewriting the include files was also for licensing. If we rewrite the header files ourselves then it's pretty much guaranteed that they can be licensed exactly the same as Wine. If we "borrow" them then who knows. Most Windows compilers I have seen have some sort of license on what you can do with their header files that might not make them fit for inclusion into Wine. I don't think this is an issue given the notice above, which Is why I started from the rsxnt headers as a base. Very cool, so you were already taking this into consideration then. An idea that just popped into my head is maybe seeing if we can get a windows compiler maker (e.g. Borland) to donate a full set of headers under the Wine license. However they may have licensed them with certain terms and be unable to do that. I'm sure the rsxnt guys would be happy to provide an email exlicitly giving permission, even though we don't need to ask for it since they have no copyright on their code. I like their headers because they are MS compatable and very lightweight (even more so since I stripped them right back before submitting). I doubt it's necessary seeing that they put them into public domain. We should definitely give 'em some credit though. This is just the stuff off the top of my head. I am gonna hit the sack now, long day tomorrow (tues.) and the next day. Good luck for the weeding! Thanks. It went great. Everything went perfectly except the flowers were kind of falling apart, but it actually worked out since it looked like the petals were supposed to be dropping intentionally! Cheers, Jon Good night, -Dave
Re: Header file legal issues (was Re: process.h patch)
Gavriel State wrote: David Elliott wrote: Part of the reason for rewriting the include files was also for licensing. If we rewrite the header files ourselves then it's pretty much guaranteed that they can be licensed exactly the same as Wine. If we "borrow" them then who knows. Most Windows compilers I have seen have some sort of license on what you can do with their header files that might not make them fit for inclusion into Wine. An idea that just popped into my head is maybe seeing if we can get a windows compiler maker (e.g. Borland) to donate a full set of headers under the Wine license. However they may have licensed them with certain terms and be unable to do that. While Jon has addressed this issue in regards to the MSVCRT headers, this might be a good time to point out that the legality of enforcing copyright on header files through licensing restrictions is questionable. I'll preface this with the usual mention of the fact that I am not a lawyer, nor do I play one on TV. Please consult a qualified professional before taking action on anything I've written. Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html The court in that case said: Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement. Hmm, I am not so sure I like all of that. Program code serves two purposes. For one thing it is functional, and for another (and actually for the most part) it has a human readable structure. I think it is actually very similar in nature to sheet music. The specific typesetting of a piece of sheet music can be copyrighted, so photocopying it is illegal. However, if the copyright has expired on the music itself then you can copy it by hand (or hell, even by machine) and as long as it is not an exact duplicate then you can make as many copies of that as you want. Since Wine absolutely requires the specific header file layout, strucutre and function names, etc to be the way the Windows headers express them, there is good cause to believe that the header files are unprotected by copyright. I would say the specific byte for byte header files are, especially the comments in the code which are most certainly copyrightable just like any text. However, you could easily make the point that you can define the same interface and do so "in your own words" and then it would be perfectly fine. The headers would of course look almost exactly the same as the originals given the nature of having to provide the same interface, but it is a new implementation of the same functionality. In fact, development tool licenses that attempt to restrict usage of these headers may even constitute anti-trust copyright misuse. Early versions of MS Visual C++ contained a shrinkwrap license that forbade the use of the product to create software for platforms other than Windows. Later revisions (ie: SP3) removed that restriction, so perhaps MS realized that this was not protectable. You'd think that would be a "Well, DUH!" But they always want to protect as many rights as they have, or don't have but could possibly have. One fly in the legal ointment is that while the headers may not be copyrighable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap lice
Re: Header file legal issues (was Re: process.h patch)
Patrik Stridvall wrote: One fly in the legal ointment is that while the headers may not be copyrighable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap license agreement and unwraps it is legally bound to follow it, while the person who later finds the unwrapped CD 'on the street' with no such license is allowed to copy the portions that are unprotected by copyright. If that is so, wouldn't it mean that if you have a pirated copy of the headers you can legally copy and distribute parts that are unprotected by copyright. :-) Oh, the irony of it all. Anyway, you don't need to go to such extremes, since the legal status of shrinkwrap licenses in Europe is much more doubtful, just have somebody in Europe do it. I can't see why something posted on wine-patches shouldn't be equal with found on the street, in the meaning that things that is unprotected by copyright can be legally incorperated in the main tree. This is probably true regardless of the legal status of shrinkwrap licenses in Europe, especially since it is IMHO entire reasonable, given existing European cases, to assume that they don't have an legally meaning. I would say in the US they should not and really don't have legal meaning either. There have not really been enough cases to say one way or the other. Yes, so far there have been stupid cases where justices decided that the shrink-wrap license actually meant something, but I can see that issue going the other direction soon. I think the courts already have enough to do without dealing with BS over a shrink-wrap license. It's unclear where the anti-trust issue fits in there. I pass, not my area of expertize. :-) Food for thought, anyhow... Yes.
Re: process.h patch
Alexandre Julliard wrote: Jon Griffiths [EMAIL PROTECTED] writes: Until we have MS style headers, at least declare msvcrt functions extern "C" so C++ Winelib programs will link. I didn't get any feedback to my headers patch. Alexandre, what do I need to do to get some headers into CVS? Or is that not the plan? Well, I don't know, I was hoping to get some feedback from the winelib experts out there on whether this is better than the approach with macros suggested by David. Hmm, glad to see everyone is alive and well again. At this point my schedule is pretty full until Thursday. My parents are getting remarried this Wednesday (Valentine's Day) so I am busy preparing with them and working on some songs to sing at the wedding and reception. My original plan was actually to write the headers along with the implementations to sort of break up the mundane task of writing headers with some actual coding and so that neither one would be too far behind the other. A lot has changed in Winelib since the original discussion on this. For one thing, DLLs work as expected now and imports can actually be resolved to native DLLs. This is sort of a recap so that we are all on the same page: There ought to be a full set of headers that is intended for linking with a real MSVCRT, possibly using a few macros sparingly but only for optimizations. There also should be the ability to use normal UNIX headers and link with a normal UNIX libc if desired. (Which currently would be the only way to do things). Francois had also talked about a mixed set of headers using mostly UNIX stuff but with a few MSVCRT things thrown in. I had thrown in the idea of being able to prefix the msvcrt functions with something like MSVCRT_ and then linking against a library which forwarded the "MSVCRT_function" to "MSVCRT.function". Thus using MSVCRT_function in the program would use the MSVCRT implementation, and using just function in the program would use the normal libc function. The idea behind this was the some source files could include header files which #defined function MSVCRT_function, other source files could include normal libc headers. Thus the references are set during compile time and not link time and also would allow you to essentially link to an MSVCRT and a libc within the same program if desired. While the idea may not be great for use in Wine itself, it might be nice if the header files supported a prefix on all function names, somewhat like NEC's SOCKS headers (except actually working unlike the socks headers). Part of the reason for rewriting the include files was also for licensing. If we rewrite the header files ourselves then it's pretty much guaranteed that they can be licensed exactly the same as Wine. If we "borrow" them then who knows. Most Windows compilers I have seen have some sort of license on what you can do with their header files that might not make them fit for inclusion into Wine. An idea that just popped into my head is maybe seeing if we can get a windows compiler maker (e.g. Borland) to donate a full set of headers under the Wine license. However they may have licensed them with certain terms and be unable to do that. This is just the stuff off the top of my head. I am gonna hit the sack now, long day tomorrow (tues.) and the next day. Have a good one, -Dave
Re: No implementation for shlwapi.dll.0(StrRetToBufA)
Ove Kaaven wrote: On Sat, 10 Feb 2001, Francois Gouget wrote: Sure they have the right to deny me access to their mail server, but to imply that I'm only allowed to connect to my ISP's mail server is bullshit. Exactly why? You *should* use your ISP's mail server, that's what it's there for. Anything else is inefficient and plain stupid. You've found one of the reasons it's stupid - another is that if the target mailserver is unreachable for the moment, it's better to let the ISP's mailserver try again for the usual 5 days than to sit dialed up yourself for 5 days. Yet another reason would be that since your ISP generally has more bandwidth than your own dialup connection, both SMTP connections are less likely to time out and cause unnecessary retries, delays, and traffic. That is most definitely correct. Well, I cannot tell you that you should switch to another ISP, it would be too easy for me and hypocritical as I'm not sure I would do it if I were in your situation. I'll see if I can send them a complaint email (without it getting bounced). Maybe *you* should switch to another ISP, one that is able to educate their users properly. That's kind of harsh, but yeah, you should definitely be going through your ISPs mail server if you have a dialup. Personally I run my own, but I have a cable modem and @Home uses bad mailservers which crash all the time. If I had a dial-up I would most definitely go through my ISPs mail-server. I also filter mail with all of the MAPS list and my own threats to spammers. It has been very effective, reducing my spam to a few per week which I usually forward to the admins of the mail servers or connections involved. Lately I have been kind of lax about that figuring a few per week is not bad. Apparently the spammers have a black-list of their own. Report enough of them to ISPs and you won't get more spam because they don't want to deal with your shit anymore. ;-). Still doesn't help those who don't have the knowledge to effectively report spam, but it has reduced my spam very nicely. -Dave
Re: Reverse engineering court decision
Patrik Stridvall wrote: [BIG BIG SNIP] Personally I don't worry that much. First of all I live in Europe secondly any kind of regulation of these kind of issues will IMHO be either logically inconsistant or completely arbitrary. Neither of the cases are likely to survive in the long run for several reason among them. 1. Constitional/"Human rights" reasons 2. Legal enforcement is close to impossible 3. It is unlikely to serve the public good Patrik, You are most likely correct. Eventually the court system will get their head out of their ass and figure this out. At the moment it seems to me like its way up in there and they are going "Damn, it's dark in here". Personally I am glad there are people that are very passionate about these issues because someone has to bitch about it and start getting normal people thinking about it. Even my dad could easily see the argument that restricting someone from writing a program is really really braindead (although he has done coding way back in the day). His response was that eventually the court system will figure it out and it'll be over and done with. Seems to be much the same as your response. -Dave
Re: Reverse engineering court decision
Patrik Stridvall wrote: One intresting aspect concerning Wine is the DRM (Digital Rights Management) that Slashdot reported that Microsoft are going to add to Windows. If we implement it is Wine we are not trying to circumvent it quite the opposite we are trying to to make it possible enforce it. ;-) Of course a one line patch making a critical function always return TRUE or something might be able to disable it for people that don't like it. :-) DO IT! What are they going to say, that because you can change the code that you are aiding in circumventing copyright protection. If they go after you then you know for sure that they have the poorest of intentions. -Dave
Re: Reverse engineering court decision
Patrik Stridvall wrote: Patrik Stridvall wrote: One intresting aspect concerning Wine is the DRM (Digital Rights Management) that Slashdot reported that Microsoft are going to add to Windows. If we implement it is Wine we are not trying to circumvent it quite the opposite we are trying to to make it possible enforce it. ;-) Of course a one line patch making a critical function always return TRUE or something might be able to disable it for people that don't like it. :-) DO IT! I think we currently have other more important thing to do for Wine 1.0. Certainly [BIG SNIP] If they go after you then you know for sure that they have the poorest of intentions. Well, we already know that their only intention is more profit, so this will not really help us derive anything new. Patrik, that was probably one of the most well-written arguments I have heard against the DMCA. Too bad probably only Wine developers will see it. Ever thought of becoming a lawyer? ;-) -Dave
Re: another question about that damned registry :-)
Juergen Schmied wrote: where is the place for HKEY_USERS/Software/... key? In the recycle bin ;-). There shouldn't be such a thing. What kind of idiot program created that? The closest correct thing would be HKEY_CURRENT_USER/Software, which would map to HKEY_USERS/%username%/Software... The crapy programm is the microsoft dialer. "HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Telephony\HandoffPriorities" Yeah, I was about to say "a Microsoft program". Think we can ignore this key safely. Definitely. I think it can be safely deleted even on windows. -Dave
Re: registry.c
Martin Pilka wrote: hello! * fix the incorrect registry behavior - rename userdef.reg to users.reg, it contains HKEY_USERS branch * drop user.reg file because of duplicity * get rid of unnecessary hkey_users_default If you absolutely MUST save keys that are directly in HKEY_USERS (which shouldn't even be there in the first damn place, see other messages by Ove, Juergen, and me), then do it a different way. 1. Keep user.reg and userdef.reg, make a new users.reg containing HKEY_USERS minus the .Default and the user's key. I believe NT/2000 do it this way. 2. Keep user.reg and make a new users.reg containing HKEY_USERS (including .Default) but not the user's key. I believe 9x does it this way. Personally I say option one. The more finer grained the registry files are, the better. Especially because it may be desirable to have a system-wide .Default key and HKEY_LOCAL_MACHINE key which can be accomplished with some symlinking now and still allow the user to have their own HKEY_USERS\username hive. -Dave
Re: Test case for GCC macro expansion
Alexandre Julliard wrote: Francois Gouget [EMAIL PROTECTED] writes: Here's the testcase I wrote: #define GetObject You cannot use GetObject in this context #define ICOM_FN(xfn)fn ## xfn #define DECLARE1(xfn)void ICOM_FN(xfn) (void); #define DECLARE2(xfn)void ICOM_FN(##xfn) (void); If the only problem is GetObject and similar functions, couldn't we simply #undef GetObject and get rid of ICOM_FN completely? or is there a deeper issue? I sent a patch both to Francois and wine-devel that undef'ed GetObject and then redef'ed it back to its original value. Did the same for GetClassInfo. It's a hack but at least it has the intended behavior and makes my tree compile. -Dave
Re: Compile error on latest CVS
Francois Gouget wrote: Yes, there is a problem with a change I made recently. There's been some discussion about it during this weekend already. Maybe the best for you is to revert back to an old version of 'include/wine/obj_base.h' (or switch to gcc 2.95) while I try to sort it out with the help from gcc guys. BTW, the compiler you're using is even more recent than the one shipped with Redhat 7, right? Francois, I believe the attached patch^H^H^H^H^Hhack will "fix" the problem. As I understand it you wish the function name to be passed to ICOM_METHOD???(...) unexpanded and you also wish it to be passed to ICOM_FN (within the ICOM_METHOD??? macro) unexpanded. In the ICOM_FN macro you prepend "fn" to it using the token pasting operator when __WINE__ is defined. If __WINE__ is not defined you leave it unaltered. After this I am assuming you WANT it expanded if it should be (i.e. fn was not prepended to it). The attached patch simply saves the value of the misbehaving macro to a temporary macro, undefines the macro, does what needs to be done, redefines the macro using the temporary macro then undefines the temporary macro. It only does this in the __WINE__ case so that it still gets expanded for winelib. I did not remove the (##xfn stuff as it only generates warnings which IMHO should be there as they indicate a broken preprocessor. Have a good one, -Dave Index: include/wine/obj_control.h === RCS file: /home/wine/wine/include/wine/obj_control.h,v retrieving revision 1.10 diff -u -r1.10 obj_control.h --- include/wine/obj_control.h 2000/09/26 00:01:00 1.10 +++ include/wine/obj_control.h 2001/01/02 10:14:35 @@ -408,12 +408,25 @@ /* * IProvideClassInfo interface */ +#ifdef __WINE__ +#ifdef GetClassInfo +#define TEMPMACRO_GetClassInfo GetClassInfo +#undef GetClassInfo +#endif /* #ifdef GetClassInfo */ +#endif /* #ifdef __WINE__ */ + #define ICOM_INTERFACE IProvideClassInfo #define IProvideClassInfo_METHODS \ ICOM_METHOD1(HRESULT,GetClassInfo, ITypeInfo**,ppTI) #define IProvideClassInfo_IMETHODS \ IUnknown_IMETHODS \ IProvideClassInfo_METHODS +#ifdef __WINE__ +#ifdef TEMPMACRO_GetClassInfo +#define GetClassInfo TEMPMACRO_GetClassInfo +#undef TEMPMACRO_GetClassInfo +#endif /* #ifdef TEMPMACRO_GetClassInfo */ +#endif /* #ifdef __WINE__ */ ICOM_DEFINE(IProvideClassInfo,IUnknown) #undef ICOM_INTERFACE Index: include/wine/obj_moniker.h === RCS file: /home/wine/wine/include/wine/obj_moniker.h,v retrieving revision 1.15 diff -u -r1.15 obj_moniker.h --- include/wine/obj_moniker.h 2000/09/26 00:01:00 1.15 +++ include/wine/obj_moniker.h 2001/01/02 10:14:36 @@ -298,6 +298,13 @@ /* * IRunningObjectTable interface */ +#ifdef __WINE__ +#ifdef GetObject +#define TEMPMACRO_GetObject GetObject +#undef GetObject +#endif /* #ifdef GetObject */ +#endif /* #ifdef __WINE__ */ + #define ICOM_INTERFACE IRunningObjectTable #define IRunningObjectTable_METHODS \ ICOM_METHOD4(HRESULT,Register,DWORD,grfFlags, IUnknown*,punkObject, IMoniker*,pmkObjectName, DWORD*,pdwRegister) \ @@ -310,6 +317,12 @@ #define IRunningObjectTable_IMETHODS \ IUnknown_IMETHODS \ IRunningObjectTable_METHODS +#ifdef __WINE__ +#ifdef TEMPMACRO_GetObject +#define GetObject TEMPMACRO_GetObject +#undef TEMPMACRO_GetObject +#endif /* #ifdef TEMPMACRO_GetObject */ +#endif /* #ifdef __WINE__ */ ICOM_DEFINE(IRunningObjectTable,IUnknown) #undef ICOM_INTERFACE
Test case for GCC macro expansion
Attached is a simple .c file (not even a program, intended for input for the preprocessor) and the output when run with the processors from the latest RH7 errata GCC 2.96 and the RH7 KGCC 2.91.66 (egcs 1.1.2). I included the output from stderr of the newer preprocessor as well. This should be a suitable simple testcase for a preprocessor. Maybe it would be good to see the results on other C preprocessors like Solaris C so that we can get a good idea if gcc should continue to support this even though I don't think it is specifically mentioned in any C standards. -Dave #define Bad VERY_Bad #define A2(a) PREFIX_##a #define A1(a) (A2(##a)) A1(Good); A1(Bad); A2(Bad); #define B2(a) a #define B1(a) (B2(##a)) B1(Good); B1(Bad); B2(Bad); # 1 "" (PREFIX_Good ) ; (PREFIX_Bad ) ; PREFIX_Bad ; ( Good ) ; ( VERY_Bad) ; VERY_Bad ; # 1 "" (PREFIX_Good); (PREFIX_VERY_Bad); PREFIX_Bad; (Good); (VERY_Bad); VERY_Bad; stdin:5:18: warning: nothing can be pasted after this token stdin:12:18: warning: nothing can be pasted after this token
Re: MSVCRT
Jon Griffiths wrote: Hi, Definitely, I am not sure how to go about this now though. Should we just say the hell with it and forward to CRTDLL since our CRTDLL is working better or should we just move code out of CRTDLL and into MSVCRT a function at a time (or several at a time)? I would prefer sticking with the latter as previously discussed, CRTDLL should depend on MSVCRT and not the other way around. I think the better plan is your original one, that is, to move everything into MSVCRT (principaly to avoid dependency issues). But we can't really do this a function (or even a couple) at a time, things need to be moved in (generally large) related blocks because of data dependencies (e.g we dont want 2 _iob's being used). more on this below. Yes, I thought about that, especially with relation to functions that are different for each DLL but use data that may need to be common. Actually yes, my original focus, and my main goal is not to churn out tons of function implementations, but to provide a build environment with proper headers and an example of how to make a Winelib app that uses MSVCRT or CRTDLL as its C library. Yeah, I think we really need this, especially for Unicode, which is impossible to work with using libc. Well, the phrase "atexit is limited only by available memory" lead me to decide that a linked list would be better, plus since they go in LIFO order it just seemed to make sense. Sure. Dont get me wrong, IMO your implementation of the storage was more correct. I just meant that with the huge number of functions left to implement (350+!) it might be more useful to get things working first and take care of the extreme cases later. Sorry, also forgot to mention that I had written it before your implementation, or probably at the same time, but you released first, so I wasn't trying to duplicate work or provide a better implementation of a trivial thing, I just happened to implement it that way when I did it. Okay, I swear that's what MSDN said, but you know MSDN. Or maybe I pulled that out of a UNIX header because it didn't say anything and at the time I didn't have UNIX headers handy. (whoops s/UNIX/windows/ on that last line) Nope, you were right, I was tripping :-) too much coffee I think, sorry! ;-) Hmm, okay, I tried to come up with a way that could easily translate most windows errors into UNIX errors and fallback to a default value for that particular function if there was some other error. I would appreciate suggestions. Hmm, we really want to translate to MS errnos rather than Unix. The current method is correct for errno/doserrno in over a hundred functions Ive tested error cases for, so I think it should do for now. There are a few cases were the error is set/cleared explicitly as well, when errno is set but doserrno isn't (these are pretty easy to test and usually listed in the online docs). If you notice, the functions I implemented are pretty basic, like exit handling and printf (not even implemented correctly). The forwarding to NTDLL was how it was done in the original CRTDLL so I just kept it so that the functions would remain implemented in MSVCRT. Basically I just wanted to get the DLL in the tree so I could link Winelib programs against it. OK, specmaker will generate (+ install into the Wine tree) a suitable stub for people in about 30s if all they want to do is link. So we can probably hold off putting the actuall DLL into the tree until we move the code, the headers are more important. But mainly the code has moved on _a lot_ since you grabbed it, especially in the area of initialisation/exit/cleanup, which is why I didn't think an msvcrt dll based on it should go in. Right, might want to hold off until we stabalize and get ready, I can live with that figuring that now that linking works correctly I can just link against CRTDLL! (woohoo!) I can still go ahead and get a good set of working header files together for winelib. When I have all the implemented functions prototyped in the correct headers (which shouldn't take too long, just kind of tedious) That would be very useful (you're right about it being tedious though). lcc has very clean headers if your looking for a place to start (the MS ones seem to be full of useless chuff). Except for wchar.h, a lot of the libc headers can be used as well. I actually have mostly stayed away from MS headers, easier to prove it wasn't a derived work that way. Only in few cases where MSDN is vague in which case they are documentation and not copied code. Better safe than sorry I figure. then I should start working on implementing what has not been implemented yet. Hopefully now we both have the time to work on this together. Absolutely. Theres a ton of functions to implement, many months work for several people I think. Oh definitely. I have started working on moving crtdll into msvcrt and
Re: MSVCRT
First off, sorry for the late response, I just got back from vacation and was planning to do some Wine work during but I wound up having enough computer stuff to do fixing my parents computers. Jon wrote: Sorry for the long post, theres a few issues raised here... On Monday 18 December 2000 9:07 am, David Elliott wrote: I am not yet including the testsuite in programs/msvcrttest but I will be posting that to wine-devel with an explanation shortly. I have a test harness for crtdll/msvcrt (or any other crts e.g. borland/watcom) that I've been using to test the crtdll implmentation against both dlls. I'd suggest we *not* put testsuites in programs/whatever (or in fact into the wine distribution at all), for the following reasons: [SNIP] Well the "testsuite" in its current form is just a printf and exit so I am not doing duplicate work, it was more of a test to make sure it was loading the DLL the way I expected it to (which Wine now does). What I propose is distributing test harnesses seperately (e.g. as a tarball). In this way developers who want to work on a given dll can d/l the testharness to check they dont break anything, and add tests for new functionality they add without disturbing the regular wine development, or increasing the download time any more for people getting/updating Wine. For reference, the crtdiff options output is attached to the end of this message. I can upload it to the wine patches directory if anyone is interested in looking running it (its a Winemaker-generated project that sits outside the Wine tree). A separate tarball would probably be the way to go for all the testing stuff. It should have its own CVS as well. Possibly because it is against current CVS and you are at the last release? There have been lots of changes to that file. I'm on the latest cvs and it failed for me too. Might have been chomped by the mailer... Doubt it, I am using netscape and attaching the file. I'll take a look at it again now. Also, saw in another mail I forgot to do a make clean directly before packaging it up... that's because I did a make just before to make sure it compiled okay. Right now I am just trying to get MSVCRT into the tree so I can start producing normal patches to implement all of the features. You may have noticed the big fat warning (fixme actually) during the initial load of MSVCRT. I suggest you don't bother reimplimenting the msvcrt functions that are already in crtdll. Every function I've tested so far in crtdll is exactly the same as msvcrt, except for about 6, which differ only in that the crtdll implementation is broken. e.g. -some math functions don't set EDOM in crtdll but do in msvcrt. -setlocale is a superset of functionality in msvcrt (e.g. locale aliases are supported). Definitely, I am not sure how to go about this now though. Should we just say the hell with it and forward to CRTDLL since our CRTDLL is working better or should we just move code out of CRTDLL and into MSVCRT a function at a time (or several at a time)? I would prefer sticking with the latter as previously discussed, CRTDLL should depend on MSVCRT and not the other way around. In these cases its better to implement the msvcrt functionality because it is essentially a bug fixed MT safe version of crtdll. I have done this but haven't added MT safety since Alexandre didn't want to when I started out. I am planning to move crtdll into msvcrt pretty shortly and turn crtdll into a forwarding dll, as per the discussion(s) a couple of months ago (I may add a dll 'alias' facility to .wine/config instead of creating a forward dll, and remove crtdll completely. This will allow us to mimic other crts also). I'll be submitting a patch in a few hours that takes crtdll completion to above 80%. This represents about 40% of msvcrt (which contains all of crtdlls functionality and extends it). I estimate that the time to then make the functions threadsafe will be around a week, at which point winelibbers can start trying msvcrt out with their apps (providing they dont use UNICODE, see below), and we can start on the other 60%... IMHO, It would be much more productive for you to work on functions that haven't already been implemented, or that occur in msvcrt exclusively. It is going to be a large job completing msvcrt and working in different areas will allow a Winelib version to progress a lot faster. Since I will be working on msvcrt once the code shift is done, I would *really* like not to fix functions I have already implimented. Actually yes, my original focus, and my main goal is not to churn out tons of function implementations, but to provide a build environment with proper headers and an example of how to make a Winelib app that uses MSVCRT or CRTDLL as its C library. Note: the following is not a flame, just observations: And not taken as a flame either. Every implemented function in your patch
Re: MSVCRT
[EMAIL PROTECTED] wrote: On Sun, 17 Dec 2000, David Elliott wrote: Okay, this should all be acceptable for inclusion into wine. The .tar.gz contains the dlls/msvcrt and include/msvcrt directories. The .diff changes the following files: Make.rules.in configure.in dlls/Makefile.in include/Makefile.in I am not yet including the testsuite in programs/msvcrttest but I will be posting that to wine-devel with an explanation shortly. Changelog: * Added msvcrt and accompanying include files to the tree. -Dave Well, there are fewer unimplemented functions than before, but one of them seems to be initterm, so I still can't use juno version 2 without native msvcrt to send this. That's all right. I haven't finished the winelib program I intend to use to send mail from mutt through juno version 2 and I don't much like juno 2's GUI. Or any GUI, if truth be told. :-). Heck yeah, now that user32 is no longer required for CUI programs, my CD-R software and also my test suite for MSVCRT now run very well on a standard Linux console. I had to do the last hunk of dlls/Makefile.in by hand (I couldn't see anything wrong with the patch, but I guess patch has sharper eyes than I). It built a nice libmsvcrt.so, but it doesn't have initterm. Possibly because it is against current CVS and you are at the last release? There have been lots of changes to that file. Back to getting the types consistent in the winelib program... Lawson Good luck with your Juno hacking. Right now I am just trying to get MSVCRT into the tree so I can start producing normal patches to implement all of the features. You may have noticed the big fat warning (fixme actually) during the initial load of MSVCRT. Hopefully that will take care of any problems with people having builtin before native for the default load order. One other thing. If you need MSVCRT routines in your app, simply prototype them in the appropriate header file and then run your winelib app with native msvcrt. At least until more functions get implemented. Alternatively you could link the winelib program against the somewhat more implemented CRTDLL using the same prototypes. -Dave
Re: Calling conventions
Francois Gouget wrote: On Wed, 13 Dec 2000, David Elliott wrote: In order to allow __cdecl and __stdcall to be defined correctly without including Windows headers it is necessary to split their definition out into a new include file. This include file is then included into windef.h in the same place it was before. This include file will also be included in the msvcrt headers so that they don't have to include all of windef.h just to get the definition of __cdecl and __stdcall. I made a similar proposal to Alexandre recently but he wasn't too hot. One difference is that I chose to isolate all the things that would normally be provided by the compiler on Windows, and a few widely used very basic Wine-specific items, not just the calling convention macros. I had: - CPU macros (as part of the calling convetion, maybe it should be handled separately) - calling convention - anonymous struct/unions - ANSI/Unicode type/prototype support (the _AW macros) - Macros for structure packing (actually WINE_UNUSED, WINE_PACKED, ...) I called the new file 'wine/winedef.h' and I expected that it might be used in other Windows headers, should it turn out that one of them is not supposed to include 'windef.h'. But I actually don't know of such a header (except the C headers), so my case was a bit weak. I attached it so that you can have a look at it. Maybe I should revive it? You should definitely revive it IMHO. Alexandre has said himself that it is inappropriate for C library headers to #include windef.h. The most reasonable way to do this is to seperate all of the Windows compiler definitions into a new include file or to seperate them out into several new include files. At the very least the C headers themselves need __cdecl defined correctly so it definitely makes sense to seperate that out. However, I can not think of many programs that would use the other items on your list and not #include windef.h except for the anonymous structs/unions but that is probably a rare case anyway. In any case, something has to be done about this before Alexandre will even accept my patch for msvcrt since otherwise I will need to include windef.h and he has already expressed a dislike for that approach (which seems completely reasonable to me) -Dave
Re: Calling conventions
Alexandre Julliard wrote: David Elliott [EMAIL PROTECTED] writes: You should definitely revive it IMHO. Alexandre has said himself that it is inappropriate for C library headers to #include windef.h. The most reasonable way to do this is to seperate all of the Windows compiler definitions into a new include file or to seperate them out into several new include files. At the very least the C headers themselves need __cdecl defined correctly so it definitely makes sense to seperate that out. If all you need is __cdecl, I'd suggest a simple #define __cdecl /*nothing*/ in the msvcrt headers, instead of adding yet another Wine internal include. I'm not completely opposed to having a wine/winedef.h file, if it's really necessary; but so far it doesn't seem to be. Seeing as how __cdecl is after all the default and therefore doesn't absolutely need to even be specified I will just not specify it. However, defining __cdecl to nothing would cause problems because a program may include both a windows header and a C library header and therefore you would receive redefinition warnings when compiling. I'll just leave out the __cdecl altogether then, it's a Microsoft-ism and isn't needed on a real compiler anyway. -Dave
Re: programs/Makeprog.rules.in
Dennis Bjorklund wrote: Installfix. Remove old link before creating the new one. -- /Dennis Name: Makeprog.rules.in_remove_link_first.txt Makeprog.rules.in_remove_link_first.txtType: Plain Text (TEXT/plain) Encoding: BASE64 This is the incorrect fix. The correct fix is to use the -f flag (and possibly also the -n just in case it was symlinked to a directory. Adding the -nf option to ln will provide exactly this same behavior without requiring an additional rm command. Simply adding -f will fix the problem for most people... That is, winedbg used to be a file and is now a symlink. -Dave
Re: programs/Makeprog.rules.in
Dennis Bjorklund wrote: On Sun, 10 Dec 2000, David Elliott wrote: Installfix. Remove old link before creating the new one. This is the incorrect fix. The correct fix is to use the -f flag (and possibly also the -n just in case it was symlinked to a directory. Adding the -nf option to ln will provide exactly this same behavior without requiring an additional rm command. Simply adding -f will fix the problem for most people... That is, winedbg used to be a file and is now a symlink. Okay. I just saw that in many other places in wine where links are created they are first removed with $(RM) and then created with $(LN_S). I don't know it it a good idea to just add -f. LN_S is checked for by the ./configure. and I don't know if we can just add a "-f" since I don't know what different versions of ln there are out there. -- /Dennis Hmm, I would think that they should be available on all versions of ln. If not I suppose that would explain why I see people do an rm and then an ln -s instead of ln -snf. In any case, here is the patch that I made to my tree yesterday. I would have sent it in but my 'net connection has been very unstable lately for some reason. Could someone with other POSIX experience besides GNU tools verify if -nf is supported by other ln's? Or should it be -n -f? -Dave Index: programs/Makeprog.rules.in === RCS file: /home/wine/wine/programs/Makeprog.rules.in,v retrieving revision 1.3 diff -u -r1.3 Makeprog.rules.in --- programs/Makeprog.rules.in 2000/12/06 00:05:15 1.3 +++ programs/Makeprog.rules.in 2000/12/10 18:00:48 @@ -24,7 +24,7 @@ $(LDSHARED) $(LDDLLFLAGS) $(ALL_OBJS) -o $@ $(ALL_LIBS) $(MODULE): $(MODULE).so - $(RM) $(MODULE) $(LN_S) $(TOPOBJDIR)/wine $(MODULE) + $(RM) $(MODULE) $(LN_S) -nf $(TOPOBJDIR)/wine $(MODULE) # Rules for checking that no imports are missing
Re: programs/Makeprog.rules.in
David Elliott wrote: Dennis Bjorklund wrote: On Sun, 10 Dec 2000, David Elliott wrote: Installfix. Remove old link before creating the new one. This is the incorrect fix. The correct fix is to use the -f flag (and possibly also the -n just in case it was symlinked to a directory. Adding the -nf option to ln will provide exactly this same behavior without requiring an additional rm command. Simply adding -f will fix the problem for most people... That is, winedbg used to be a file and is now a symlink. Okay. I just saw that in many other places in wine where links are created they are first removed with $(RM) and then created with $(LN_S). I don't know it it a good idea to just add -f. LN_S is checked for by the ./configure. and I don't know if we can just add a "-f" since I don't know what different versions of ln there are out there. -- /Dennis Hmm, I would think that they should be available on all versions of ln. If not I suppose that would explain why I see people do an rm and then an ln -s instead of ln -snf. In any case, here is the patch that I made to my tree yesterday. I would have sent it in but my 'net connection has been very unstable lately for some reason. Could someone with other POSIX experience besides GNU tools verify if -nf is supported by other ln's? Or should it be -n -f? -Dave ARGH, patched the wrong damn line. Try this one instead. I actually tested this, and it works. -Dave Index: programs/Makeprog.rules.in === RCS file: /home/wine/wine/programs/Makeprog.rules.in,v retrieving revision 1.3 diff -u -r1.3 Makeprog.rules.in --- programs/Makeprog.rules.in 2000/12/06 00:05:15 1.3 +++ programs/Makeprog.rules.in 2000/12/10 18:37:52 @@ -41,7 +41,7 @@ install:: $(MODULE).so [ -d $(bindir) ] || $(MKDIR) $(bindir) $(INSTALL_PROGRAM) $(MODULE).so $(bindir)/$(MODULE).so - cd $(bindir) $(LN_S) wine $(MODULE) + cd $(bindir) $(LN_S) -nf wine $(MODULE) uninstall:: cd $(bindir) $(RM) $(MODULE) $(MODULE).so
Re: PATCH: INT13 (READ/WRITE SECTORS)
Joerg Mayer wrote: On Fri, Nov 17, 2000 at 12:57:18PM +0100, Frank Cornelis wrote: I wrote a little patch to support INT 13 read/writing of sectors on a floppy disk. If it's OK, please merge it with the CVS tree. ... + sprintf (dev_name, "/dev/fd%d", drive_nr); ... + sprintf (dev_name, "/dev/fd%d", drive_nr); ... Is there a reason why you don't use the devices from the wine.conf file? (Sometimes it might be helpful to work with a loop device instead of the real drive). I am guessing one reason is that the devices in the wine.conf generally point to a partition. Now obviously with floppies the device would match, but for a hard-drive it's different. In fact, it really ought to allow assigning a numbered BIOS INT13 device to a specific device seperate from the drive letter definitions. Like: [Int13] Bios0=/dev/fd0 Bios1=/dev/fd1 Bios80=/dev/hda Bios81=/dev/hdb Or something like that assuming that I am remembering correctly that floppy drives are 0-7f and hard drives are 80-ff. -Dave
Re: Loadorder no more honoured
Taral wrote: On 11 Nov, Uwe Bonnes wrote: So when at some point built-in shell is loaded, this results in dlopen_dll called for shell.dll and and rpcrt4.dll,ole etc are loaded from the builtin files unconditional. How to fix that? Rewrite wine to compile its dll-replacements as dlls instead of using an ugly hack with .so files. Eh? I don't think so. They need to be elfdlls, that is, still be SOs that can import native OS functions, but are imported by wine apps like real windows DLLs. It seems that Alexandre or someone is working on this by the last couple patches to winebuild and so on. -Dave
Re: RFC: MSVCRT (updated RFC)
Alexandre Julliard wrote: David Elliott [EMAIL PROTECTED] writes: Now that I have that figured out I'll fix all of those problems and ditch the libwinemsvcrt because the way it is linking now is actually exactly how I want it to link anyway without needing to do stupid hacks. But the way it will link in the future is not the same as it is now, and is closer to what you thought it was doing now (confused yet? ;-) No, not at all confused. I think what I thought it was doing is almost exactly what it will do in the future. Basically now Winelib linking completely bypasses the spec file and links directly to the internal functions (the MSVCRT_* in your case). In the future it will link to the names as exported from the spec file. Yup, I figured that out too after trying to see what would happen if I tried using a function that wasn't implemented in libmsvcrt.so but was forwarded in libwinemsvcrt.so. It then dawned on me that it was really grabbing the symbols from libmsvcrt.so like a normal UNIX program. This doesn't mean however that you should export MSVCRT_* like you did in your libwinemsvcrt; it means that the Winelib app should be compiled perfectly normally, using standard C functions, and all the magic will happen at link time. So once the new mechanism is in place, you should no longer need any #define xxx MSVCRT_xxx, or any MSVCRT_xxx prototype in the header files. Well for now it seems like this is the best way to do things (which you seem to agree with). However, I don't really want to have to change a bunch of headers when winebuild is fixed, and I doubt that you do either, so I propose the following: #define MSVCRT_SYMBOL(s) MSVCRT_##s PVOID __cdecl MSVCRT_SYMBOL(malloc) (MSVCRT_size_t size); I think it would be reasonable to keep naming the structures with the MSVCRT_ prefix and using a bunch of typedefs to get rid of the prefix when compiling a winelib program. Not doing so would make the headers get REALLY messy with MSVCRT_SYMBOL all over the damn place. Eventually when the MSVCRT_ prefix is no longer needed it can easily be redefined. However, when compiling the MSVCRT source itself (which #include's these header files with #include "msvcrt/header.h") we still want the MSVCRT_ prefix and therefore we can use the define as shown above in this case. I will put that #define into a seperate header and #include it from all of the headers. Then when the change is needed I can change the one header file and it'll be good to go. I think I could probably put that in windef.h as I think most of the headers are including that anyway. The only other thing that would be needed is to remove all of the #define magic for the functions, which will be a very simple task, of course I could always put these in an #ifndef FINALLY_FIXED_WINEBUILD or something. Actually, I could do that anyway for clarity whether or not it ever got used it would at least mark which lines to remove. Does this sound reasonable to you? I have actually thought of several different ways of tackling this problem, but this seems to be the easiest to me and I don't want to bother you and others with 20 different ways to do something when this appears to be the best way to do it. -- Okay, now onto what I actually have done so far. Attached are the new versions of things (same filenames as before). I now simply have a libmsvcrt and a winelib program to test it. It is against the now current CVS. As before you will need to run autoconf and tools/make_debug unless you want to be lazy and attempt to apply the lazy patch (which is really only included because it was part of the cvs diff anyway). The tar should be extracted into the toplevel sourcedir as before. In the programs/msvcrttest/Makefile.in I have hardcoded the path to my compiler's include files (like stdarg.h). One way I have come up with to find your compilers include directory looks like this: echo "#include stdarg.h" | cpp -M | sed 's/^-: *\([^ ]*\)\/stdarg.h.*/\1/' That actually works on my system, but I am not sure how portable that is or maybe there is a better way to do things other than using -nostdinc on the compiler's commandline. Right now I am of the opinion that in a winelib program things like stdarg.h should work with the compiler's conventions and not MSes. Therefore I am not including a stdarg.h because the winelib program should use the compiler's include file. This is especially true if the program implements and calls varargs functions within itself. It *MUST* use the compilers definition to work right. Of course, all this is a non-issue for most winelib developers since GNU C on ix86 is binary compatible with MS AFAIK. I need a bit of input on how to deal with this. vprintf and friends comes to mind as a potentially major problem. Right now I think the best thing to do is to put some FIXME's in the c
Re: RFC: MSVCRT (updated RFC)
Francois Gouget wrote: On Thu, 2 Nov 2000, David Elliott wrote: [...] Okay, I can understand why not to use windef.h. But I figured if its a hack it might as well really be a hack. I won't use windef.h anymore but will instead typedef int INT; in the MSVCRT header files. I think that is the only definition I wanted anyway. Why do you use INT? The Microsoft headers use int like any well behaved C library header. In particular exit, _exit, and _errno all use int. Well, I was thinking that we would want the types to be the same as Win32 and therefore use INT which could later be defined as a 32-bit integer if int was 64-bit on the platform. I am not really familiar with how different compilers handle the size of an int. It was my understanding that it's usually the native int on the processor which would not work very well for binary compatibility. But maybe I could be wrong in my thinking and I should just go ahead and use int. -Dave
Re: msvcrt.dll
Jon Griffiths wrote: Hi David, I was working on crtdll until about 3 weeks ago when i took a months holiday. I'll be back in a couple of days and intend to start working on it again, so we should probably discuss some aspects of the implementation. I submitted a much fixed/extended patch than the one sent to winehq to Alexandre before I left (the winehq version has several bugs and shoulnd't be used, it was really put there for discussion), however he didn't accept it based on the way file mapping is currently done. I will be changing the patch as it stands to conform to the style Alexandre suggested it (minor) and resubmitting it within a week. The one on winehq.com looked particularly bad in a lot of places to me anyway. I suppose you have a better version that I haven't seen yet. Alexandre and most of the wine developers are really picky about what goes in. Don't feel bad because I have been in the same position, it takes a while to get used to the Wine tree and some of the philosophies. I have had several patches rejected one or two times before getting accepted. Hell, even recently due to a design issue. i have just been reading the develop mailing list and caught your comments, i agree with most of the points that were raised during the discussion and have a few of my own: -fairly few functions can be implemented using the native glibc/libc. any function that uses file or allocates memory must be re-written (you cant use crt mem functions on crt allocated memory). also structures should be binary compatable with windows even on big endian machines. True, but I have one concern. Have you looked at the MS provided MSVCRT source? If you have I would suggest consulting with a lawyer before sending in any patches. As I said before, a broken but mostly working MSVCRT is better than an illegal one. This is one of the FAQs and you really need to be careful about this. However I suppose if you have and you could describe it to me then I could implement it and it would be okay (this is how Compaq cloned IBM's BIOS IIRC). I am more than willing to sign a sworn statement that I have not looked at the code. This is especially important as it's highly likely that I'd implement something almost exactly like MS, and if I looked at the code it would seem as if I just copy and pasted it even though I didn't and that's definitely uncool. I might be overreacting, but better safe than sorry. Also, I do not have a big-endian machine to test, but I generally write good portable code so it should only require minor changes to work if Wine ever actually runs on other archs. Winelib of course works on some other archs, but in that case binary compatibility is somewhat of a non-issue. -compatable headers for winelib should be low priority until the implementation is mostly complete, otherwise we could break existing winelib users. this can be relaxed where headers arent used under unix. Absolutely not. Compatible headers are a top priority for me and especially a top priority for those developing with Winelib. I am doing this more for winelib than for wine. -msvcrt *is* crtdll, with an extra 565 functions implemented on top, and made threadsafe. the common functions should be the same code. crtdll should be made threadsafe, the performance overhead for programs that use crtdll is minimal, and then the code can be shared. plus the difference between threadsafe and non threadsafe is only a line or two in some functions. Hmm, okay. MS must have had a reason for making MSVCRT rather than just adding the functions to CRTDLL and making some of the existing ones threadsafe. If that is the case then it leads me to believe that some functions will need to be implemented differently. Or maybe MS was just stupid which doesn't surprise me either. However, I do agree that when possible CRTDLL should use the MSVCRT implementation. crtdll.spec will mostly turn into "@ forward function MSVCRT.function" Unless there is a specific reason to implement it differently for CRTDLL. -I am using several programs that rely on crtdll, and crtdll is included in win2k (modified 12 July 1999). Sounds good. I am not saying CRTDLL should not be worked on, I am just saying that MSVCRT is more of a priority as far as winelib is concerned since it would be the one used by a winelib program. I am more concerned about winelib than wine for this particular case, especially because MSVCRT is included if you download IE anyway. let me know what you think - if you want me to mail you my latest patch I can do it when i send it to alexandre for resubmittal. pretty much all file functions are now implemented along with a whole bunch of other stuff. I also have a testbed which works for testing lots of crtdll and mscrtdll functions. I will have a look at your patch when I get back and get on to my pc as well, and might have some more comments for you then. Actually,
Re: Build system
"Dimitrie O. Paun" wrote: Well, it looks like it's time for discussions about the future of Wine. So, here is something that has been on my mind for quite a while now: the build system. In a nutshell, we should have a build system that allows building Wine in a variety of ways: different compilers, output formats, etc. In more detail, it seems to me that we (should) support: A. Build environment Supported: Linux, FreeBSD, Solaris Future: cygwin? (at least for some DLLs) Why not: win32 (at least for some DLLs) B. Compilers / Runtime Supported: gcc, cc (solaris) (Patrik?) Future: cygwin, mingw, uwin (again, at least for some DLLs) Why not: msvc, bcpp, etc (ditto) C. DLL formats Supported: ELF, PE, elfdll (?) Question: what is the status of elfdll, and what exactly does it do? D. Run environments Supported: Linux, FreeBSD, Solaris Future: MacOSX, BeOS Why not: Windows (at least for some DLLs) The idea being, of course, to support as many combinations as possible (and where applicable, cross-platform as well). With such a system in place, we could, for example, compile comctl32 on Linux using gcc to produce a PE that should run in Windows. This can give us an idea about how well we've implemented a component for example. Now, not all DLLs can be compiled in all these different configurations. The entire point of this exercise is to come up with a system that is flexible, powerful, and easy to use that will allow us to declare what make sense where. But before we go into details, do people agree that such a system would be useful? I have thought of this myself, and it wouldn't be all that hard to do. All you need to do is make use of autoconf for many of these issues. The one thing that stands out is that you need some sort of UNIX on top of win32 layer to actually run ./configure. In addition, all the makefiles are fairly unix specific. I suppose with a bit of magic this could be done in a fairly clean way and would not effect the day-to-day hacking of wine for most people. The key is that if you make it harder for me to develop Wine on Linux because you want to support other platforms I am going to be kind of pissed. I would say that most developers feel the same about this. Maybe the first step would be to allow parts of Wine to be cross-compiled on a Linux system making real Win32 .DLL files. One issue with this is that many packages allow you to do something like: cd packagesourcetree mkdir CROSS cd CROSS ../configure (with appropriate options for cross compiling) make Is it possible to do this with the wine sourcetree? That is, can you have the built files in a seperate dir from the sources? If not then this is the first thing to fix as having two complete copies of the sourcetree just to allow building for different targets is going to make your life a living hell. -Dave
Re: Wine packaging - the kitchen sink?
Jeremy White wrote: Okay, I'm hoping we can achieve convergence on packaging standards and agree on what packages should look like and do. However, I think we've got some problems/issues and I thought I'd try to rehash the ones I remember. If I've missed any, or explained them poorly, please correct me. 1. At package install time, should we create a global wine.conf? View 1: No - we supply something like wine.conf.template, and then walk the user through using winecfg of wineconf to get their own .winerc. View 2: Yes. We autobuild a global wine.conf file during the install process. With debian, we can do this somewhat elegantly due to debconf. Side issues: With View 2, there is a hope that Wine can support a true multiple user configuration. Some of us feel that this is not worthwhile to try to support at this time. Perhaps we resolve this by saying that for debian, because of debconf, we take view 2, and for RPMS, we take view 1. I hate to diverge, but I think the opposing views are pretty entrenched. No, do that. At least to begin with. Get some RPMS out and around, then work on doing #2 immediately. I dunno what to do with deb. If Ove is still interest in hacking a kick-ass debian package together then you will be able to look at Ove's stuff to come up with an equivilant for RPMs rather than reinvent the wheel. 2. (Not yet discussed) - What packages do we provide? Marcus provides one - Wine. Ove provides five - libwine-dev, libwine, wine-doc, wine-utils, and wine. I would argue that Marcus provides too few, and that Ove provides too many. Well sort of, but Ove's situation may be better for debian. On RedHat I would suggest the following names: wine: All things required for running windows exes and winelib programs and any utilities necessary for configuration (like regapi and wineinstall and stuff) (so like Ove's wine and libwine and part of wine-utils packages I guess) wine-devel: All things required for developing wine applications. Also include utilities like winebuild that are needed for winelib development (Ove's libwine-devel I assume) wine-doc: All kinds of wine documentation. Don't forget to use the appropriate macro for the docdir as some RPM systems use /usr/doc while the newest redhat has gone to /usr/share/doc to be more inline with the new filesystem standard. However, it may be a good idea to have some of the documentation as part of the main wine package, especially things related to configuring wine on the system. wine-utils: Extra utilities that aren't needed but are good to have anyway. So I guess that makes 4 then, and in a slightly different manner than Ove. However, Ove may have good reasons pertaining to the way Debian likes packages to be done that dictated which files he put in the packages in order to be accepted for official debian inclusion. RedHat doesn't really have any set rules and thus we can do what we think is appropriate for our project. Remember that packages are not for *us*, they're for end users. IMHO, end users really want one of two things: 1. Wine - to run my app 2. Winelib - to build my app (okay, no one really wants this yet, but they're going to if I have anything to do with it g). I think splitting off the doco to save users download time is perfectly reasonable, and won't confuse end users. However, I think the current split into five, while I understand the motive, is confusing to the end user. Right, I will probably never have a packaged version of Wine on my system for very long unless I am testing it or something. All my stuff comes out of CVS. See above for me thoughts on what the packages should be named. 3. Concern - winecfg dependencies When designing winecfg, we chose Tcl/Tk, partly because that's what TkWine used, and we were trying to expand on that, and partly because we didn't have a clear alternative. Initially, Martin built winecfg for distribution linked entirely against static libraries. This meant that winecfg created no new dependencies on new users. However, it increased download sizes fairly signficantly. So, the current thinking is to have winecfg linked completely dynamically, and impose these requirements. Maybe we need to go back to the drawing board and reexamine this issue; perhaps some libraries could be static, and some dynamic. I think the goal would be to have the Wine packages work perfectly on 'stock' distributions (i.e. RH 7, Suse 7, OpenLinux 2.4, etc).
Re: Wine packaging - the kitchen sink?
Ove Kaaven wrote: On Tue, 31 Oct 2000, David Elliott wrote: One thing I was thinking of was the issue of Wine's binary compatibility, especially from the point of view of codeweavers. I am assuming you are doing all of this so you can setup an environment for running the programs that you are porting. This may be a non-issue as i think most core issues are near-finalized. However, we may want to plan for the future and allow multiple copies of wine/winelib to be installed. Isn't this a problem that was solved long ago by the invention of ELF library versioning? In its simplest form, it goes like this: libwine.so.1.0 = old winelib apps links with this libwine.so.2.0 = new winelib apps links with this Binary compatibility was an issue that we wanted to address at Wine 1.0. You've got a point about the ELF versioning. This indicates to me that your method of a libwine package is a good idea. I therefore ammend my suggestion as follows: wine: This package should be like I said before, but should not contain the libraries. That is, it should be the emulator and related stuff, since if you think about it, the emulator is basically just a wine application. libwine.so does belong in this package though, since it is only used by the emulator AFAIK. wine-libwine: This package should be all the libraries required to run winelib programs. The reason I suggest this is so that it would be possible to have several different wine-libwines installed. If binary compatiblity is broken, an updated set of packages will be provided, and you can still keep your old wine-libwine package and not have file conflicts. Although unless you updated the version of every library you'd still get file conflicts unless you package every library seperately (which may not technically be a bad idea assuming the right Requires: lines are used, but this could be somewhat of a PITA for users to have to install several packages, one for each dll). Or maybe you could use a hibrid system. Like put all of the core components in a package (kernel,user,gdi,ntdll,libwinelib,etc.) and then have seperate packages for the other dlls that are properly seperated in the code. Once again Ove, you have the right idea in the first place, with these changes, my recommendation is essentialy what you are already doing (but with different names because of the RPM-Debian differences). -Dave
Re: Wine packaging - the kitchen sink?
"Dimitrie O. Paun" wrote: From: "David Elliott" [EMAIL PROTECTED] wine-doc: All kinds of wine documentation. Don't forget to use the appropriate macro for the docdir as some RPM systems use /usr/doc while the newest redhat has gone to /usr/share/doc to be more inline with the new filesystem standard. However, it may be a good idea to have some of the documentation as part of the main wine package, especially things related to configuring wine on the system. We really do not need this package. Really guys, we do not have that much docs anyway, and the potentially big ones belong in the -devel package anyway. Moreover, for people that are really tight on disk space, rpm has flags to skip the installation of the bundled documentation. All we need is: wine, wine-devel, wine-utils (maybe) It's always a hassle to d/l and install more packages than necessary. KISS. -- Dimi. DOH! I forgot about rpm having the option to not install documentation (I have 40GB, so haven't needed it).. good idea. Yes, don't have a seperate docs package but instead include the various docs either in wine or wine-devel (or wine-utils) depending on what they pertain to. I totally agree with this. -Dave
RFC: MSVCRT
Hi, I have started implementing MSVCRT for Wine and specifically for use with Winelib. Attached are three files, msvcrt.diff, msvcrt_lazy.diff, and msvcrt.tar.gz The msvcrt.diff contains the changes you will need to make to your wine source tree (against the CVS of about 20 minutes ago). The msvcrt_lazy.diff contains the diff you will need if you are too lazy to run autoconf and tools/make_debug (but this could bite you in the ass, so if you have autoconf on your system, you should use it). The diff to configure has some extra stuff in it because apparently my autoconf is a bit different from the one Alexandre uses. The msvcrt.tar.gz contains the new files for msvcrt and a winelib application (in programs/) that will test the msvcrt implementation. Somehow the CVS directory got into dlls/msvcrt, dunno how cause I don't remember it being in CVS. Maybe this is a CVS "feature". The libwinemsvcrt.so is an idea I had to resolve the issue of symbol naming. A winelib program wishing to use MSVCRT for its libc links against winemsvcrt. The header files are designed with #defines so that when a program uses for example exit(0) it translates to MSVCRT_exit(0). Thus the issue of naming is dealt with during the compile as opposed to hacking link defines. The drawback to this approach is that importing of other DLLs from a DLL is somewhat broken in that WINEMSVCRT does not correctly load or initialize the MSVCRT library since the winebuild generated code does not do this correctly. Eventually this should be done correctly and WINEMSVCRT will even load a native MSVCRT. Another possible implementation of the winemsvcrt library is commented out in the dlls/msvcrt/winemsvcrt/Makefile.in file. It creates libwinemsvcrt by appending MSVCRT_ to the names in the msvcrt.spec and reusing the .o files used to create msvcrt. The drawback to this approach is that it duplicates some binary code and will not allow the native msvcrt to be used. It also won't allow you to use a native msvcrt for winelib. This was my original way of doing it, provided only for reference. I personally prefer obfuscating the function names over fooling with linkorder, but I would like other people opinions about how to handle the conflict with real libc names. For what it's worth, I believe MinGW32 uses my system of obfuscating names. Another advantage to my approach is that different sourcefiles of the same program can use different headers and thus use both the real libc functions and MSVCRT functions in the same program. It also makes the headers look a lot cleaner than they would if the function names had to be different for internal wine building and winelib building. In the programs/msvcrttest directory there is a stdarg.h from gcc 2.96 included. This is only because I haven't yet provided a stdarg.h and one of the wine headers needs some definitions from it. There is also an empty string.h because it is included in include/winnt.h (presumably as a courtesy include because it doesn't seem to use it). I really want input from everyone on this, especially anyone at Codeweavers working on this or thinking about it. I know Francois had expressed some interest. Also, I would like some people more familiar with legal issues to let me know if it would be okay to look at MSes provided source to MSVCRT. I am thinking no, and thus I have not and will not look at it. I think I have it on my MSVS CD here, and it would help a lot with issues like binary compatibility, but I'd rather have a slightly broken but legal MSVCRT than one that could get me and others into legal trouble. That and if I happen to implement a function exactly like MS (just by coincidence, for example, I would imagine malloc and free have a similar implementation) I don't want the issue coming up that I have seen the source and might have directly copied it. Have a good day! -Dave ? dlls/msvcrt ? include/mixedcrt ? include/msvcrt ? programs/msvcrttest Index: Make.rules.in === RCS file: /home/wine/wine/Make.rules.in,v retrieving revision 1.69 diff -u -r1.69 Make.rules.in --- Make.rules.in 2000/10/31 00:20:51 1.69 +++ Make.rules.in 2000/10/31 04:50:40 @@ -121,6 +121,8 @@ msacm.drv \ msacm32 \ msnet32 \ + msvcrt \ + winemsvcrt \ msvfw32 \ odbc32 \ ole32 \ Index: configure.in === RCS file: /home/wine/wine/configure.in,v retrieving revision 1.155 diff -u -r1.155 configure.in --- configure.in2000/10/23 21:32:05 1.155 +++ configure.in2000/10/31 04:50:56 @@ -1065,6 +1065,8 @@ dlls/mpr/Makefile dlls/msacm/Makefile dlls/msnet32/Makefile +dlls/msvcrt/Makefile +dlls/msvcrt/winemsvcrt/Makefile dlls/msvideo/Makefile dlls/ntdll/Makefile dlls/odbc32/Makefile @@ -1135,6 +1137,7 @@ programs/clock/Makefile programs/cmdlgtst/Makefile
