wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

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

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

06 Feb '02

> For those coming internationally, just hope that Microsoft > isn't waiting > at the airport with a bunch of DCMA lawyers to arrest you :) > > Mind you, M$ wouldn't do that because they don't like to > admit that Linux, > Wine, or anything else actually exists. I don't think Wine does anything DMCA related right now. However it will be much fun when we will get to the DRM parts of Windows. Dialog from the future: "Oh, no, this is not a circumvention device, we are just trying to implement copy protection to protect the intrests of RIAA and MPAA." "But what about the function FooIsAuthorized?" "What about it? It is just a stub that nobody for some reason have gotten around to implement. :-)" BOOL WINAPI FooIsAuthorized(...) { FIXME("(...): stub\n"); return TRUE; /* Information wants to be free */ }

1 0

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

05 Feb '02

> 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.

1 0

Re: Header files not present on Windows
by Alexandre Julliard 05 Feb '02

05 Feb '02

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. -- Alexandre Julliard julliard(a)winehq.com

1 0

TSXxxx functions: die!
by Dimitrie O. Paun 05 Feb '02

05 Feb '02

Once again, Since this list is (again!) so quiet, I feel obligated to stir the spirits a little. So here it goes: we should get rid of the TSXxxx functions. Why? -- we don't keep to standard API, which is against the Wine's spirit -- they introduce yet another (useless) layer -- we reaquire the lock like crazy for no good reason -- most modern X systems are already thread safe -- we integrate Wine's locking with glic's, so we should be OK -- they are ugly How? s/TSX/X/g rm -rf tsx + misc Makefile cleanups But I hear people screaming: how about portability? What about platforms where we don't integrate with libc's locking, or when we don't have a thread safe X? Well, we can create a wrapper driver which simply aquires the lock, calls into the regular driver, then releases the lock. In fact, I am not convinced we shouldn't deal this way with the current driver, to simplify the code. It's not like we're missing a lot on performance... -- Dimi.

1 0

WineHQ cvs
by Francois Gouget 05 Feb '02

05 Feb '02

I was looking at the WineHQ CVS last week-end (trying to add a section about how to contribute to Wine and to beef up the about section) and, at least to an untrained eye, it looks like it contains many obsolete files that should be deleted. Here are some examples: * a number of files exist in both .html and .shtml form. Isn't the html form obsolete? about.html & about.shtml contrib.html & contrib.shtml search.html & search.shtml who.html & who.shtml * some files have multiple versions lying around refs.html & refs.shtml & refs2.html index.shtml & indexold.html * there is a number of file that I'm not sure are still in use threads_etc, referenced from design.html which is referenced, but commented out, from indexold.html & test003.html win_utils_test, does not appear to be referenced anywhere shots.html, referenced only from indexold.html Is there a good reason to keep the above files? Did I miss something? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 1

Re: Make a progress bar control behave more like a windows equivalent
by Dimitrie O. Paun 05 Feb '02

05 Feb '02

On Tue, 5 Feb 2002, Dmitry Timoshkov wrote: > Hello. > > According to my test application, progress bar control always does > InvalidateRect() if it wants to repaint itself. It is smart enough > whether or not invalidate background. Probably other comctl32 controls > need to be fixed in respect of this. That's a good point. When I wrote the Progress Bar & Up Down Controls way back when, I did the repaint thingy as other controls were doing. So I think this style simply got propagated through the controls without good reason, other than "others do it too". -- Dimi.

1 0

Re: *MEGA* bug
by lawson_whitney＠juno.com 05 Feb '02

05 Feb '02

On Tue, 28 Nov 2000, it was written: > > > On Mon, 27 Nov 2000, Andreas Mohr wrote: > > > Hi all, > > > > does no Windows program at all ever check return values !?!?!? OOPS, sorry. This and the other anachronisms are what come of using pieces of my mail system to do stress tests. Lawson Probable user head space error. - Dennis A. Moore

1 0

How long for CVS?
by Gerhard Gruber 04 Feb '02

04 Feb '02

A few days ago I sent a patch for WritePrivateProfileSection that fixed the wrong behaviour that this function should create multiple keys with the same name which will be needed for wininit.ini. Now I have seen two updates of the CVS tree but this path hasn't been applied. Does this mean I should resend it to the pathces list, or should I wait a bit longer? How long does it usually take for a patch to get submitted?

1 0

Re: Listview Unicodification (part 2)
by Alexandre Julliard 04 Feb '02

04 Feb '02

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Alexandre, let me know if you like the patch better in this format. Yes, it's much better that way, thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: API test suite
by Andriy Palamarchuk 04 Feb '02

04 Feb '02

Hi Chris, thank you for suggesting the help. Preferred method of contacting Wine developers is posting to mailing list wine-devel. In this way everybody can participate in the discussion and the conversation will be documented for later reference. See www.winehq.com how to join the list. I forward my response to the mailing list. Chris Caston wrote: > I have volunteered myself to help test Windows functions for > compatibility with WINE. I'm am not one of the WIndows programmers but I > intend to take responsibility for many of the functions to be checked > and to keep track of functions (perhaps even developers) and their > status in a database. As well a setup assocation to e-mail results to > other important people. You are welcome! You can learn Windows programming while creating the tests. Knowing answers for these questions I can better help you: What is your programming experience? Do you have any Windows develoment tools? What operation systems do you currently use (Windows, Linux)? > Could be so kind to shed some light on the API test suite. Firstly, how > well documented are these functions? > > I'm getting conflicting information in this issue. Some people say that > the Win32 API is obscured and kept closed while others say that it is > one of the most throughly documented API's in use today with many books > about programming in this environment and information on the MSDN site. On one hand there are a lot of documentation about Win32 API, on other hand the documentation is often misleading, there is a set of API which is not documented at all and some programs, especially Microsoft products (IE, Office), tend to use it. Don't warry about this. We don't have any tests. Start with writing tests for well-documented API, document the cases when Win32 API behaviour differs from the documentation. > I have found a page that lists 350+ functions: > > http://www.vbapi.com/ref/funca.html Before somebody mentioned that Windows has more than 12,000 API functions :-) MSDN (msdn.microsoft.com) is the best source of information about Windows API. You also can find a lot of information on the Net. Some references are listed on www.winehq.com. > Secondly, what mechanisms are being used for the test suite? We are going to use tests, written in C and Perl. > Have these yet been agreed on? Kind of - we already finished *very* active discussion on the topic :-) Perl and C frameworks and tests conventions are under development. If you are interested, see thread "Re: We *really* need a development model change !" and a few other threads for details. > Do you have some test functions already written that I can see? Yes, the Perl framework with sample test is already in Wine code repository in programs/winetest directory. You can browse Wine source online at: http://cvs.winehq.com/cvsweb/ I have C testing framework, but it is not in CVS yet. Alexandre, what is the status of C testing framework? Do you want me to submit the latest version I have (without using the _T macro) for including in CVS? The process of tests development, especially on Windows, is not created yet. > How can I learn the processes involved? The development process is described on www.winehq.com. Please, read the documentation presented there. Good luck. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com

1 0

RE: Another Potential Slave... I mean Programmer
by Joe Tennies 04 Feb '02

04 Feb '02

Okay. I'll admit I am biased toward GNOME, but my real problem is that I didn't explain myself much, and I doubt people actually went to look at the gstreamer site. I had found it before, but forgot about. Why I think KDE should adopt gstreamer as well. It is not a replacement for ALSA, OSS, ESD, or aRts... it's an add-on to it. My understanding of the gstreamer project is that it's Linux/UNIX's response to the Windows CODEC system. It is a single interface to output video and audio from various types of input file types. They have support for MP3s, DIVX (coming), Ogg Vorbis, DVD, AVI, MPEG, Video 4 Linux, etc. for input files. It also supports OSS, ALSA, esd, aRts, X11, aalib (gotta love it), SDL, etc. for outputs. This is obviously not for programs that need low latency. It is for your everyday stuff. It is more than good enough for saying "you got mail," yet it would have support for lots of files types w/o specifically writing support for the new file type. This is also good for multimedia players and web browsers due to the support for lots of file types (I could see XMMS switching to this from its plugin system). Is this the answer for recording studio programs, remakes of Rebirth (WE NEED ONE OF THESE), or people that need the audio fast, but for the typical desktop user, it will be a god send. Only downfall I could see to the KDE crowd is the need to install GLIB. It doesn't require the full GTK+, just GLIB (linked lists and other datastructures). KDE could recommend using aRts for output and write its own input plugins for implementations that depended on a library KDE didn't need installed but KDE did install another one that implemented something simiilar. HECK, I don't think anyone would mind KDE writing their own underlying/core part, required you use aRts for output, didn't require GLIB (though this may be difficult), but used those input plug-ins. I understand KDE and GNOME have very different things in their head, but we need to get some standards here. XDND was way overdue (though I hear it wasn't a great implementation, at least they agreed on how to do something), and the two groups need to make more decisions like these to help each other strive. Remember everyone. I WAS a HUGE KDE fan myself for years. I had installed GNOME a couple times and hated it. I used KDE through 2.1 (I think... definitely in the 2.X). Then I discovered I had Blackbox on my machine, and it flew. I like the QT library (though I won't use it because I am now a GNOME guy). I like the layout of KDE... simple yet sophisticated. It tailors to the geek and the 'typical home user.' I just like GNOME's CORBA interface they are adding (which is where gstreamer will fit in). Something that can be so easily updated and contain potential problems is powerful (though VERY frustrating at times). I also love Ximian, who I feel keeps pushing the things that need to get done to make Linux a full fledged desktop system -- not to mention their love of all things monkey =) I salute KDE. They did the large scale desktop environment for the masses first (CDE is NOT for the masses anymore). They are probably still doing it best (I hear lots of complaints about some of GNOME's design). The problem I see is that there's no one really pushing KDE to keep its lead (and the slow speed it had under Mandrake). -----Original Message----- From: Christopher Morgan [mailto:chmorgan@speakeasy.net] Sent: Saturday, February 02, 2002 11:46 PM To: Joe Tennies Subject: Re: Another Potential Slave... I mean Programmer It would be interesting to see a latency comparison between gstreamer, arts and jack. If gstreamer doesn't get very close to what jack can do then it isn't the solution for the future. We need low latency or tons of audio apps will continue to find it through direct alsa or jack interfaces. Ideally we should pick the best solution and much of it is based on the latency issue, features should come after and should be designed such that they don't increase latency by any more than they have to. It sounds a little like you want to go with a gnome solution because you use gnome. I think more work needs to be done to come up with a linux(open source or whatever as well) wide solution to the problem. Chris On 2 Feb 2002, Joe Tennies wrote: > On Sat, 2002-02-02 at 05:42, Hetz Ben Hamo wrote: > > > I'm not trying to start a Gnome/KDE flame war, but as far as I know, esd is > > > unmaintained and the Gnome developpers are thinking about switching to > > > aRtsd. Wouldn't it be more useful to write an aRts driver ? > > > > Actually if I'm not mistaken - GNOME people are moving to gstreamer, if I'm > > not mistaken. I'm not sure since I work with KDE here... > > > > Hetz > > > Actually, I just looked at gstreamer. It lies above aRts, esd, alsa, and oss. It is a platform independent (well, not ported to everything yet, but working on it) system. I think KDE SHOULD be heading this way and am impressed that GNOME is. I think that gstreamer would be the way to go for WINE. > > > >

1 0

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

04 Feb '02

--- 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: Another Potential Slave... I mean Programmer
by Derek J Witt 03 Feb '02

03 Feb '02

Hehe. I meant to say that sound quality from esound is not as clear as artsd. The best way to notice that is trying to play stereo sound. E.g. Real Player is very noticable (even in monoaural). Sorry for the confusion, Lee. -- Derek. >On Sat, 2002-02-02 at 10:01, Derek Witt wrote: >> Yeah, aRtsD can run stand alone without KDE. I do believe artsd is >> superior to esd in that the output doesn't sound like a scratchy shortwave >> radio. On my machine, aRtsD does have slightly more overhead (according >> to top), but it's hardly noticeable on my box. > >scratchy shortwave radio???...based on what listening device? just >curious here.. > >:) >lee >-==== > > > -- Derek http://www.getonline.cc

1 0

Re: Resend: CW: Progress control creation fixes
by Andreas Mohr 03 Feb '02

03 Feb '02

On Sun, Feb 03, 2002 at 06:48:00PM +0800, Dmitry Timoshkov wrote: > Hello. > > This is a part of the big CodeWeavers' patch, adapted for current CVS. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Moved style correcting code to the WM_CREATE handler and added > clearing of WS_EX_CLIENTEDGE and WS_EX_WINDOWEDGE as in Windows. > Added SetWindowPos(SWP_FRAMECHANGED) to make changes take effect. "Moved" ? I can only see an addition here... You might want to check your patch. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 2

Re: Support for generation of .def files from .spec files
by Steven Edwards 03 Feb '02

03 Feb '02

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Hello. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Support for generation of .def files from .spec > files. This is great. I wont have a chance to try it out untill monday. Hopefully it will make it in to the tree. Thanks Steven __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com

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