July 2004 - Wine-Devel - list.winehq.org

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

by Paul Davis

>>Once again how can you fuss about unstable interfaces on a project that >>does not have a stable release? You could work with Winehq to create >>those stable interfaces. PDB might not be able to fuss, but I will. I recently asked about a way to figure out which version of Wine is in use at run-time because of the recent changes to wine_init()'s prototype. Alexandre appeared quite adamant that he was against introducing any such mechanism. Wine has a bit of a problem with the Mono project and our much smaller FST project to support VST win32/x86 plugins on linux. It has previously been a self-contained project that did not provide libraries, and whose internal API was not accessed by anyone or anything outside of Wine itself. It now is being used by (at least) 2 projects as a *library*, and it can either accept that role - which implies providing (at least) runtime version info - or reject it, which would be a great shame. --p

July 2, 2004

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

by Peter Dennis Bartok

May I remind you that this thread was started by you, asking why we are abandoning Wine, not by me complaining about Wine. All I did was give you the reasons why we are no longer using Wine. You may not like them, you may disagree with them, but the decision has been made. And there is really nothing to be gained in nitpicking or pointing fingers. I don't understand the comment about managed Quake, but we don't have to create managed Wine. We simply have to create the SWF controls in managed code and the underlying SWF framework. Wine doesn't have anything to do with the framework, anyway, so it's down to the controls. And even by using the Wine controls we still would have to either modify Wine to support the additional functionality required by SWF, or subclass them, basically recreating the drawing code for those controls and just using the WndProc messages from Wine. So, you can see it's really just a small step to then drop Wine and handle the management of Windows ourselves instead of using Wine for it. Not trying to be rude either. You asked, I answered. Peter -----Original Message----- From: "Steven Edwards" <steven_ed4153(a)yahoo.com> To: "Peter Dennis Bartok" <peter(a)novonyx.com>; <mono-winforms-list(a)ximian.com> Cc: <wine-devel(a)winehq.com> Date: Thursday, 01 July, 2004 21:03 Subject: Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans. >Hello Peter, > >I am not trying to be rude but... > >--- Peter Dennis Bartok <peter(a)novonyx.com> wrote: >> >Rather than spending a whole lot of time rewritting things wouldnt >> it >> >be better to help the Wine project get stable and move to the 1.0 >> goal? >> >There is a roadmap and TODO on Winehq of things that are needed for >> >1.0. >> No, it wouldn't. Even if Wine already was 1.0 we still would not have >> the >> portability we're trying to get (ie. run on Solaris Sparc, Mac OS, >> etc) and > >Well Winelib does run on PPC and the port to Sparc is mostly done. 99% >of Wine even compiles on Alpha here for me. See > >http://www.winehq.com/site/status_porting > >> debugging would still be almost impossible (Wine does funky stuff >> with >> register for thread storage, special stuff would be required to setup >> Mono-created threads before they'd be able to call Wine functions, >> etc). >> Also, there doesn't seem to be much interest from the Wine community >> to do >> anything that helps using Wine with SWF/Mono. We've had to resort to >> some >> quite complicated mechanisms to even be able to use Wine as a shared, >> runtime attached library, after Alexandre rejected a patch that only >> touched >> six lines of existing Wine code and added a new library to Wine, to >> allow >> straightforward use of Wine as a library. Having to take instead the >> complicated route it now means that many people are having problems >> getting >> SWF to run at all, with due to strict path dependencies. > >I was there when Miguel came online to ask why the patch was not merged >and I also seem to recall Alexandre proposed a fix the would work and >seemed to make Miguel happy. > >See: >http://www.winehq.org/hypermail/wine-devel/2004/03/0150.html > >> Another problem was that we had to spend way too much time tracking >> what >> changed from one Wine version to the next. For example from April to >> May, >> the wine_get_unix_file_name() function arguments were changed (I'm >> not even >> asking why it was changed instead of introducing a new function with >> different arguments and leaving the old one for those people who >> might use >> it). Since I can't require always the latest Wine version, I have to >> come up >> with code figuring out what Wine version might be running, and write >> code to >> make version dependent Wine calls. I'd rather spend that time >> improving SWF. > >Once again how can you fuss about unstable interfaces on a project that >does not have a stable release? You could work with Winehq to create >those stable interfaces. > >Besides how can you blame the Wine project for tracking changes when >the first patch Mono submitted was this? > >http://primates.ximian.com/~duncan/mono-wine/sources/mono-wine.patch > >A whole bunch of #ifdefs and other kludges that violates Winehq coding >standards. > >> Notice how people complain on this mailing that they're having >> problems >> getting even basic stuff going? The SWF code works, it's the >> interaction >> with Wine that's mostly causing the problems. Again, as I said, it >> will >> become much easier for the regular user once the Wine dependency is >> removed >> and the controls are all in managed code. > >Alright well I am not claiming to know very much about the project. >Like I said I only lurk here because I care about how its going to run >on ReactOS. I guess my final though on the matter is that if Vertigo >Software could make a mananged Quake2, how hard can it be for you to >make a managed Wine? > >Thanks >Steven > > > > >__________________________________ >Do you Yahoo!? >Yahoo! Mail - 50x more storage than other providers! >http://promotions.yahoo.com/new_mail >_______________________________________________ >Mono-winforms-list maillist - Mono-winforms-list(a)lists.ximian.com >http://lists.ximian.com/mailman/listinfo/mono-winforms-list > >

July 2, 2004

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.

by Steven Edwards

Hello Peter, I am not trying to be rude but... --- Peter Dennis Bartok <peter(a)novonyx.com> wrote: > >Rather than spending a whole lot of time rewritting things wouldnt > it > >be better to help the Wine project get stable and move to the 1.0 > goal? > >There is a roadmap and TODO on Winehq of things that are needed for > >1.0. > No, it wouldn't. Even if Wine already was 1.0 we still would not have > the > portability we're trying to get (ie. run on Solaris Sparc, Mac OS, > etc) and Well Winelib does run on PPC and the port to Sparc is mostly done. 99% of Wine even compiles on Alpha here for me. See http://www.winehq.com/site/status_porting > debugging would still be almost impossible (Wine does funky stuff > with > register for thread storage, special stuff would be required to setup > Mono-created threads before they'd be able to call Wine functions, > etc). > Also, there doesn't seem to be much interest from the Wine community > to do > anything that helps using Wine with SWF/Mono. We've had to resort to > some > quite complicated mechanisms to even be able to use Wine as a shared, > runtime attached library, after Alexandre rejected a patch that only > touched > six lines of existing Wine code and added a new library to Wine, to > allow > straightforward use of Wine as a library. Having to take instead the > complicated route it now means that many people are having problems > getting > SWF to run at all, with due to strict path dependencies. I was there when Miguel came online to ask why the patch was not merged and I also seem to recall Alexandre proposed a fix the would work and seemed to make Miguel happy. See: http://www.winehq.org/hypermail/wine-devel/2004/03/0150.html > Another problem was that we had to spend way too much time tracking > what > changed from one Wine version to the next. For example from April to > May, > the wine_get_unix_file_name() function arguments were changed (I'm > not even > asking why it was changed instead of introducing a new function with > different arguments and leaving the old one for those people who > might use > it). Since I can't require always the latest Wine version, I have to > come up > with code figuring out what Wine version might be running, and write > code to > make version dependent Wine calls. I'd rather spend that time > improving SWF. Once again how can you fuss about unstable interfaces on a project that does not have a stable release? You could work with Winehq to create those stable interfaces. Besides how can you blame the Wine project for tracking changes when the first patch Mono submitted was this? http://primates.ximian.com/~duncan/mono-wine/sources/mono-wine.patch A whole bunch of #ifdefs and other kludges that violates Winehq coding standards. > Notice how people complain on this mailing that they're having > problems > getting even basic stuff going? The SWF code works, it's the > interaction > with Wine that's mostly causing the problems. Again, as I said, it > will > become much easier for the regular user once the Wine dependency is > removed > and the controls are all in managed code. Alright well I am not claiming to know very much about the project. Like I said I only lurk here because I care about how its going to run on ReactOS. I guess my final though on the matter is that if Vertigo Software could make a mananged Quake2, how hard can it be for you to make a managed Wine? Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

July 2, 2004

Re: collation tables

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)altlinux.ru> wrote: > In test dlls/kernel/tests/locale.c > I see comment > /* this requires collation table patch to make it MS compatible > */ > I get trouble with one program it needed collation table to be > identical to MS table. What app is it? In which way it depends on the collation table being MS compatible? Crossover Office has a patched version libs/unicode/collation.c, could you try it with your aplication? > Does anyone knows what is the better way to fix this tables, in > which place? Can I fix libs/unicode/cpmap.pl for it? Yes, that was an idea. -- Dmitry.

July 1, 2004

Re: fix bug in GetCPInfo

by Vitaly Lipatov

On Thursday 01 July 2004 23:09, Uwe Bonnes wrote: > >>>>> "Vitaly" == Vitaly Lipatov <lav(a)altlinux.ru> writes: > > Vitaly> Bug: When call GetCPInfo with CP_ACP for example, > in returned Vitaly> structure field CodePage filled with > CP_ACP constant, not real Vitaly> codepage of current ACP. The > attached patch fix this bug. I Vitaly> have compared behavior > of this functions with Win2003. > > This implies, that you have written a test. Please provide the > test for our test suite. test is attached. I see in output (for ru_RU.KOI8-R locale in Linux): GetOEMCP = 866 isValidCodePage = 1 GetACP = 1251 isValidCodePage = 1 GetCPInfo for CP_ACP (OK=1) MaxCharSize=1 GetCPInfoEx for CP_ACP (OK=1) MaxCharSize=1 CodePage=0 CodePageName=ANSI Cyrillic isValidCodePage = 0 CodePage is filled by zero. You can compare with Win2003. -- Lav Vitaly Lipatov Saint-Petersburg GNU! ALT Linux Team! LaTeX! LyX!

July 1, 2004

Re: fix bug in GetCPInfo

by Uwe Bonnes

>>>>> "Vitaly" == Vitaly Lipatov <lav(a)altlinux.ru> writes: Vitaly> Bug: When call GetCPInfo with CP_ACP for example, in returned Vitaly> structure field CodePage filled with CP_ACP constant, not real Vitaly> codepage of current ACP. The attached patch fix this bug. I Vitaly> have compared behavior of this functions with Win2003. This implies, that you have written a test. Please provide the test for our test suite. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 1, 2004

Re: Delayed breakpoints in winedbg

by Eric Pouech

Adrian Rees a écrit : > Hi all, > > Apologies in advance for what is probably a dumb question... > > I'm trying to debug a windows application by breaking on a call to a DLL > function - in fact it's the NtCreateKey function within the ntdll > library. > > I must be missing something fundamental because the debugger indicates > that it has set a delayed breakpoint, but the breakpoint is never > reached, although turning on debugging messages clearly indicates that > the function is being called. that's strange. ntdll should always be loaded when you enter the debugger. So, I wonder whether your DLLs have been compiled with the debug information set. Could you post the output of 'info share' from the debugger command line ? A+

July 1, 2004

collation tables

by Vitaly Lipatov

In test dlls/kernel/tests/locale.c I see comment /* this requires collation table patch to make it MS compatible */ I get trouble with one program it needed collation table to be identical to MS table. Does anyone knows what is the better way to fix this tables, in which place? Can I fix libs/unicode/cpmap.pl for it? Any suggestions? -- Lav Vitaly Lipatov Saint-Petersburg GNU! ALT Linux Team! LaTeX! LyX!

July 1, 2004

Re: psapi.dll tests

by Ferenc Wagner

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > >> Hi, please somebody enlighten me! How does this test >> work once psapi_test.exe is linked with -lpsapi? How can >> a program start at all without one of its hard >> dependencies? > >> START_TEST(module) >> { >> dll = LoadLibrary("psapi.dll"); >> if (!dll) { >> trace("LoadLibraryA(psapi.dll) failed: skipping tests with target module\n"); >> return; >> } > >> The above seems to be a common idiom which I don't >> understand as opposed to using GetProcAddress and >> invoking functions through pointers. What am I missing >> here? > > If the library is already loaded, LoadLibrary returns the > HModule of the already loaded module, to my knowledge... Fine, but what for? Once this code is given control we can be sure that run-time linking is done, ie. psapi.dll was found and loaded. What do we test then? -- Feri.

July 1, 2004

Re: psapi.dll tests

by Uwe Bonnes

>>>>> "Ferenc" == Ferenc Wagner <wferi(a)afavant.elte.hu> writes: Ferenc> Hi, please somebody enlighten me! How does this test work once Ferenc> psapi_test.exe is linked with -lpsapi? How can a program start Ferenc> at all without one of its hard dependencies? Ferenc> START_TEST(module) { dll = LoadLibrary("psapi.dll"); if (!dll) { Ferenc> trace("LoadLibraryA(psapi.dll) failed: skipping tests with Ferenc> target module\n"); return; } Ferenc> The above seems to be a common idiom which I don't understand as Ferenc> opposed to using GetProcAddress and invoking functions through Ferenc> pointers. What am I missing here? -- Feri. If the library is already loaded, LoadLibrary returns the HModule of the already loaded module, to my knowledge... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 1, 2004