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

Re: Native DDE problems

by List vmn

Erich!!!! Very Cool! Thanks for your prompt answer. Please send me the patch. I will surely test it! Just one question on your answer, my two apps are called DISP.EXE and PDV.EXE Is one of them 16 and the other 32 bit ? If I recompile both of them to 32 bit or 16 bit, should DDE work? I can also try that. Frankly, I didn´t even know that one was 16 and the other 32 bit. Miguel Feitosa At 21:11 26/2/2002 +0100, you wrote: > > The http://www.winehq.com/News/status.html states that the implementation > > of the serial/parallel port > > is 90% complete but that DDE is still being implemented by Eric Pouech and > > not functional. >the status page is now a bit outdated >DDE (and DDEML) now kinda work >however, some 16 bit support is still missing in DDE (and DDEML), hence >your >problems as the trace shows >as of today : >- two 32 bit apps should be able to communicate through DDE >- two 16 bit apps should be able to communicate through DDE >- however, a 16 bit and a 32 bit app will not be able to communicate > >I have a yet unfinished patch here that should (partly) take care of >that >if you have the wine source and are ready to do some testing, I can >provide >you the patch to see if it helps in your situation > >as DDEML is a pure 16 bit DLL (the 32 bit DDEML implementation is part >of >USER32), it's very unlikely that native DDEML will work in wine >so, sticking to builtin USER/USER32/DDEML is the only viable solution >(even >if it's not completly done yet) > >A+

Feb. 26, 2002

Re: Native DDE problems

by Eric Pouech

> The http://www.winehq.com/News/status.html states that the implementation > of the serial/parallel port > is 90% complete but that DDE is still being implemented by Eric Pouech and > not functional. the status page is now a bit outdated DDE (and DDEML) now kinda work however, some 16 bit support is still missing in DDE (and DDEML), hence your problems as the trace shows as of today : - two 32 bit apps should be able to communicate through DDE - two 16 bit apps should be able to communicate through DDE - however, a 16 bit and a 32 bit app will not be able to communicate I have a yet unfinished patch here that should (partly) take care of that if you have the wine source and are ready to do some testing, I can provide you the patch to see if it helps in your situation as DDEML is a pure 16 bit DLL (the 32 bit DDEML implementation is part of USER32), it's very unlikely that native DDEML will work in wine so, sticking to builtin USER/USER32/DDEML is the only viable solution (even if it's not completly done yet) A+

Feb. 26, 2002

Re: Menu Item problem(was Notepad not remaining language selection)

by Sylvain Petreolle

> Notepad is an application that is used so often > that we need > something to fill the role of 2. 1 and 2 need not be > completely > incompatible either. But I would personally lean > more towards 2, and a > removal of the menu. It seems to me that testing > various languages would > be better done by setting LANG, and even better, by > writing test units. > No problem if you want to remove the menu and the key. I will modify my proc to handle the function that gets the language from the system. In this case i can drop the proc that saves the language. What functions do the retrieval o the langage ? I'm pretty young in programming windows. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Feb. 26, 2002

Re: Out of process COM objects & Installshield v6

by Dan Kegel

Ove Kaaven wrote: > I've been working on this as part of my COM restructure. I've implemented > NdrDllRegisterProxy and large pieces of rpcrt4's marshaling framework. I'd > like to release it to WineHQ, but Gav still wants something in exchange. > (If we can't get money, we'll consider releasing it if a Wine developer > agrees to work on stuff that may be useful for us, like an ALSA driver, > and/or a Wine kernel module to speed up synchronization primitives (like > mutexes), or maybe more DirectShow work, or something of the kind.) Cool. I bet something could be worked out. As you know, David Howells did a bunch of work on a kernel module last year ( see http://marc.theaimsgroup.com/?l=linux-kernel&m=101344885113906&w=2 http://cvs.winehq.com/cvsweb/kernel-win32/ http://marc.theaimsgroup.com/?l=wine-devel&m=98628491209432&w=2 ) I wonder if Red Hat would be willing to have David bring his wine kernel module up to date in exchange for Transgaming contributing your COM work? - Dan

Feb. 26, 2002

Re: Menu Item problem(was Notepad not remaining language selection)

by Andriy Palamarchuk

--- Francois Gouget <fgouget(a)free.fr> wrote: > On Tue, 26 Feb 2002, Andriy Palamarchuk wrote: > [...] > > Then, what is the correct approach will be? Set > the > > default language based on system settings? > > We can leave the language menu for now for testing > > purposes. > > I guess this depends on whether you see Wine's > notepad as: > 1. a test program, primarily used by Wine > developpers to test Wine > 2. strictly a replacement for the Windows applet > > > If 1 then the menu can stay. But it could even > set the system-wide > notion of which language is used. If 2, then it is > not necessary and > should probably disappear. > > Notepad is an application that is used so often > that we need > something to fill the role of 2. 1 and 2 need not be > completely > incompatible either. But I would personally lean > more towards 2, and a > removal of the menu. It seems to me that testing > various languages would > be better done by setting LANG, and even better, by > writing test units. Agree, I'm also for notepad as an application and do the testint with unit tests. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

Feb. 26, 2002

Re: Bootprocedure again

by Gerhard W. Gruber

Andreas Mohr wrote: > Hmm, well, winebootup is supposed to execute everything *at once* > on Wine startup (i.e. check in the wine wrapper script whether this is > the first wine instance to get started, then run winebootup) > > If you don't think this is a good design, then go ahead and change it ! > (if it's better, that is ! ;) I think this is a good design when it is the way you are describe it here. What me bothered was, that there is a little bit of startup in loader/main.c and then there is a little bit of startup in winebootup. How can it check wether this is the first instance in a script? As I have seen in loader/main.c there is an if(firstthread) which I supposed to be what you mean with first instance and I thought this would be the natural place to go for that thing. Is winebootup going to replace wine then, once it is finished? Otherwise there would be two boot programs doing almost similar things and that's what I consider a bad design. :)

Feb. 26, 2002

Re: Menu Item problem(was Notepad not remaining language selection)

by Francois Gouget

On Tue, 26 Feb 2002, Andriy Palamarchuk wrote: [...] > Then, what is the correct approach will be? Set the > default language based on system settings? > We can leave the language menu for now for testing > purposes. I guess this depends on whether you see Wine's notepad as: 1. a test program, primarily used by Wine developpers to test Wine 2. strictly a replacement for the Windows applet If 1 then the menu can stay. But it could even set the system-wide notion of which language is used. If 2, then it is not necessary and should probably disappear. Notepad is an application that is used so often that we need something to fill the role of 2. 1 and 2 need not be completely incompatible either. But I would personally lean more towards 2, and a removal of the menu. It seems to me that testing various languages would be better done by setting LANG, and even better, by writing test units. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Feb. 26, 2002

Re: Bootprocedure again

by Andreas Mohr

On Tue, Feb 26, 2002 at 12:14:15PM +0100, Gerhard W. Gruber wrote: > David Elliott wrote: > > Anyway, on a personal note, don't get disheartened that the wine > > developers don't like you. Believe me, EVERYBODY who has contributed code > > to Wine has had some code or some ideas frowned upon. Just think about it > > Good to know. :) Of course I know that someone, who works for a long > time on a project, has some ideas as to how something has should be > done. Sometimes this is good and somtimes this is bad, but I don't want > to throw everything around when there are already plans on how something > should be integrated. That's why I started that thread. Hmm, well, winebootup is supposed to execute everything *at once* on Wine startup (i.e. check in the wine wrapper script whether this is the first wine instance to get started, then run winebootup) If you don't think this is a good design, then go ahead and change it ! (if it's better, that is ! ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Feb. 26, 2002

Re: Codeweavers' integrity (or lack thereof)

by Roland

At 02:36 PM 2/25/02 -0700, Brett Glass wrote: >At 02:32 PM 2/25/2002, Andreas Mohr wrote: > > >I'm not much in favour of a license change, but if there's enough reason to > >believe that a "new" license boosts Wine's productivity, then I'm all > >for it. > >There has been no credible evidence to that effect presented to date. >However, the threats that a new license would pose to participation >in the project by companies such as Transgaming or Lindows have been >amply demonstrated. > >--Brett Glass Agreed. And I want to add that we also should think if the price we are paying with the license change in the long run is worth the EVENTUAL TEMPORARY boost in productivity. It MAY BE that now we have a temporary boost because one company wishes this license change and will start to contribute more after that. But it is not certain if that company will still be around in some years or if other companies will NOT contribute to WINE because of the new xGPL license. After all, if we wanted a productivity boost lets license all WINE code to Microsoft, I'm sure they would agree to help develop it further in turn :))) Roland

Feb. 26, 2002

Re: Alternative make scripts

by Dimitrie O. Paun

On Tue, 26 Feb 2002, Andriy Palamarchuk wrote: > Does that mean we don't need alternative build scripts > in the Wine tree (probably except winetest)? I'd personally would want to see our Makefile system be portable enough to do this. When I tried porting Wine to cygwin, they were good enough, so I see no reason for a separate script. -- Dimi.

Feb. 26, 2002