wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

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

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