May 2003 - Wine-Devel - list.winehq.org

Re: x11drv

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Oliver> Howdy, I was trying to do a new wine update to the latest CVS, > Oliver> and when cvs update gets to windows/x11drv, it just hangs. I > Oliver> tried deleting the windows directory and I'm using "-Pd." Is > Oliver> there a simple solution to this? > > You probably also have the -z option set, perhaps in your ~/.cvsrc. > > This option should be the culprit, it has been discussed before. Exactly. But now the question is what has happened to the WineHQ CVS tree that directories windows/ttydrv and windows/x11drv (removed long time ago) reappeared again? -- Dmitry.

May 5, 2003

Problem using winemaker/winelib

by Neven.Luetic＠t-online.de

Hello, I am currently trying to continue development of an originally Windows based project on Linux. To create a functioning Linux-executable, I have tried to use winemaker. When I specify the additional headers and libraries correctly, everything seems to be fine. At least configure and make do not show up with errors. The result of the make is a shared library, named like the executable I expected to build ("drobot.so") and a shell script "drobot". When I start this script I get: err:module:get_registry_value Invalid load order module-type L"so", ignored wine: cannot find 'drobot.exe' This seems to indicate some kind of error in the build process, because what was built is exactly a linux .so.If I change my wine config concerning DLLs from "*" = "builtin, native, so" into "*" = "builtin, native" the first message disappears. However wine is still looking for a drobot.exe (according to the generated script). The generated Makefile contains "drobot" as the executable, i.e. the shell script. What did I do wrong? Greetings -- Neven Luetic <Neven.Luetic(a)t-online.de>

May 5, 2003

solaris x86 development?

by Peter Lees

hello, what is the status of WINE development for solaris x86? i'm running into some fairly fundamental build bugs & would like to know if anyone has got it working. thks p

May 5, 2003

Re: Windows API db script

by David Miller

Ok, here is what I have. win98-4.10.1998 win95-4.00.950 winme-4.90.3000 winnt40-sp1-4.0.1381 winnt40-sp6-4.0.1381 win2k-sp1-5.00.2195 Should the service pack level change the OS version number? At 03:44 PM 5/4/2003 +0200, you wrote: >On Sun, 04 May 2003 04:46:49 -0400, Dave Miller <compsol(a)ptd.net> wrote: > > > I have posted an update to the script. Francois Gouget sent a patch > >to fix a problem handling uppercase filenames. The patched script is > >now available. Thanks to those who have submitted .ref files. I have > >five versions so far. Now it is time to think about what kind of > >queries we want to be able to do... > >You probalby should post the versions you already got and you still ned, so we >don't send it twice (or have to waste time installing a clean setup). > >Thanks for this tool. Quite nice. :) >-- >Gerhard Gruber > >Für jedes menschliche Problem gibt es immer eine einfache Lösung: >Klar, einleuchtend und falsch. (Henry Louis Mencken)

May 5, 2003

Re: Problem in ole32.CoCreateInstance ?

by Marcus Meissner

On Mon, May 05, 2003 at 07:09:07AM +0200, Sylvain Petreolle wrote: > Sorry, I didnt notice that lpclf is the variables that receives the > pointer. > > > Why not check why it's "always 0" for you, instead of complaining > > that > > it is? If the CoGetClassObject call can't obtain the class factory, > > it's > > usually because the registry entries are missing, incorrect, or the > > referenced dll can't be loaded, but then it should have returned a > > failure, and CoCreateInstance should then bail out before getting to > > this point. You could also find out why it didn't, then? > > Yes, found it. The problem isnt in the macro. :) > We should add a check in the case no class factory is found, to avoid > crashing. > But I dont understand why CoGetClassObject returns ok and leaves lpclf > set to NULL. > Adding a TRACE after CoGetClassObject I get : ... > trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=00000000 > <= shouldnt happen. Who is returning this hres 0x0 value? Which dll? Whoever it is, it is broken. Ciao, Marcus

May 5, 2003

Re: New metabugs

by Shachar Shemesh

Francois Gouget wrote: > * wine-gdi > 'Drawing, graphics, fonts, drivers' > > That appears to include BiDi. But I still think an >internationalization keyword that would cover BiDi, XIM, dead-keys, and >localization of resources would be a good thing. > > I am not sure what XIM is. In any case, I don't think BiDi+dead-keys should go in the same category as localization. The frist two are technological, and require a programmer knowledgable in the system, but which does not necessarily speak the language. The last is linguistic, and requires someone who speaks the language, but may not necesserilly know any programming at all. As for components - some BiDi stuff goes in GDI - sure. Text rendering is one obvious example. Adding BiDi to the Edit Control should go in GUI, however. I'm not sure where bugs such as 1163 should go (currently filed under GUI, but should probably go to GDI, as the underscores are added by DrawText). 1158 is a definite GUI. For those reasons I did not want to add a BiDi component, but rather a keyword. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

May 5, 2003

Re: Problem in ole32.CoCreateInstance ?

by Sylvain Petreolle

Sorry, I didnt notice that lpclf is the variables that receives the pointer. > Why not check why it's "always 0" for you, instead of complaining > that > it is? If the CoGetClassObject call can't obtain the class factory, > it's > usually because the registry entries are missing, incorrect, or the > referenced dll can't be loaded, but then it should have returned a > failure, and CoCreateInstance should then bail out before getting to > this point. You could also find out why it didn't, then? Yes, found it. The problem isnt in the macro. :) We should add a check in the case no class factory is found, to avoid crashing. But I dont understand why CoGetClassObject returns ok and leaves lpclf set to NULL. Adding a TRACE after CoGetClassObject I get : trace:ole:CoCreateInstance sanity check: hres=80040154, lpclf=00000000 trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=41fb14e4 trace:ole:CoCreateInstance sanity check: hres=80040154, lpclf=00000000 trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=40289148 trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=4029b7f8 trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=4029b830 trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=4029b668 trace:ole:CoCreateInstance sanity check: hres=00000000, lpclf=00000000 <= shouldnt happen. ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

May 5, 2003

Re: Re: Callbacks while app is looping

by Ove Kaaven

fre, 02.05.2003 kl. 21.03 skrev Mike Hearn: > > Well, the wine DInput implentation keeps an internal map of key states and > > updates these when an event happens. Its just this badly written bit of code > > thats using it to wait for a keyboard event :) > > I suspect the actual problem is that keyboard hooks require the app to > be processing messages in order to function. In fact, run that test app > in desktop mode - you'll see that it works fine, presumably because the > desktop continues processing messages even when the app within it is > not. > > I'm not sure what to do about this, it'd seem sensible to have X11 > events processed by the service thread, but I suspect there are reasons > why this isn't the case. Even so, the current thread can and should still process its incoming X11 events whenever it needs to. Adding an event-checking (but otherwise no-op) construct like MsgWaitForMultipleObjectsEx(0, NULL, 0, 0, 0); to GetDeviceState and GetDeviceData should be able to make this happen.

May 5, 2003

Re: New metabugs

by Dimitrie O. Paun

On May 4, 2003 10:27 pm, Francois Gouget wrote: > I continued looking at the component list and especially the component > definition page: > http://bugs.winehq.com/describecomponents.cgi?product=Wine > > Some interesting things I noticed: > > * wine-patches > 'Report consisting solely of a patch' > > I think this should be a keyword, 'patch', rather than a component. It should die, for sure. Patches should be sent to wine-{patches,devel} for inclusion or discussion. I have patches submitted to Bugzilla, they have about 0 visibility. A much better way to do it is to submit the patch to one of the above mentioned lists, and add a link to the archived message. This way: -- You get the patch out there, to a much wider audience -- You can have discution threads about it via regular email -- You get to link it to the bug, if relevant. > > * wine-help > 'Basic support or configuration request' > > I think such requests belong to wine-users rather than Bugzilla. The > reason is that I see Bugzilla as a way for developpers to track bugs in > the code and reports such as 'Application foo does not work' are > quite useless to developpers. They start to become more useful when you > get to the level of a crash with a relay log, a stack trace, a > meaningful FIXME, etc. > That being said, I'm not sure it would be 'right' to close such bugs. > But I think our policy should be to at least direct the reporter to > wine-users and assign the bug to the 'wine-help' component. Agreed. Let's nuke it. > * I still think it would be nice to be able to attach a bug to a > specific dll. I don't know if that means we should add a bunch of > components or a bunch of keywords or find yet another mechanism. > Similarly having keywords/components corresponding to the debug > channels would be nice. Maybe nice, but most likely overkill. Bugzilla is way too complicated already, half of it's features are most likely never used. You need a degree in Bugzilla to operate it properly, this would just make it even more complicated... -- Dimi.

May 5, 2003

Re: rpc exception

by Dimitrie O. Paun

On May 5, 2003 12:18 am, Ove Kaaven wrote: > Hmm. That could be solved by making the try block a nested function too, > but I suppose that would bring some overhead... If it fixes the problem, I'd take the overhead any time. If people are concerned about that, they can: A. Use a compiler that support the sytanx B. Rewrite the code to avoid using our compatibility macros -- Dimi.

May 5, 2003