wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

RE: Wine license change
by Patrik Stridvall 07 Feb '02

07 Feb '02

[Oh, no here we go again] > Some recent events have occurred that have made me change my opinion > about a Wine license change. I see. > During my involvement in the Wine project, I have always striven to > make sure that I, and my company, did what was best for the Wine > project. Before I critize you to much. I would like to point out for the record that I do believe that you and Codeweavers as far reasonable possible have done what you claim and that you have my gratitude and respect for that. However remember that: "The road the hell is paved with good intentions." > I believe Wine's success will help to make the world a > better place. Partly agreed. I believe that people moving from Windows to Unix is a good thing and that Wine (or Wine like projects) are among the nessary tools to acceive this. It is not the only tools though. > To that end, often through difficult personal > negotiations, I have always insured that all of my contracts require > that all code changes be returned to Wine. This, in effect, treats > Wine as an LGPL product. You have my respect for that as explain above. However I'm not entirely convince that this always is a good thing. It is a probably a good strategy by average but do not believe it is always the right thing. In military terms: A strategic retreat is often good, eventhough retreat as a strategy is not. > You can argue that the flexibility granted by the Wine license has > meant that I received some business I would not otherwise have had. > Gav, for example, has pointed out that Corel would never have worked > on Wine if not for its license. There are two ironies there - first, > Corel has always been a great Wine citizen, IMO, never 'abusing' the > license. Second, while we did work with Corel to help them with Wine, > we never signed a contract with them. Their lawyers and I were never > able to agree on a contract that we thought would sufficiently protect > Wine. Fortunately for me, we were able to work with Corel without a > contract, but this issue to this day creates unnecessary friction > between my company and Corel. Read that Gavriel have written again. Surely you must realize that there is a difference between: 1. Specificing a goal in the beginning and be legally forced to stick to it until the end no matter what. 2. Specificing a goal in the beginning and be legally able to retarget when reallity didn't turn out as you expect. There is a difference between striving to do good and being forced to do good because of an earlier promise despite the fact that reality has changed. > However, with some recent events I cannot disclose, it is clear to me > that the opportunity for Wine to be used in a proprietary product is > too tempting and has caused some harm to the Wine project. Based on > experience, I feel strongly that the potential for harm is great > enough that CodeWeavers needs to take two actions. First, we would > like to release all new code we develop under an LGPL style license. > Second, I would like to open another call for a license change and > thereby strongly add my voice to Alexandre's. Luckily for you your credibillity is pretty high. Normally I immediately raise the red flag of warning then I heard claims made referring to undisclosed information. I understand that you are worried about the future but don't let your fears drive you onto the wrong path. > Thus, I would like to call for a change in the Wine license. I think > we all agreed that the LGPL formed the basis for a good 'alternate' > license strategy. Eben Moglen, the counsel for the FSF, has kindly > offered to help review licensing strategies for Wine. The goal is to > attempt to secure some form of Copyleft protection for Wine while > still permitting proprietary software to link and bind with Wine. I > think it it is great that we have, in Eben, not only the leading legal > scholar on free software licensing, but a great hacker to boot. I > think he will clarify exactly what is possible and what is not > possible with GPL style licenses and insure that the license we choose > will meet our goals. Talking to Eben can only help. However we need to very careful to specify not only what we want to acceive but also and MUCH more importantly what we want to _avoid_ the license from accidently preventing. So what do you want this new license to acceive? And the much more important question what do you want to avoid the license from accidently preventing? > When Alexandre last brought up this issue, he was very disappointed. > He felt that there was not enough support from the 'silent majority' > of Wine developers for a license change. His overriding lament to me > was 'No one cares'. I care. > He further felt that since a small number of > major Wine contributors objected, that it was not appropriate to > change the license. > > I would like to ask for a more formal process. I would like each and > every contributor to Wine to send Alexandre a private email with an > 'Agree' or 'Disagree' opinion, so that he can more truly assess what > the contributors to Wine really want. The specific question I wish to > pose is as follows: > > Should the Wine project switch to a license which has as > its goal to attempt to secure some form of Copyleft > protection for Wine while still permitting proprietary > software to link and bind with Wine? > > Please privately let Alexandre (julliard(a)winehq.com) know what you > think, and then publicly respond to this thread as you feel > appropriate. Done. > Finally, in closing, I wanted to summarize our position. We plan to > release our future work under an xGPL style license, and we would like > the rest of the Wine community to join us. If the bulk of the > community wants to stick with the current license, then we will > probably end up making a separate CVS development tree. Anyone would > be free to use our work from that tree, under the xGPL-style license > terms the FSF's lawyers recommend. Is that a threat or what? Hmm. I think I will intrepret is as symptom of your fears and advise you to try and avoid acting in a hastely manner. By all means start a dialog the FSF lawyers, but don't do anything you might later regret.

1 0

Conferences
by Keith Matthews 07 Feb '02

07 Feb '02

Speaking of conferences, is anyone planning on going to FOSDEM (16th & 17th Feb, Brussels) ? -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration

2 1

Example of ODBC and wine
by Ricardo 07 Feb '02

07 Feb '02

has anyone used wine with a program that conects to an ODBC database? How have you set this? I was thinking about FreeTDS but i configured it and doesn't know what to do nexe. Any help? Thanks Ricardo

2 1

Re: Wine license change
by Dave Jones 07 Feb '02

07 Feb '02

I like the LGPL and all, but I think converting to this license will hurt greatly the current projects such as Lindows and Transgaming and, in proxy, hurt wine. Mindshare is important, and to see Wine in succesful projects helps people to realize it as a viable product. I don't think anybody is turned off from developing wine with its current license, but the change would turn away many I'm sure. Some people get thier paychecks working on Wine (Transgaming). I think TG has done great things for Wine, and I wouldn't have supported them had they not promised to release thier changes back to the main wine tree. Lindows, however, can eat it. By not intending release thier changes and to sieze the Wine code to make it thiers for profit, I cannot, and will not support them. What I would like to see is a new licence that sees that all forks move back into the main wine tree at regular intervals, say, after 6 months or a year while still allowing companies to do what they will with the code. We aren't looking to stifle innovation here, I like the TG subscription model, and I would probably contribute in that kind of fashion to many projects, but there must be an incentive to do so (like TG's DirectX work) I am against a change to LGPL, but I realize the current license is allowing lindows to stand on the shoulders of giants and wearing a long overcoat to cover it up, and that is just wrong. Dave Jones - dajones(a)purdue.edu

1 0

Re: Wine license change
by Robert Boucher 07 Feb '02

07 Feb '02

Just a quick question that I haven't seen addressed: If the license is changed to LGPL, who will own the copywrite? The contributors, or the Wine Project? -Rob

2 1

Wine license change
by Jeremy White 07 Feb '02

07 Feb '02

Folks, Some recent events have occurred that have made me change my opinion about a Wine license change. During my involvement in the Wine project, I have always striven to make sure that I, and my company, did what was best for the Wine project. I believe Wine's success will help to make the world a better place. To that end, often through difficult personal negotiations, I have always insured that all of my contracts require that all code changes be returned to Wine. This, in effect, treats Wine as an LGPL product. You can argue that the flexibility granted by the Wine license has meant that I received some business I would not otherwise have had. Gav, for example, has pointed out that Corel would never have worked on Wine if not for its license. There are two ironies there - first, Corel has always been a great Wine citizen, IMO, never 'abusing' the license. Second, while we did work with Corel to help them with Wine, we never signed a contract with them. Their lawyers and I were never able to agree on a contract that we thought would sufficiently protect Wine. Fortunately for me, we were able to work with Corel without a contract, but this issue to this day creates unnecessary friction between my company and Corel. However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's. Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. I think it it is great that we have, in Eben, not only the leading legal scholar on free software licensing, but a great hacker to boot. I think he will clarify exactly what is possible and what is not possible with GPL style licenses and insure that the license we choose will meet our goals. When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license. I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows: Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine? Please privately let Alexandre (julliard(a)winehq.com) know what you think, and then publicly respond to this thread as you feel appropriate. Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend. Thanks, Jeremy

13 21

RE: Wine compile on MSVC?
by Patrik Stridvall 07 Feb '02

07 Feb '02

> Is this correct that tests are made to compile Wine on MSVC? Only on a small scale, nothing really serious yet. > What good > is this for? I thought Wine should be an emulation of windows > code on a > Unix platform, what good is it to run Windows on Windows? > > Just being curious. :) Well. I qoute myself: "It would be quite nice to have all non core DLL compiling and working and with winetest ported. Then you could just run winetest through the debugger and be able to set breakpoint and step through the code in Visual Studio in order to get all to tests to run properly. :-)" Also note that this would make it possible to debug each dll in an enviroment where all other DLLs except the DLL tested were real Windows DLLs.

2 1

Wine compile on MSVC?
by Gerhard W. Gruber 07 Feb '02

07 Feb '02

Is this correct that tests are made to compile Wine on MSVC? What good is this for? I thought Wine should be an emulation of windows code on a Unix platform, what good is it to run Windows on Windows? Just being curious. :)

1 0

RE: Header files not present on Windows
by Patrik Stridvall 07 Feb '02

07 Feb '02

> >Eventually I guess that the non-core DLL:s never should call any > >non Windows functions at all and the core DLL:s are not really useful > >to compile and run under Windows anyway. > > Well I have only played with the shell32.dll and in any file > in there except > "shelllink.c" removing "unistd.h" entirely had no negative > effect whatsoever. > This means to me that it is not needed at all. The use of > fork(), execvp(), and > waitpid() in "shelllink.c" however seems to require the > "unistd.h" header. > > I'm not sure if shell32 should be considered a core DLL. It > seems to me > rather not. shell32 is not really a core DLL eventhough it is a borderline case since some functionallity might want to intergrate with the desktop. However, it definitly should compile under Windows at least with limited functionallity. > The desired operation could be possibly achieved > with the use > of Windows kernel functions as well. Possibly, but it looks a little Wine specific to me. I'm not 100% sure what the code does. Anyway, we could always choose to exclude that code on Windows. It would be useful to run test on the rest of the functionallity in any case.

1 0

(FWD) Announcing wineconf 2002
by Ove Kaaven 07 Feb '02

07 Feb '02

I received this today... it seems Lindows seem to want to host a Wine conference. I noticed that they misspelled Alexandre's name and email address, though they claim to work with him. Since this is supposed to be an open conference anyway, and it's not a secret (most of the mail is just a straight dump of the webpage they link to anyway), I decided to forward it to wine-devel (but without the HTML). ---------- Forwarded message ---------- Date: Tue, 5 Feb 2002 14:21:18 -0800 From: Cheryl Schwarzman <cheryl(a)lindows.com> To: uczekalla(a)codeweavers.com, andi(a)rhlx01.fht-esslingen.de, andrew(a)transgaming.com, aric(a)codeweavers.com, bon(a)elektron.ikp.physik.tu-darmstadt.de, brianv(a)ski-copper.com, dimi(a)cs.toronto.edu, dmitry(a)codeweavers.com, ekohl(a)codeweavers.com, eric.pouech(a)wanadoo.fr, fgouget(a)free.fr, franciosj(a)macadamian.com, galberte(a)neo.lrun.com, gav(a)transgaming.com, gerard.patel(a)asi.fr, hdavies(a)codeweavers.com, james(a)macadamian.com, jasonfilby(a)yahoo.com, jefft(a)xandros.com, juilliard(a)codeweavers.com, jwhite(a)codeweavers.com, lionel.ulmer(a)free.fr, marcus(a)jet.franken.de, mike_mccormack(a)start.com.au, ovek(a)transgaming.com, ps(a)leissner.se, ridgway(a)winehq.com, sanderv(a)xs4all.nl, tephane(a)macadamian.com Subject: Announcing wineconf 2002 Announcing wineconf 2002 We believe 2002 is the year WINE really breaks through to have a major impact on computing. Many of you have had the vision and dedication long before Lindows.com was around. And it's all of you who deserve the credit. As a small token of our gratitude, we want to do our best to host the first conference dedicated to WINE called wineconf. As the host, Lindows.com will pay the cost of putting on the conference including venue, food and other necessary arrangements. The agenda and speakers will be the members of the WINE community. It will be a two day event on Friday and Saturday where new ideas can be shared, new connections made, and you can hear from the best and brightest pushing the WINE initiative forward. We have dubbed the event wineconf and it will be open to all who wish to attend. We don't expect a large crowd given the highly technical focus. Working with lead WINE mind, Alexandre Juilliard, we have come up with a list of people whose historic contributions to WINE deserve extra recognition. To this group, we're making a special offer by picking up their airfare to and from San Diego for this event. This is Lindows.com way of thanking those who have made contributions in the past to get WINE to the level it is at. We will notify you personally, if you are in this list. If you are not on this list, you are still welcome to attend with no registration fee, but you will be responsible for your own transportation. Hotel costs will range from $75-125 per night. The agenda will be sent out several weeks before the conference outlining the topics and speakers. We will be working with attendees and speakers to ensure we touch all the areas of interest. wineconf will be held in San Diego, CA on March 15th-16th, 2002. We selected San Diego for two primary reasons. First, because it's our home town we can keep the costs down on the venue, transportation, computer facilities, etc. Like all startups (that weren't born in 1999!), we have a finite budget we're trying to stretch as far as possible. Secondly, since WINE is a worldwide effort there's no ideally centralized location, so we selected a place that should be nice and warm in March. (San Diego is 25 minutes south of LA by plane or 1.5 hours by car.) The specific agenda will be forthcoming as we work with WINE contributors to get their input and guidance. You can register online by going here: www.lindows.com/wineconf We hope you can make it! Registration Form: First Name: Last Name: Email: Company: Address: City: State: Zip: Country: Phone: Topics You Would Like To See Discussed: Speakers You Would Like To Hear From: ------------------------------------------------------------------------ Optional Part (for those we will be paying for air transportation) Because of your past contributions to WINE, Lindows.com is offering to arrange and pay for airfare from a nearby major metropolitan area to San Diego for you to attend wineconf 2002. This offer is non-transferable. Your flight would depart on Thursday, March 14th and return on Sunday, March 17th. To qualify, by February 13th, 2002, you must: 1. Register online at http://lindows.com/wineconf (enter your name for the "Invitation Code"). 2. Send an email to cheryl(a)lindows.com with the below cancellation payment information. You will need to agree that if you do not attend that you will pay for all costs incurred by Lindows.com related to airfare arrangements. Your credit card will ONLY be billed if you do not attend after saying that you will. Hope to see you in San Diego! ------------------------------------------------------------------------ NOTE: In addition to registering at http://lindows.com/wineconf, we must receive the below information no later than February 13th, 2002 (e-mail this to cheryl(a)lindows.com). After that date, this offer is no longer valid. I agree to attend wineconf 2002 March 14-15th in San Diego and understand that Lindows.com will be paying for my airfare. If I do not attend, I understand that I will have to pay for the costs incurred in the scheduling of this airfare. <"yes I agree." and your name here> Exact name on passport or ID: <put your name here> Nearest Major Airport: <put your city and country here> Credit Card Type: <card type> Credit Card Number: <card number> Credit Card Expiration Date: <exp date> Please remember to travel with picture ID, passport and VISA if required. Further information can be found here http://www.lindows.com/wineconf

7 7

RE: Header files not present on Windows
by Rolf Kalbermatter 07 Feb '02

07 Feb '02

Patrik Stridvall <ps(a)leissner.se> writes: >> Patrik Stridvall <ps(a)leissner.se> writes: >> >> > Hmm. I'm note sure I like making unistd.h >> > an optional header but then few part of >> > Wine should include it anyway so perhaps >> > it doesn't matter. >> >> The question is whether you can build without it. If the needed >> definitions are provided by other includes then it's fine to make it >> optional; but if the code doesn't compile without it then there's no >> point in having a check. > >Yes and in many cases it did work without unistd.h, but maybe that >is because it really wasn't needed at all. > >In some case it might have worked because some of the functions in >unistd.h is defined else where in Windows and in some case we might >get it to work by including needed files. > >Of course in such cases we probably should fix Wine and >include that other header exclusively instead of unistd.h. > >Anyway, I just experimented a little trying to get Wine to compile >under Windows. I'm not really sure exacly what to do. > >Eventually I guess that the non-core DLL:s never should call any >non Windows functions at all and the core DLL:s are not really useful >to compile and run under Windows anyway. Well I have only played with the shell32.dll and in any file in there except "shelllink.c" removing "unistd.h" entirely had no negative effect whatsoever. This means to me that it is not needed at all. The use of fork(), execvp(), and waitpid() in "shelllink.c" however seems to require the "unistd.h" header. I'm not sure if shell32 should be considered a core DLL. It seems to me rather not. The desired operation could be possibly achieved with the use of Windows kernel functions as well. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citeng.com Netherlands mailto:rolf.kalbermatter@citeng.com

1 0

Date format
by info2000＠telecable.es 07 Feb '02

07 Feb '02

Hello, IŽm running a windows aplication made on Builder C, and when I execute de program with Wine, I receive an error message, reference to the date format, I get the year correctly, but the rest of date content is ="0", for example 01 January 2002 at 13:20:15 is= 17/20/02 00:00:00 can you help me to fixing this problem? thanks from spain. Jose. --------------------------------------------- Este mensaje fue enviado utilizando el servicio de correo-web de: http://www.telecable.es

2 1

RE: Some more MSVC fixes
by Roger Fujii 07 Feb '02

07 Feb '02

From: Patrik Stridvall <ps(a)leissner.se> wrote: > > Dimitrie O. Paun wrote: > > > On Wed, 6 Feb 2002, Steven Edwards wrote: > > > > > > Any other interesting compilers? Maybe the Solaris one? What about > > > headers? We already have 4 * 4 * 3 = 48 combinations. > > I tried briefly with the Solaris compiler, but there seemed > > to be enough problems that I gave up. I really don't remember what they > > were. > Well, the older versions for one doesn't support __stdcall. > I'm don't know about the newer. well, the current version doesn't seem to run under solx86 even with the gcc. Not certain what changed. Trying to figure it out right now (if only cvs.winehq.org would let me in...) > > It is probably a moot point now, since Sun has announced that there > > will be no Solaris 9 X86. > AFAIK they have only said that Solaris 9 SPARC will be released > before Solaris 9 X86. Of course it is not a good sign if you > read between the lines but still. well, technically, they said that x86 development work has stopped, but they can change their minds. Effectively, they "laid off" solx86, but added "we may ask you back..." Not promising at all.... -r

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 07 Feb '02

07 Feb '02

> Dimitrie O. Paun wrote: > > On Wed, 6 Feb 2002, Steven Edwards wrote: > > > > Any other interesting compilers? Maybe the Solaris one? What about > > headers? We already have 4 * 4 * 3 = 48 combinations. > > I tried briefly with the Solaris compiler, but there seemed > to be enough > problems that I gave up. I really don't remember what they > were. Well, the older versions for one doesn't support __stdcall. I'm don't know about the newer. > It is > probably a moot point now, since Sun has announced that there > will be no > Solaris 9 X86. AFAIK they have only said that Solaris 9 SPARC will be released before Solaris 9 X86. Of course it is not a good sign if you read between the lines but still.

1 0

Re: X connection to :0.0 broken (explicit kill or server shutdown).
by Sylvain Petreolle 07 Feb '02

07 Feb '02

Bonjour, Je rencontre un problème persistant avec wineconsole. Dès qu'il est chargé le système ralentit et wine grandit en mémoire jusqu'à saturation de la mémoire swap.(256M ram physique + 208M swap) Le message "fixme:bitmap:CreateCompatibleBitmap got bad width 1939840 or height 2457900" me fait penser que wineconsole se configure mal. Y a t il un moyen de spécifier une taille de fenêtre ? En regardant le code source (registry.c) jai essayé de mettre la proprété WindowSize à une valeur très petite, mais le lancement en mode debugmsg +reg montre que les valeurs sont ignorées par le programme. Comme vous etes en partie l'auteur de ce programme, je pense trouver un peu de répondant... --- Sylvain Petreolle <spetreolle(a)yahoo.fr> a écrit : > Hi, > > Using wineconsole to try a command line program > like ftp.exe (runs fine whithout wineconsole), > it appears that wineconsole slowdowns the system > and use incredible amounts of memory. > > These are the messages that appear on the wine > command > line : > > fixme:bitmap:CreateCompatibleBitmap got bad width > 1939840 or height 2457900, please look for reason > fixme:console:SetConsoleCtrlHandler (0x1001dc5,1) - > no > error checking or testing yet > fixme:bitmap:CreateCompatibleBitmap got bad width > 1939840 or height 2457900, please look for reason > > then i got the shell prompt, look like the process > had > end up. > (the processes didn't end up of course). > i must kill the processes (the 2 windows desktops > displayed are complete empty and > do not close when asked to close) > > Running it with --debugmsg +relay, I saw that wine > took a long time when running x11drv.SelectObject. > and the last line in the debug text is > X connection to :0.0 broken (explicit kill or server > shutdown). > (this is before I do killall wineconsole wine). > > > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et > en français ! > Yahoo! Mail : http://fr.mail.yahoo.fr > ATTACHMENT part 2 application/x-bzip2 name=wineconsole_debug.log.bz2 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr

1 0

Re: Some more MSVC fixes
by Dimitrie O. Paun 07 Feb '02

07 Feb '02

On Tue, 5 Feb 2002, Patrik Stridvall wrote: > I have finally tried to compile Wine with MSVC. > Eventhough I had to do some hack on the whole > it compiled quite well. Great. On a slightly related note, is it possible that we compile Wine with the MS headers? What would it take to do that? If we could, we would have one more degree of freedom: Platform Compilers BinFmt Headers -------- --------- ------ ------- Linux gcc ELF Wine *BSD MSVC PE MS Solaris Borland ReactOS(?) Cygwin Esentially, most of the above possible cobinations should work (except, of course Windows-base compilers and ELF). If we get this level of portability, would be nice to set an automatic compile farm which tries all the possible combinations, and reports problems early, so they get fixed. -- Dimi.

3 3

Favor: I need examples of un or poorly documented APIs
by Jeremy White 06 Feb '02

06 Feb '02

I'm working with someone involved in the Microsoft trial, and they are looking for some information from the Wine team. Specifically, they need clear examples of Windows APIs that are not documented, or cases where the actual working of an API is substantially different from the documented behavior. I've asked around CodeWeavers, and we had a few examples, but we're in a bit of a time crunch (48 hours), and I was hoping to ask a broader audience to pitch in. In an effort to keep this off topic traffic down, please reply just to me; if you like, I can post a summary of the results. Thanks, Jeremy

2 1

flaky regression(?) - patch.py?id=1012510895681951425038278
by lawson_whitney＠juno.com 06 Feb '02

06 Feb '02

Good day! Something in this patch makes my app set This->bigBlockSize of its inbox to zero when it gets a big batch of mail. Of course, the app (and my laola-based mailbox reader) is then unable to read the file. AFAICT, that is the only byte that is damaged, and it can be fixed after, but it is annoying. The app never did this before the patch, and hasn't since I reverted it yesterday. I will work on refining my observations, and I expect I will find and fix the error eventually. I'm just writing this in case it may be some help to anyone. Lawson

3 9

RE: (FWD) Announcing wineconf 2002
by Patrik Stridvall 06 Feb '02

06 Feb '02

> I received this today... it seems Lindows seem to want to host a Wine > conference. I noticed that they misspelled Alexandre's name and email > address, though they claim to work with him. Well, I'm not suprised. I'm not 100% sure how his last name is spelled. I usually cut and paste or more often, only use his first name. :-) > Since this is > supposed to be > an open conference anyway, and it's not a secret (most of the > mail is just > a straight dump of the webpage they link to anyway), I > decided to forward > it to wine-devel (but without the HTML). Hmm. I noticed people on the special invitition list (that get air transportion payed) must register by 13th February, 2002. It is only a week until then, they could have given us some more time to consider it, I think. Anyway, I'm slightly intrested in coming. Providing of course that at least a few of the Wine people will come. I'm not particularly intrested in travelling at least 12 hours by air to only talk to the Lindows.com people. Anybody else interested? PS. Does anybody know if a VISA to the US is required for citizens of the European Union countries (like Sweden)?

6 6

Re: Some more MSVC fixes
by David Laight 06 Feb '02

06 Feb '02

Alexandre Julliard wrote: > > David Laight <david(a)l8s.co.uk> writes: > > > This is the standard behaviour for C includes. It is actually usually > > best to use <> not "" for all header files - unless you explicitely want > > the file included from the current directory. > > The problem is our makedep uses the "" to determine which headers to > include in the dependency list, so this would have to be changed. Sounds like your makedep is broken! It needs to recognise <> and "" and treat them differently! David

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Wed, 6 Feb 2002, Patrik Stridvall wrote: > > > Well. If you do as I did and just add just create > > a Visual Studio Project (.dsp) for each DLL using the > > MS headers is the default. I had to add "..\..\include" > > to the include path to get it to use the Wine header. > > Sorry Patrik if my questions are sometimes naive, but I don't have a > Windows partition, let alone MSVC. So, here goes the question: > > MSVC must have a command line version of the compiler. Yes, MS Visual Studio always calls the command line version to compile. It is called "cl.exe". > Wouldn't it be > easier to use our Makefile system under cygwin to compile > Wine with MSVC? Possible. However I don't know exactly cygwin works. I try to avoid Windows as much as possible. I know how MSVS project files work though so I tryed with them first. Personally I think that the ultimate solution would be to automatically generate the .dsp files from Makefile.in or otherwise. There is a huge advantage of using the Microsoft format since Visual Studio can read them and you can for example just point and click on the files of each DLL to open them inside Visual Studio. The .dsp format is not very difficult to generate. It is just some sort of glorified Makefile. > > As to how good it works with MS header: > > Well, the problem is that if you don't add the path the > > Wine header files like debugtools.h doesn't > > exists so it doesn't compile very well and if > > you do the Wine headers take priority. > > That's why all our private headers must reside in > include/wine. That needs > to be fixed, eventually. Hmm. Well, I gave the MS headers one more try and discovered a few not so nice things. If you have a Wine specific include like below in a file: #include "heap.h" and this file heap.h in turn has a #include "winbase.h" it will include the Wine version of the file instead of the MS version. This is probably because with "" files in the same directory has priority IIRC. This is solvable by doing #include <winbase.h> but this requires changes in almost all .h files but it is just a simple search and replace. Hmm. I wonder if doing this will cause any bad effect with GNU C or other compilers? > > Of course you could add the MS header for inclusion one > > more time after the Wine headers, but where they > > are under Windows are installation dependent and not > > very portable. :-( > > Yeah, but that could be determined by configure. True. > > Additionally windef.h must be included first. > > > > #include "winbase.h" > > #include "windef.h" > > > > doesn't work. You have to do > > Of course. I was thinking would be nice to have a > > #include "wine/prologue.h" > <whatever includes you have> > #include "wine/epilogue.h" > > > #include "windef.h" > > #include "winbase.h" > > > > This is a minor issue though. > > Which should be fixed, I think. Yes. It will investigate some more. > > I also so got some other strange error with PCONTEXT > > in winnt.h which in didn't understand. > > > > In short it was a terrible mess so I primarily tested > > it with the Wine headers. > > It would be sooo nice if we could compile with other headers > as well. Just > compiling would be great, running the resulting executable would be > fantastic! Yes. :-)

4 3

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> > Personally I think that the ultimate solution would be to > > automatically generate the .dsp files from Makefile.in or otherwise. > > May not be easy but you are pretty good with perl so if anyone can > pull it off it's you :-) I don't think it is that difficult even for somebody less comfortable with Perl. The problem is getting all the details right and that will take some time, but allmost all details are quite easy, I think. > Once you have all the .dsp files, make a big .dsw file in the > top-level directory that references all the other .dsp files. That way > you can double-click on the .dsw, and then pick which dll you want to > build, build them all at once, etc. I guess you already know > about them > (and they are really simple to generate). Yes, I have it that way right now. But I only have a .dsp for a of few DLLs since doing it manually is quite boring. It would be quite nice to have all non core DLL compiling and working and with winetest ported. Then you could just run winetest through the debugger and be able to set breakpoint and step through the code in Visual Studio in order to get all to tests to run properly. :-) > > Hmm. Well, I gave the MS headers one more try and discovered > > a few not so nice things. > > > > If you have a Wine specific include like below in a file: > > #include "heap.h" > > and this file heap.h in turn has a > > #include "winbase.h" > > it will include the Wine version of the file instead of the > > MS version. This is probably because with "" files in the > > same directory has priority IIRC. > > No, that's because we use '-I .', which is a questionable practice. > Unfortunately I believe there is something that makes it hard to avoid > in Wine's case. I cannot remember what though. No, I don't think so. First of all -I. means current directory that is the directory of the current .c file. I was refering to that the #include "winbase.h" in file heap.h in wine/include perfered the winbase.h in wine/include rather than the MS variant. This is propably because #include "" with MSC always chooses the include from the same dir first rather the Microsoft dir that was EARLIER in the -I path (or rather the MSC equivalent). In the .c file #include "winbase.h" correctly included the MS variant. I haven't tested if GNU C have the same behavior but it might. > > > > Of course you could add the MS header for inclusion one > > > > more time after the Wine headers, but where they > > > > are under Windows are installation dependent and not > > > > very portable. :-( > > > > > > Yeah, but that could be determined by configure. > > > > True. > > But you would have to run configure on Windows, no? Since configure > is a shell script this means you need something like cygwin to compile > the source :-/ Or did you mean to run configure on Unix to > generate just > the right Makefiles for use on Windows? I didn't nessisarily mean configure but rather a Perl script that generates the .dsp files. Just install Perl and double click on configure.pl and all the .dsp was generated. Then double click on wine.dsw and you are ready to go.

1 0

compiling .obj with wine
by Ricardo 06 Feb '02

06 Feb '02

hi, Is it possible to compile/linkedit .obj, not the source, with wine libs? thanks Ricardo.

2 1

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Wed, 6 Feb 2002, Patrik Stridvall wrote: > [...] > > I also so got some other strange error with PCONTEXT > > in winnt.h which in didn't understand. > > You must define _X86_ before including 'winnt.h'. > Otherwise it won't > known on which architecture it's being compile and it won't define > CONTEXT. Yes, I realized that slighty after sending the mail. _M_IX86 is defined by the complier but _X86_ is defined by windows.h iif _M_IX86 is defined. > And you must also include 'windef.h'. Otherwise CONST is > not getting > defined and again, errors ensue. > > #define _X86_ > #include <windef.h> > #include <winnt.h> > > > Defining _X86_ is done in 'windows.h' which means that it is > virtually impossible to use these headers without including the big > beast itself. Yes. I have noticed that. However it is not that bad. #include "windef.h" #include "winnt.h" #include "stdarg.h" #include "winbase.h" Seems to do the trick. Another thing. It seems that all files will need to include "config.h" anyway because of issues like MSC doesn't support inline only __inline so a #define inline __inline is needed for anything reasonable to work anyway. Adding #include "config.h" at the top of each .c files is not that bad and things like #define _X86_ from windows.h could be there as well.

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Tue, 5 Feb 2002, Patrik Stridvall wrote: > > > I have finally tried to compile Wine with MSVC. > > Eventhough I had to do some hack on the whole > > it compiled quite well. > > Great. On a slightly related note, is it possible that we compile Wine > with the MS headers? What would it take to do that? Well. If you do as I did and just add just create a Visual Studio Project (.dsp) for each DLL using the MS headers is the default. I had to add "..\..\include" to the include path to get it to use the Wine header. As to how good it works with MS header: Well, the problem is that if you don't add the path the Wine header files like debugtools.h doesn't exists so it doesn't compile very well and if you do the Wine headers take priority. Of course you could add the MS header for inclusion one more time after the Wine headers, but where they are under Windows are installation dependent and not very portable. :-( Additionally windef.h must be included first. #include "winbase.h" #include "windef.h" doesn't work. You have to do #include "windef.h" #include "winbase.h" This is a minor issue though. I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand. In short it was a terrible mess so I primarily tested it with the Wine headers. I have only tested a few DLL since doing .dsp files for each them was some work. I might do a script to automatically generate .dsp files for MSVC some day. > If we > could, we would > have one more degree of freedom: > > Platform Compilers BinFmt Headers > -------- --------- ------ ------- > Linux gcc ELF Wine > *BSD MSVC PE MS > Solaris Borland ReactOS(?) > Cygwin > > Esentially, most of the above possible cobinations should > work (except, of > course Windows-base compilers and ELF). Well. I think GNU C chokes on the MS headers so that won't work either. > If we get this level of portability, would be nice to set an automatic > compile farm which tries all the possible combinations, and reports > problems early, so they get fixed. Yes, that would probably be a good idea.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel