June 2002 - Wine-Devel - list.winehq.org

Re: How big is the Direct3D stuff?

by Marco Pietrobono

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 6 Jun 2002, Johan Gill wrote: > I'm planning to do some work, but it's a matter of priorities, as always. I would like to start some work on directx/direct3d too, but first I need to complete the ALSA driver. Right now I'm studying the internals of the dsound.dll, to correct the interaction between the ALSA driver and the DSOUND_* functions used to mix the primary buffer. I hope to complete it soon, so I can start to study the other parts of the DirectX / Direct3D dlls. bye, /pietrobo - -- Stud. Marco Pietrobono | Murphy's Law: if something could v. del Calice, 39 - 00178 ROMA | go wrong, it does. Tel. +39.6.7186329 0339.7410893 | Legge di Murphy: se qualcosa può http://www.pietrobo.com | andar male, lo farà. - ------------------------------------------------------------------------ Strange game. The only winning move is not to play. What about a nice play of chess ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8/7NYJdpOg6vRQxoRAgnRAJ9Vr4CFzPdHa7B1enVjGzuyimTfzgCfSUN5 c2r41U+i1/AC3M7flIwwJss= =7kgl -----END PGP SIGNATURE-----

June 6, 2002

RE: How big is the Direct3D stuff?

by Patrik Stridvall

> At 08:10 PM 6/6/02 +0200, Patrik Stridvall wrote: > > > > >Secondly who are you to tell people what they can or can't do > > > >for a living? > > > > > > Huh? Did I say it was wrong what they did? Please provide > > > some evidence, > > > otherwise apologize... > > > >It was not meant as an accusation, merely a statement that > >it is not of your concern what other people do. > > Please don't try to distract. I'm not distracting. I wasn't refering to anything you said. I merely stated that whether you agree or not I don't consider to be of your concern. > Someone mentioned that > programmers got bought > out, then I asked what that meant exactly. I never said, that > I didn't > agree with programmers working for TG. In fact I think there > is nothing > wrong with that. So I didn't tell anyone they shouldn't do it. > Ok? So then we agree. Good.

June 6, 2002

Error messages when typing Hebrew characters

by Shachar Shemesh

Hi. I tried repeating Hetz's experiment, and run the command "LANG=he_IL wine notepad", and then type a few (random) Hebrew chars. I get the following messages on screen: Warning: Language 'he_IL' was not found, retrying without country name... fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented fixme:win:GetProcessDefaultLayout ( 0x40556df4 ): No BiDi err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEA (hebrew_finalkaph) : err:keyboard:X11DRV_ToUnicode (virtKey=4C,scanCode=26,keycode=2E,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CF9 (hebrew_shin) : err:keyboard:X11DRV_ToUnicode (virtKey=41,scanCode=1E,keycode=26,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEC (hebrew_lamed) : err:keyboard:X11DRV_ToUnicode (virtKey=4B,scanCode=25,keycode=2D,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CE3 (hebrew_dalet) : err:keyboard:X11DRV_ToUnicode (virtKey=53,scanCode=1F,keycode=27,state=2010) I tried following X11DRV_ToUnicode around a bit, but hit a brick wall at the X11 function "TSXKeysymToString". Anyone has any idea why the Hebrew characters are not being translated correctly (the character names are correct). Shachar

June 6, 2002

RE: How big is the Direct3D stuff?

by Roland

At 08:10 PM 6/6/02 +0200, Patrik Stridvall wrote: > > >Secondly who are you to tell people what they can or can't do > > >for a living? > > > > Huh? Did I say it was wrong what they did? Please provide > > some evidence, > > otherwise apologize... > >It was not meant as an accusation, merely a statement that >it is not of your concern what other people do. Please don't try to distract. Someone mentioned that programmers got bought out, then I asked what that meant exactly. I never said, that I didn't agree with programmers working for TG. In fact I think there is nothing wrong with that. So I didn't tell anyone they shouldn't do it. Ok? Roland

June 6, 2002

RE: How big is the Direct3D stuff?

by Francois Gouget

On Thu, 6 Jun 2002, Roland wrote: > At 07:04 PM 6/6/02 +0200, Patrik Stridvall wrote: [...] > >Secondly who are you to tell people what they can or can't do > >for a living? > > Huh? Did I say it was wrong what they did? Please provide some evidence, > otherwise apologize... Patrik, Roland, This is a fla^H^H^H debate for the wine-license mailing list. Let's try to keep wine-devel productive and focus on what's the plan for implementing Direct3D in Wine. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

June 6, 2002

RE: How big is the Direct3D stuff?

by Patrik Stridvall

> At 07:04 PM 6/6/02 +0200, Patrik Stridvall wrote: > > >First of all since it was in parts their code the could have > relicensed > >it to whatever they wished, so that wouldn't have been that large > >problem. > > No quite true. If the code is based on previous LGPL code, > they couldn't > relicense it, unless they also coded all of that previous > stuff. That's the > whole point of the LGPL. Obviously the author can relicense his code to whatever he wish. Now if if there are LGPL:ed parts that his code depends on he must remove them and if he wishes make his code usable in other contexts rewrite the LGPL:ed parts. Note that copyright only covers unique expression. Whether some his code was based on facts or ideas discover by authors of LGPL:ed licensed code doesn't count as far as copyright law is concerned. Also note that the LGPL has been fulfilled by since the other LGPL authors can keep his code so it will be quite hard to make additional claims especially since as I said copyright only protects unique expression. > >Secondly who are you to tell people what they can or can't do > >for a living? > > Huh? Did I say it was wrong what they did? Please provide > some evidence, > otherwise apologize... It was not meant as an accusation, merely a statement that it is not of your concern what other people do.

June 6, 2002

RE: How big is the Direct3D stuff?

by Roland

At 07:04 PM 6/6/02 +0200, Patrik Stridvall wrote: >First of all since it was in parts their code the could have relicensed >it to whatever they wished, so that wouldn't have been that large >problem. No quite true. If the code is based on previous LGPL code, they couldn't relicense it, unless they also coded all of that previous stuff. That's the whole point of the LGPL. >Secondly who are you to tell people what they can or can't do >for a living? Huh? Did I say it was wrong what they did? Please provide some evidence, otherwise apologize... Roland

June 6, 2002

opengl32 wglSwapLayerBuffers

by Jesse Allen

Hi, I've been on a kind of rampage trying to Warcraft 3 working the best it can under Wine. I have previously tried WineX, which works pretty much right out of their CVS. WineX has some of D3D8 done, thus War3 works easily. But however, it has some graphics bugs, and possible some what slower framerate than in Windows. Warcraft 3 has a secondary, opengl graphics driver in it. You can access it by running wine War3.exe -- -opengl for example. But when doing this on either Wine or WineX it would say wglSwapLayerBuffers... stub !, and there would be no graphics output. I investigated this and of course found that there was nothing there. I searched through gl headers and the wine sources for an opengl equivilant, and found a SwapBuffers(hdc HDC) through GDI/x11drv? I decided to call that from wglSwapLayerBuffers. In doing that, this still ignored a parameter of UINT fuplanes. I really don't know what fuplanes is for. So this is not at all a complete implimination of this function. An attached patch file shows my changes to wgl.c as from current release. I went ahead and tried War3 again with opengl. This time, it outputs graphics. In comparison with D3D8, there are no graphical errors, and it seems slightly faster. But DXGrab no longer works, but a quick solution is to switch to the same game resolution. The game looks like its working perfectly now!! No side affects have been seen with ignoring fuPlanes. I'm haven't worked on wine before, but I'm willing to work with whoever to figure out how to correctly implement this function or others related to this. Perhaps I can figure out what fuPlanes is? Jesse Allen cc me as I'm not subscribed to the mailing list. ___________________________________ NOCC, http://nocc.sourceforge.net

June 6, 2002

Re: Do we need Direct3D? How about OpenGL?

by Lionel Ulmer

On Thu, Jun 06, 2002 at 01:24:04PM -0300, Roland wrote: > I just thought about this. AFAIK most good 3D games support OpenGL anyway. Well, that is if you are a fan of Q3A-derived shooters.. Otherwise, most other games are D3D only. Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 6, 2002

Re: null midi device

by Eric Pouech

> I think it would be better to support ALSA midi and then people could use > Timidity as an Alsa 'plug-in' to do a software sequencer. note that this is also possible with OSS interface, and wine OSS driver already includes MIDI support so this should be more straight forward A+

June 6, 2002

Re: How big is the Direct3D stuff?

by Lionel Ulmer

On Thu, Jun 06, 2002 at 01:33:28PM -0300, Roland wrote: > What do you mean by 'bought out'? I suppose there where WINE contributors > who now work for TG, right? > If this is the case it is another point in favour of the LGPL... The LGPL would not have changed anything here, as they are free to change the license of the *new* code they write whenever they want. Anyway, the 'bought out' was to be meant as a joke and not to be taken pejoratively. If people prefer to be paid to do stuff they like, it's their choice. And we should stop here before needing to follow-up to wine-flame^H^H^H^Hlicense :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 6, 2002

Re: imports by ordinal

by Alexandre Julliard

juergen.schmied(a)debitel.net writes: > I'd like to use in a internal wine-dll(shell32) a function exported > by an other dll(shlwapi) by ordinal. How can I do this in a clean > way without use of GetProcAddress in a way it works with native > dll's too? You have to use GetProcAddress, there is no automatic import mechanism. That's a feature to discourage you from calling ordinal functions ;-) -- Alexandre Julliard julliard(a)winehq.com

June 6, 2002

Re: self-registerable standard DLLs

by Alexandre Julliard

"John K. Hohm" <jhohm(a)acm.org> writes: > I noticed that the attempt to test comcat.dll on Win98 failed because > DllRegisterServer is a stub returning E_NOTIMPL. I have added the > registry entries for the component categories manager to winedefault.reg, > which should suffice for normal Wine installations. Despite this, is it > generally acceptable to have actual code to register/unregister a standard > COM server DLL in its Dll[Un]RegisterServer? It would be redundant for > normal Wine, but hey, it's not big or complex. Actually putting that in DllRegisterServer is arguably the right way to do it. What we should have is some kind of installation step that would register the Wine dlls, instead of having to put everything in winedefault.reg. -- Alexandre Julliard julliard(a)winehq.com

June 6, 2002

Re: How big is the Direct3D stuff?

by Johan Gill

Lionel Ulmer wrote: >Hi all, > >As I once started working on Direct3D in Wine and was one of the contributor >to the DDraw code, let me answer some of these questions :-) > >> * What are the tasks for implementing Direct3D? >> > >It's not easy to separate the tasks. For one, documenting and >re-appropriating the DDraw code would be the first thing to do. > ><start of minor rant> > >As other people discussed it, the current DDraw code in WineHQ's CVS tree is >from TransGaming. I do not say that it's worse than the previous code (it's >certainly better and respects the DLL separation stuff), but my biggest >problem with it is that it was entirely developped 'in-house' and sumbitted >'as is' to the WineHQ tree without really involving any of the WineHQ >DirectX developpers (like Marcus or me). Now don't undertand this wrong, I >am certainly also to blame because I found other interests at that time and >mostly stopped working on Wine. > >This means that now that TG does not really contribute back much to WineHQ >(even in pure 2D stuff), we have a large piece of code that nobody really >bothered to undertand and is largely unmaintained. > >Now I understand why Linus absolutely refuses big patches doing a lot of >stuff in one go and wants small incremental patches :-) > >Finally, saying 'now let's start working on Direct3D' will not help much if >we do not find at least 3 or 4 people interested in working on it. I once >submitted some D3D work but nobody ever contributed to it and it was mostly >unmaintained once I stopped working on it (and I fear that would be the same >for other parts of Wine like Multimedia, the debugger for example, if Eric >did take some prolonged vacations :-) ) > I'm planning to do some work, but it's a matter of priorities, as always. /Johan Gill, johane(a)lysator.liu.se

June 6, 2002

RE: How big is the Direct3D stuff?

by Patrik Stridvall

> At 06:00 PM 6/6/02 +0200, Lionel Ulmer wrote: > >community's for not doing anything at all and letting things > in the state it > >was (well, not TG's fault except if you consider that they > 'bought out' the > >people who would have worked on it in their free time, but > that is just > >plain good business sense :-) ). > > What do you mean by 'bought out'? I suppose there where WINE > contributors > who now work for TG, right? Yes. > If this is the case it is another point in favour of the LGPL... First of all since it was in parts their code the could have relicensed it to whatever they wished, so that wouldn't have been that large problem. Secondly who are you to tell people what they can or can't do for a living?

June 6, 2002

Re: How big is the Direct3D stuff?

by Roland

At 06:00 PM 6/6/02 +0200, Lionel Ulmer wrote: >community's for not doing anything at all and letting things in the state it >was (well, not TG's fault except if you consider that they 'bought out' the >people who would have worked on it in their free time, but that is just >plain good business sense :-) ). What do you mean by 'bought out'? I suppose there where WINE contributors who now work for TG, right? If this is the case it is another point in favour of the LGPL... Roland

June 6, 2002

Do we need Direct3D? How about OpenGL?

by Roland

Hello, I just thought about this. AFAIK most good 3D games support OpenGL anyway. That means, they can run without D3D, right? If this is true maybe it would be more of an advantage to concentrate on other parts of DirectX first. Postpone D3D to a later moment...in a few years or so :)) Roland

June 6, 2002

Re: self-registerable standard DLLs

by Tony Lambregts

Alexandre Julliard wrote: >"John K. Hohm" <jhohm(a)acm.org> writes: > > > >>I noticed that the attempt to test comcat.dll on Win98 failed because >>DllRegisterServer is a stub returning E_NOTIMPL. I have added the >>registry entries for the component categories manager to winedefault.reg, >>which should suffice for normal Wine installations. Despite this, is it >>generally acceptable to have actual code to register/unregister a standard >>COM server DLL in its Dll[Un]RegisterServer? It would be redundant for >>normal Wine, but hey, it's not big or complex. >> >> > >Actually putting that in DllRegisterServer is arguably the right way >to do it. What we should have is some kind of installation step that >would register the Wine dlls, instead of having to put everything in >winedefault.reg. > > > Would it be a good idea to create a bug report for this?... Or does someone want to implement it right away... Tony Lambregts

June 6, 2002

Re: How big is the Direct3D stuff?

by Lionel Ulmer

Hi all, As I once started working on Direct3D in Wine and was one of the contributor to the DDraw code, let me answer some of these questions :-) > * What are the tasks for implementing Direct3D? It's not easy to separate the tasks. For one, documenting and re-appropriating the DDraw code would be the first thing to do. <start of minor rant> As other people discussed it, the current DDraw code in WineHQ's CVS tree is from TransGaming. I do not say that it's worse than the previous code (it's certainly better and respects the DLL separation stuff), but my biggest problem with it is that it was entirely developped 'in-house' and sumbitted 'as is' to the WineHQ tree without really involving any of the WineHQ DirectX developpers (like Marcus or me). Now don't undertand this wrong, I am certainly also to blame because I found other interests at that time and mostly stopped working on Wine. This means that now that TG does not really contribute back much to WineHQ (even in pure 2D stuff), we have a large piece of code that nobody really bothered to undertand and is largely unmaintained. Now I understand why Linus absolutely refuses big patches doing a lot of stuff in one go and wants small incremental patches :-) Finally, saying 'now let's start working on Direct3D' will not help much if we do not find at least 3 or 4 people interested in working on it. I once submitted some D3D work but nobody ever contributed to it and it was mostly unmaintained once I stopped working on it (and I fear that would be the same for other parts of Wine like Multimedia, the debugger for example, if Eric did take some prolonged vacations :-) ) So the current situation is *not* TransGaming fault, but largely the community's for not doing anything at all and letting things in the state it was (well, not TG's fault except if you consider that they 'bought out' the people who would have worked on it in their free time, but that is just plain good business sense :-) ). <end of minor rant> > * Can older versions be implemented independently from the newer ones? This is the big problem when doing DDraw work, designing stuff that : a) can work accross multiple DDraw versions (ie find the common stuff and implement hardware acceleration here and then doing the rest in some 'emulation' layer). b) can work accross multiple object 'types' (for example, a surface can be the front / back buffer, a texture, a ZBuffer, a compressed texture, some random buffer, an overlay, ...). c) respects the DLL separation (ie puts all 'hardware' related stuff like X11 calls or OpenGL in the X11drv). > * Do we have nothing at all or do we have something? What changes need > to be done to this something to make it better. We still have the old Direct3D code that I wrote to support DirectX 5 / 6 in CVS (not functionnal, but enough to see the ideas :-) ). > * What modifications are necessary to other parts (x11drv, DirectDraw) > to implement Direct3D? As said before, a lot of X11drv work and a DDraw rework :-) > * Are there other DirectX areas that are lacking and that will prevent > games from working even if we get Direct3D working (DirectPlay, > DirectInput)? Mostly all the DirectX 8 (Dinput and DSound 8) if we want to support Direct3D 3. Otherwise, we should have almost everything needed in the other DirectX stuff to implement Direct3D. > * One item I can suggest is adding support for XVideo to DirectDraw (I > believe that's where it fits) to enable hardware scaling and YUV > conversion when playing videos. This would be more for media players > than games but could be useful anyway. I have a patch than I am slowly working on to re-add the Xv support to DDraw (it's based on some work that Marcus did). But as explained before, it's not that easy to do :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 6, 2002

Re: imports by ordinal

by Andreas Mohr

On Thu, Jun 06, 2002 at 10:39:36AM +0000, juergen.schmied(a)debitel.net wrote: > Hi! > > I'd like to use in a internal wine-dll(shell32) a function exported by an other dll(shlwapi) by ordinal. > How can I do this in a clean way without use of GetProcAddress in a way it works with native dll's too? Well, if a Wine DLL exports a function as ordinal only, then we can expect the Windows counterpart to do the very same thing (i.e. the same functionality at the *same* ordinal, and no name). Thus I think that a pFunc = GetProcAddress(hMod, "#<ordinal>"); should be ok. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

June 6, 2002

Re: Need better documentation of Windows 16/32 APIs for Mingw Port

by Andreas Mohr

On Thu, Jun 06, 2002 at 01:16:16AM -0700, Steven Edwards wrote: > Does anyone where I can find some good information on > the win16/32 APIs? Any book refrences to amazon mabey? Search for win31wh.hlp and win31mwh.hlp. That should help. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

June 6, 2002

RE: null midi device

by degs

Fair enough - I'm suprised though - I thought pretty much all games these days used pre-recorded music aince Windows couldn't (until recently) be relied on to provide a synthesiser if the sound card didn't have one. -- degs -----Original Message----- From: Johan Gill [mailto:johane(a)lysator.liu.se] Sent: 06 June 2002 15:23 To: degs; wine-devel(a)winehq.com Subject: Re: null midi device degs wrote: >Hi, > >I can't see much benefit to a timidity output in Wine - it seems like an >awful lot of effort for little return. Very few general purpose Windows >applications actually do MIDI output. The exceptions would be: (very) old >games; MIDI file players (plenty of UNIX replacements for these) and music >production software. No one seriously using music production software is >going to want a MIDI output connected to timidity - the audio quality is not >good enough, and if they did want to use it I'd imagine the latancy/timeing >would not be tight enough. > >-- degs > Final Fantasy VII uses midi for music, that's my reason. /Johan Gill, johane(a)lysator.liu.se

June 6, 2002

Re: null midi device

by Johan Gill

degs wrote: >Hi, > >I can't see much benefit to a timidity output in Wine - it seems like an >awful lot of effort for little return. Very few general purpose Windows >applications actually do MIDI output. The exceptions would be: (very) old >games; MIDI file players (plenty of UNIX replacements for these) and music >production software. No one seriously using music production software is >going to want a MIDI output connected to timidity - the audio quality is not >good enough, and if they did want to use it I'd imagine the latancy/timeing >would not be tight enough. > >-- degs > Final Fantasy VII uses midi for music, that's my reason. /Johan Gill, johane(a)lysator.liu.se

June 6, 2002

Re: null midi device

by Lionel Ulmer

> I thought about it. you need to use timidity 0.20i (the last one from the original author released under LGPL, the next ones are released under GPL). > Then, to make it a real midi driver (in terms of Win32 API) which isn't a trivial task (for example, timidity pre-processes the full content of the MIDI file to be played, whilst a standard MIDI driver has to play midi notes on the fly...). I did start looking at that a long time ago, but without real results in so far. I think it would be better to support ALSA midi and then people could use Timidity as an Alsa 'plug-in' to do a software sequencer. Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 6, 2002

RE: null midi device

by degs

Hi, I can't see much benefit to a timidity output in Wine - it seems like an awful lot of effort for little return. Very few general purpose Windows applications actually do MIDI output. The exceptions would be: (very) old games; MIDI file players (plenty of UNIX replacements for these) and music production software. No one seriously using music production software is going to want a MIDI output connected to timidity - the audio quality is not good enough, and if they did want to use it I'd imagine the latancy/timeing would not be tight enough. -- degs -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com]On Behalf Of Eric Pouech Sent: 06 June 2002 15:01 To: johane(a)lysator.liu.se Cc: wine-devel(a)winehq.org Subject: Re: null midi device > I was thinking: Couldn't one use timidity to make a fake midi device > that actually produces sound? That would be something. I thought about it. you need to use timidity 0.20i (the last one from the original author released under LGPL, the next ones are released under GPL). Then, to make it a real midi driver (in terms of Win32 API) which isn't a trivial task (for example, timidity pre-processes the full content of the MIDI file to be played, whilst a standard MIDI driver has to play midi notes on the fly...). I did start looking at that a long time ago, but without real results in so far. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

June 6, 2002