Re: Re: dbghelp
> UnDecorateName is still a stub, while our winedump has some a good> framework for UnDecorateName, also translating into a GCC way and not in a> VC++ way. How should these things go together? See the comment in dbghelp.c !! My first thouhgt would be to make a .a lib out of winedump code, and use it in winedump and msvcrt and / or dbghelp. I haven't studied yet the best way to share the code between msvcrt and dbghelp A+
RE: Handling dialogs created without using templates
Hi, Thanks. Would you be able to share details of the changes you did for handling MDI windows? Regards Santosh > -Original Message- > From: Dmitry Timoshkov [SMTP:[EMAIL PROTECTED] > Sent: Tuesday, March 30, 2004 7:40 PM > To: Santosh Siddheshwar > Cc: [EMAIL PROTECTED] > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote: > > > Yes attached is a sample which is pretty similar to what I described > > below. > > Thanks. Now I see where the problem is. We have to hook dialog creation > code into common window creation code, something similar to what I've done > recently for MDI. Alexandre, are my thoughts correct? > > -- > Dmitry. * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *
Re: Should winemaker be able to handle this
On April 3, 2004 6:43 pm, Francois Gouget wrote: > I agree on the A/B distinction. However even in the B case we need these > options for those cases where winemaker generates a whole lot of > makefiles. Right. We need to support that case, but it seems that we need a way to include stuff in the generated Makefiles. So, instead of adding all these options, maybe we can find a way to simply allow the user to include stuff in the generated Makefile. Something simple, like: winemaker -A 'DEFS=-DSTRICT ...' where -A will simply add the argument as a line at the beginning of the generated Makefile. This is easier to implement, document, etc., and it's general enough that we don't have to keep adding options to support all sorts of users. -- Dimi.
Re: WININET: move to Windows sockets
On April 4, 2004 10:18 pm, Jonathan Wilson wrote: > Use #ifdef stuff so that when building on WINE, it uses unix sockets. We have to be smart about this, having #ifdefs all over the file is not acceptable. But from the look of the patch that was just posted, it certainly looks like we can achieve this without too much pain. But yes, I'm also curious how much of a hit we're taking. -- Dimi.
Re: WININET: move to Windows sockets
How about this. Use #ifdef stuff so that when building on WINE, it uses unix sockets. But when building on win32 (which would include MingW and ReactOS), it uses winsock.
Re: WININET: move to Windows sockets
Hello Hans, --- Hans Leidekker <[EMAIL PROTECTED]> wrote: > > This makes wininet build on MinGW. > > Changelog: > Move to Windows sockets. > I asked Alexandre about a patch to move Wininet to Winsock and he said it took to much of a performance hit to merge. Is there a way we can bench mark it to show how much of a hit Winsock vs Unix sockets is going to give us? He suggested that we find a way to make Wininet use Unix sockets on Unix and Winsock on Windows. Thanks Steven __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/
Re: DDraw issues, etc.
On Mon, 5 Apr 2004 02:20:51 +0200 (CEST) Francois Gouget <[EMAIL PROTECTED]> wrote: > It looks like an i810 to me (but I have never actually seen one so...) > > Do you know if it is integrated on the motherboard? And then is it an > Intel chipset? > > Also, cat /proc/asound/cards will tell you what type of sound card you > have. 0 [I82801BAICH2 ]: ICH - Intel 82801BA-ICH2 Intel 82801BA-ICH2 at 0x1200, irq 10 apparently it's an ICH2 and not an i810, and yes it is integrated on the motherboard. (My computer is a laptop :P) The odd thing about it is that the sound works fine in WineX (after a little hacking to get it to even run the app :/). Tim
Re: DDraw issues, etc.
On Sun, 4 Apr 2004, Tim Hentenaar wrote: [...] > 00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 05) [...] > Hmm.. I don't believe that my card is an i810, it could be, but I have > the alsa drivers statically linked into my kernel and I forgot exactly > which one it is. It looks like an i810 to me (but I have never actually seen one so...) Do you know if it is integrated on the motherboard? And then is it an Intel chipset? Also, cat /proc/asound/cards will tell you what type of sound card you have. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: DDraw issues, etc.
On Sun, 4 Apr 2004 16:17:29 +0200 (CEST) Francois Gouget <[EMAIL PROTECTED]> wrote: > Do you have an i810 sound card by any chance? 00:1f.5 Multimedia audio controller: Intel Corp. 82801BA/BAM AC'97 Audio (rev 05) > I'm asking this because there are known problems with sound on i810 > soundcards, especially if you are using the Alsa drivers. I'm using the 2.6.0 kernel with the alsa kernel modules, and OSS emulation. > > It seems to be caused by a kernel bug which is triggered by the > full-duplex mode: > > http://crossover.codeweavers.com/pipermail/discuss/2003-December/005653.html > Hmm.. I don't believe that my card is an i810, it could be, but I have the alsa drivers statically linked into my kernel and I forgot exactly which one it is. Tim
Re: appdb - improvement in serching out bugs
Quoting hatky <[EMAIL PROTECTED]>: > > On Sunday 04 April 2004 06:21, [EMAIL PROTECTED] wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#"; > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts
Re: appdb - improvement in serching out bugs
Quoting hatky <[EMAIL PROTECTED]>: > > On Sunday 04 April 2004 06:21, [EMAIL PROTECTED] wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#"; > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts
Re: dbghelp
> "Eric" == Eric Pouech <[EMAIL PROTECTED]> writes: Eric> Eric Pouech a écrit : >> This is a first (and incomplete) shot at implementing the dbghelp >> DLL. Eric> forgot to say that: - this patch must be applied before the ones Eric> on imagehlp & taskmgr - code is highly derivated from winedbg Eric> current code Eric> I'm also working on a winedbg version based on this DLL, but it Eric> isn't ready yet (as dbghelp seems to get a bit more mature, I Eric> thought some people might be interested in testing it) UnDecorateName is still a stub, while our winedump has some a good framework for UnDecorateName, also translating into a GCC way and not in a VC++ way. How should these things go together? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Personal tree with interesting patches
On Sat, 2004-04-03 at 12:28, Dmitry Timoshkov wrote: > Mike, where is your DCOM related work? Well, all the patches that *I* wrote for DCOM have been merged into Wine by Alexandre a long time ago. If you are thinking of the merge I did of Oves TransGaming patches, then I'm afraid the only tree I have with that work is ancient and I have not had time to import it into arch yet (I may not bother). I never was able to split it up to Alexandres liking. Hopefully if I am to do it a second time, I will have sufficient skill and knowledge to turn it into a correct series of patches. thanks -mike
Re: appdb - improvement in serching out bugs
On Sunday 04 April 2004 06:21, [EMAIL PROTECTED] wrote: > The current code can get bugs that have nothing to do with the AppDB. This > should fix it. > > -- > > Tony Lambregts I think this is wrong, you are saying the url in bugzilla should be exactly "appdb #" where it should realy be "http://bugs.winehq,org/show_bug.cgi?id=#"; -- Hatky, Worshiper of wine (http://www.winehq.org/), Impossible is only an opinion.
installation program
Title: installation program On the To Do List (c.4) is an item for having a new graphical Wine install program. Anyone ever looked at Frank Hendrickson's WineTools program? http://franksworld.net/winetools.html It used to be written in some funky language, now it's all shell script. Anyway, if you look at the script (wt210) you'll notice he uses xdialog ( http://thgodef.nerim.net/xdialog/ ) for the GUI. So here's what I'm wondering.. How feasible would it be for Wine to create a new Winelib program (say, wdialog) and use a similar concept as Frank? wdialog would simply replicate the functionality of xdialog. We could potentially fail gracefully into shell mode if Wine can't start. It might be a cheap and simple way to get a GUI front-end. Of course, all this requires sane defaults so Wine can actually run wdialog. Any thoughts? --- Brian Vincent Copper Mountain Telecom [EMAIL PROTECTED]
Re: DDraw issues, etc.
On Sun, 4 Apr 2004, Tim Hentenaar wrote: [...] > I'm also looking at some of the wave driver stuff. WineX's wave driver > (at least the OSS driver) does the sound for the game perfectly > whereas Wine's wave output sounds rather odd, crackling, and it seems > not to flush the buffer properly. :P Do you have an i810 sound card by any chance? I'm asking this because there are known problems with sound on i810 soundcards, especially if you are using the Alsa drivers. It seems to be caused by a kernel bug which is triggered by the full-duplex mode: http://crossover.codeweavers.com/pipermail/discuss/2003-December/005653.html Do you use the Linux Alsa sound drivers in OSS emulation mode, or do you use the kernel OSS sound driver? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
Re: DDraw issues, etc.
> And that it does :/ It seems not to update the screen properly, but then > again, it could be something not completely implemented in Wine, or the game > engine. Well, if it asks for multiple clipping rectangles, and from what I found out in the MSDN, they should not overlap. So you should just have to loop over all the rectangles and do the 'copy_on_screen' as many times as there are rectangles. Of course, if they overlap, this method will still work except that we would 're-Blit' some parts multiple times (we would just need to do the optimisations later on). See these pages : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/regions_6702.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/regions_9kky.asp > According to M$ DX7 Documentation, DirectDrawSurface::Blt() should only > bit to areas that are in the clip list. And apparently 98% of the time that > it's trying to blit to a rect that it's not putting in the clip list, it's > almost identical to the RGNDATA.rcBound value, so i'm guessing it's for some > type of back-buffer used by the engine :P You mean that it's trying to blit to a zone that is not at all in the clip list (ie all of the intersections of the destination rectangles with the rectangles in the clip list are empty) ? It may well be that it's not a bug (why use clip lists if you still need to check in the engine code if you are completely in or not from the lists). > Yeah, that is unless the current DD code was rewritten to use GL and also > assuming that the person running it had Direct Rendering, but then again, > that would take a lot of time to do, and could possibly be horridly slow if > the person happened not to have direct rendering :P Well, it's in my plans to do the GL 'port'... It could even be done pretty easily (as almost all of the code already exists in the D3D part of the code). It would be mightily hacky, but well, it may even work :-) What's blocking me is that my 'target' applications is COMI and it uses 8 bit graphics (so I need a GFX card supported paletted textures to really see if I can get a nice speed-up). > I'm also looking at some of the wave driver stuff. WineX's wave driver (at > least the OSS driver) does the sound for the game perfectly whereas Wine's > wave output sounds rather odd, crackling, and it seems not to flush the > buffer properly. :P For that, Robert and Eric are the experts... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DDraw issues, etc.
On Sun, 4 Apr 2004 10:26:34 +0200 Lionel Ulmer <[EMAIL PROTECTED]> wrote: >Of course, if it uses more than one, some adaptations > would be needed :-/ And that it does :/ It seems not to update the screen properly, but then again, it could be something not completely implemented in Wine, or the game engine. > What do you mean by 'a destination rect that isn't present in the clip list' ? According to M$ DX7 Documentation, DirectDrawSurface::Blt() should only bit to areas that are in the clip list. And apparently 98% of the time that it's trying to blit to a rect that it's not putting in the clip list, it's almost identical to the RGNDATA.rcBound value, so i'm guessing it's for some type of back-buffer used by the engine :P > Oh well, it can be LOTS of stuff... In Windows, they have direct frame > buffer access so some games (like MI3) did a lot of updates of the screen > (which leads to a lots of traffic in Wine between game memory, X11 and the > frame buffer). It works perfectly well in Windows and will be slow as hell > in Wine. Yeah, that is unless the current DD code was rewritten to use GL and also assuming that the person running it had Direct Rendering, but then again, that would take a lot of time to do, and could possibly be horridly slow if the person happened not to have direct rendering :P I'm also looking at some of the wave driver stuff. WineX's wave driver (at least the OSS driver) does the sound for the game perfectly whereas Wine's wave output sounds rather odd, crackling, and it seems not to flush the buffer properly. :P Tim
Re: DDraw issues, etc.
On Sat, Apr 03, 2004 at 08:34:38PM -0500, Tim Hentenaar wrote: > I had a look, and implemented a clip list with one rect to use the same > code as with an hWnd since they are virtually the same. This app is wierd in > the fact that it dosen't use the hWnd for clipping with one rect, but rather > a clip list with one rect. That fixed the drawing somewhat. Well, it's not THAT strange... Ie if you want to use the features of the clipper in, for example, a full screen applications, you do not need to create a HWND which is the size of the rectangle, you can just add your own clip list. And, if the hardware supports clipping with Blits, you gain time as you do not have to do a lot of stuff in the game engine (all the rectangle intersection code). In OpenGL-land, this is called 'glScissor' :-) So, if your game uses only one rectangle, it should be pretty easy to map to the current code. Of course, if it uses more than one, some adaptations would be needed :-/ > For instance, I noticed that the app sets the clip list, then tries to blit > to a destination rect that isn't present in the clip list. I'm guessing that > it's meaning to clip the source rect, but why you would clip the source > surface is foreign to me. :P What do you mean by 'a destination rect that isn't present in the clip list' ? > I'll have to dig a little deeper yet to figure this out. The main thing > that irks me, is that even with clipping implemented, wherever it has to > draw any sort of constant animation it's horribly slow (most of the time). > Though when it plays a movie it plays perfectly. I'm guessing this would be > a flaw in the game engine. Oh well, it can be LOTS of stuff... In Windows, they have direct frame buffer access so some games (like MI3) did a lot of updates of the screen (which leads to a lots of traffic in Wine between game memory, X11 and the frame buffer). It works perfectly well in Windows and will be slow as hell in Wine. Lionel -- Lionel Ulmer - http://www.bbrox.org/
