Re: Problem with Winedbg

2000-12-30 Thread Francois Gouget
On Sat, 30 Dec 2000, Eric Pouech wrote: [...] the format H:debugger/winedbg is an awful mix of DOS and unix paths I don't agree. Ok, it would be better to have an absolute path like "H:/debugger/winedbg". But Win32 supports both '/' and '\' as directory separators so the path above is a

Re: Re: Problem with Winedbg

2000-12-30 Thread Mike McCormack
Hi All, i'm having the same problem too. wine seems to think that the first parameter to the debugger is the name of an executable... I understand, but Wine does not seem to attempt to load the winedbg.so. This is what i see when i put a DebugBreak() in kernel32_99() bash-2.03$ wine

Re: Problem with Winedbg

2000-12-30 Thread Eric Pouech
Francois Gouget wrote: On Sat, 30 Dec 2000, Eric Pouech wrote: [...] the format H:debugger/winedbg is an awful mix of DOS and unix paths I don't agree. Ok, it would be better to have an absolute path like "H:/debugger/winedbg". But Win32 supports both '/' and '\' as directory

Re: [LONG :-)] Some ramblings about the Wine Application Database

2000-12-30 Thread Lionel Ulmer
I strongly agree with what both of you have suggested; I particularly think Francois is correct to suggest that we resolve some of the hierarchy/name space issues with keywords. I have one problem with keywords is that I do not trust anyone to enter 'correct' informations :-) IMHO, the more

Re: Problem with Winedbg

2000-12-30 Thread Guy L. Albertelli
-Original Message- From: Eric Pouech [EMAIL PROTECTED] To: Francois Gouget [EMAIL PROTECTED] Cc: Guy L. Albertelli [EMAIL PROTECTED]; Wine Devel [EMAIL PROTECTED] Date: Saturday, December 30, 2000 8:49 AM Subject: Re: Problem with Winedbg I thought it could make a difference, but it

Re: Problem with Winedbg

2000-12-30 Thread Eric Pouech
Thanks Eric, changing the registry entry to a absolute Unix format worked. The patch, however, did not work. There was no apparent difference with the old registry (with either '/' or '\') and the patch being either on or off. the patch didn't work with H:debugger/winedbg or with

Re: Delayed import thunks for Sparc

2000-12-30 Thread Eric Pouech
Ulrich Weigand wrote: Hello, this patch implements delayed import thunks for Sparc. I've also modified the i386 implementation a bit to make it more easily portable; specifically, I've moved all references to the delay_imports symbol into the C routine to avoid having to implement PIC

Proposed new oic_wineicon

2000-12-30 Thread Christopher Morgan
Using the Wine glass image from WineHQ I created a 32x32 xpm to replace the current wine(martini?) glass in the About Wine dialog(/include/bitmaps/oic_wineicon). I thought I would post the xpm here and see if the new icon was acceptable and if anyone wanted to take a shot at improving it

Re: Delayed import thunks for Sparc

2000-12-30 Thread Ulrich Weigand
Eric Pouech wrote: Ulrich Weigand wrote: I've also modified the i386 implementation a bit to make it more easily portable; specifically, I've moved all references to the delay_imports symbol into the C routine to avoid having to implement PIC references in assembly ... (on i386 it just

Re: Delayed import thunks for Sparc

2000-12-30 Thread Eric Pouech
I don't think we need to follow the original implementation instruction-for-instruction. Even the Pietrek article itself says that delay load implementation can be modified ... agreed, at least for the internals... the prototype of the user defined hook must be the same (but implementing it

Re: MSVCRT

2000-12-30 Thread David Elliott
First off, sorry for the late response, I just got back from vacation and was planning to do some Wine work during but I wound up having enough computer stuff to do fixing my parents computers. Jon wrote: Sorry for the long post, theres a few issues raised here... On Monday 18 December 2000

PRESS: /. transgaming

2000-12-30 Thread Marcus Meissner
Hi, The Transgaming Announcement has hit /., with usual discussions ;) "WINE gets Direct3D Support" http://slashdot.org/article.pl?sid=00/12/30/1427237 Ciao, Marcus

Re: MSVCRT

2000-12-30 Thread Jon Griffiths
Hi, Definitely, I am not sure how to go about this now though. Should we just say the hell with it and forward to CRTDLL since our CRTDLL is working better or should we just move code out of CRTDLL and into MSVCRT a function at a time (or several at a time)? I would prefer sticking with

Re: MSVCRT

2000-12-30 Thread Andreas Mohr
On Sun, Dec 31, 2000 at 01:26:46AM +, Jon Griffiths wrote: Basically I want to ensure that if we are going to cause disruptions for people (which we will, undoubtably people arent going to read the release notes and will run the builtin), then its for a worthwhile reason (i.e. an Hmm,

Re: MSVCRT

2000-12-30 Thread Jon Griffiths
On Sunday 31 December 2000 2:15 am, Andreas Mohr wrote: You could always make Wine use the *native* version of the file as default loadorder. What's the problem ? Well, of course if people start forcing the loadorder to builtin, then we're outta luck... Thats what I did (wanting to run a

Re: Proposed new oic_wineicon

2000-12-30 Thread Ove Kaaven
On Sat, 30 Dec 2000, Christopher Morgan wrote: Using the Wine glass image from WineHQ I created a 32x32 xpm to replace Hmm... are you sure the WineHQ image *is* a wine glass? Discussions on e.g. web-admin (maybe on wine-devel too) suggests that it isn't, but actually a martini glass or

Re: Proposed new oic_wineicon

2000-12-30 Thread Christopher Morgan
Heh. I think its a bit more of a wine glass than the current one ;-) I did a search on google and came up with these pages (http://www.webtender.com/db/glass/11) for a white wine glass and (http://www.webtender.com/db/glass/10) for a red wine glass. I guess it does look like a champagne

Re: PRESS: /. transgaming

2000-12-30 Thread FT Rathore
Hi Well slashdot is always a week late. I was wondering when I saw the announcement on this list about a week ago but saw no comments from anyone here. BTW has anyone tried the diff from them. I would be happy if it even makes DotectX better (whoch they are releasing as Wine license right away).