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

MSI SQL
by EA Durbin June 1, 2006

June 1, 2006

I changed the sql statement in my installer to read the following. SELECT * FROM Media WHERE LastSequence > %i , and it returns the 1st DiskId, with a LastSequence of 6, even after the LastSequence exceeds 6. The WHERE STATEMENT is broken in msi SQL. The installation of the first 6 .dlls works nicely, they are in my C: folder. trace:msi:ACTION_InstallFiles file paths L"C:\\windows\\temp\\FL_mfc71_dll_1_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" to L"C:\\mfc71.dll" trace:msi:ACTION_InstallFiles Pass 2: L"_a8c1851f3c994e35b6e28a65f4793745" trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `Media` WHERE `LastSequence` >=7" 0x7fb8f794 trace:msi:msiobj_addref 0x7fd53fd8 trace:msi:msiobj_addref 0x7fd53fd8 trace:msi:MSI_ParseSQL Parse returned 0 trace:msi:ready_media_for_file LastSequence 6 trace:msi:ready_media_for_file Source is CAB L"Disk1.cab" I also tried querying another table to ensure it is the WHERE statement and not a table specific problem. here is the result of the SELECT * FROM File WHERE Sequence >= 8 Though this query doesn't return in sequential order like from the Media table, I did find numbers lower than 8 in the results trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `File` WHERE `Sequence` >= 8" 0x7fb8fa38 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 7 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 2 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 1 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 3 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 5 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 4 Looks like the WHERE statement is broken in SQL.

1 0

Re: winspool/tests: Use 0xdeadbeef as magic Value
by Jeff Latimer June 1, 2006

June 1, 2006

A minor spelling mistake, deaddeef instread of deadbeef. Jeff Detlef Riekenberg wrote: >I was using 0x00dead00 before, but Dmitry suggested 0xdeadbeef, as this > > > >-#define MAGIC_DEAD 0x00dead00 >+#define MAGIC_DEAD 0xdeaddeef > >

2 1

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom
by Mike Hearn June 1, 2006

June 1, 2006

The location CD drives are mounted changes between systems, this patch is essentially specific to yours. Wine already supports HAL, which should solve this in a more correct manner (though we have reports it doesn't work for some games!), so how comes that's not enough? thanks -mike

4 4

wine problems on a 64bit system
by Pavel Troller June 1, 2006

June 1, 2006

Hi! As some of you know, I'm experimenting with my new 64bit systems. I've found that there are problems running a lot of applications, which normally run on a 32bit system. A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. On a 64bit system, it just prints fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around but the workaround seems to be unefficient, because nothing more happens. With a +relay, it shows that the program is looping, executing 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 0009:Ret msvcrt._except_handler3() retval=00000000 ret=7bc54d65 and nothing more, ad infinitum. The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message). Are there chances to fix this issue ? Or is it a system problem ? With regards, Pavel Troller

6 14

Text input box with scrollbar
by Augusto Arcoverde da Rocha June 1, 2006

June 1, 2006

Hi all, Where I can find the inputbox drawing code? Some of these box appear with scrollbar when testing Action Request System application under Wine, but not under MS Windows. Thanks, Augusto Arcoverde da Rocha

3 2

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory
by Alexandre Julliard June 1, 2006

June 1, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > + SetLastError(0xdeadbeef); > + res = GetPrintProcessorDirectoryA(NULL, NULL, 1, NULL, 0, &cbBuf); > + if(!res && ( (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) || > + (GetLastError() == 0xdeadbeef) )) { > + trace("Not implemented yet\n"); > + return; > + } Unless there really is a Windows version that fails here, this test is wrong. Things that are not implemented yet in Wine should be marked with todo_wine, not ignored. -- Alexandre Julliard julliard(a)winehq.org

2 2

Winecfg add CoreAudio to audio drivers list
by Emmanuel Maillard June 1, 2006

June 1, 2006

Changelog : Winecfg add CoreAudio to audio drivers list thanks Emmanuel

1 0

Re: Re: How are we doing?
by fenix＠club-internet.fr June 1, 2006

June 1, 2006

----Message d'origine---- >De: Alexandre Julliard <julliard(a)winehq.org> >A: Detlef Riekenberg <wine.dev(a)web.de> >Date: Thu, 01 Jun 2006 11:45:10 +0200 >Copie à: wine-devel(a)winehq.com, Mike Hearn <mike(a)plan99.net> >Sujet: Re: How are we doing? > >Detlef Riekenberg <wine.dev(a)web.de> writes: > >> During the Time, things changed and I get confused more and more times >> about "special Developers" and "other Developers", as well as "special >> Patches" and "other Patches". >> (It's also Possible, that i did not see the big differences before). > >There's no such thing as special developer vs. other developer, it's >more like a linear scale based on trust: the more I trust a developer >the easiest it is for him to get his patches committed. The only way >to earn trust points is by submitting consistently good patches. > >That doesn't mean you can't get stuff in if you aren't trusted, but it >means it will require extra scrutiny, which is why it's very important >at the beginning to send small patches that are easy to review. Once >you have earned enough trust you can get away with being a bit more >sloppy (but not too much, or you'll lose trust points again ;-) It's possible to see on wiki the "trust points" positions ? :) And on each WWN, see the variations (seems the famous kde buzz) :) Anyway, adding an explaining page on wiki for "how to begin as wine developper" may help a lot Regards, Raphael

4 3

Wine 1.0 Tasks
by Dan Kegel June 1, 2006

June 1, 2006

If you look at http://bugs.winehq.org/ you'll see a link on the left hand side called "1.0 Tasks", which lists the 1.0 bugs being tracked in bugzilla. Here's the URL it links to http://bugs.winehq.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_s… I suspect a few of these are stale, and a bunch others are missing, but I like the idea of using bugzilla to track our progress to 1.0. What other bugs should be fixed before 1.0? Let's nominate a few bugs to add to the 1.0 task list, discuss them a bit, and see what Alexandre thinks. For instance: I'd like one goal of 1.0 to be "make Windows developers take Wine seriously." To achieve that, I think 1.0 has to support at least some Microsoft development tools well, including their IDEs and debuggers. It's probably unreasonable to require 1.0 to support .NET, so maybe supporting the last pre-.NET versions of Visual C++ (6.2?) and Visual Basic (6.0?) would be a good goal. And I don't think it's that unreasonable anymore; Wine is pretty close to being able to do that. What do y'all think? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

8 14

Re: comctl32: Fix loading string from resources
by Alexandre Julliard June 1, 2006

June 1, 2006

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > LoadString() cannot be used to measure the length of a string resource. > It will not return the length of the string if no buffer is provided, > instead it will return 0! This patch fixes the broken property sheet code. Since you are going to the trouble of loading it all by hand, you should allocate and fill the buffer right away, instead of returning only the length and letting LoadString do the whole thing once again. Also a test case for LoadString demonstrating that the current behavior is wrong would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

2 1