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

Re: msi: Test the install sequence order
by James Hawkins Oct. 12, 2006

Oct. 12, 2006

On 10/12/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > MSI installers usually have at least two install sequencing tables, > InstallExecuteSequence and InstallUISequence. If the install is run > at the Full UI level, then the installer executes the actions in the > InstallUISequence table in order, up to the ExecuteAction sequence. > At this point, the installer starts running through the actions in the > InstallExecuteSequence table. On the other hand, this test shows that > some actions in the InstallExecuteSequence are run before certain > actions in the InstallUISequence table. I don't know if the installer > has a set list of standard actions that are run in the > InstallExecuteSequence before the InstallUISequence, or what, but this > test at least shows that there is at least one action, ResolevSource, > that is run in the InstallExecuteSequence before other actions in the > InstallUISequence. The test works like this: > > InstallExecuteSequence InstallUISequence > ------------------------------------ ------------------------- > ResolveSource 850 SetMagicKey 925 > WriteRegistryValues 6000 ResolveSource 960 > ExecuteAction 1300 > > ResolveSource (IES) gets called to set the property SOURCEDIR. > SetMagicKey sets the property MAGICKEY to 1 only if the SOURCEDIR > property is set. WriteRegistryValues writes a certain registry key > only if MAGICKEY is set. If the ResolveSource from the > InstallExecuteSequence doesn't get called before SetMagicKey, then > SOURCEDIR will not be set, and SetMagicKey, and thus > WriteRegistryValues, will not be called. > > Changelog: > * Test the install sequence order. > *sigh* Ignore this for now. The solution is easier than all of this. Though documentation says otherwise, the SourceDir and SOURCEDIR property are set unconditionally when you run the install with MsiInstallProduct. I'll resend the tests without the ResolveSource action to show this. -- James Hawkins

1 0

Re: regedit: Allow importing UCS-2 and UTF-8 files created by Windows' regedit v5
by Detlef Riekenberg Oct. 12, 2006

Oct. 12, 2006

On Do, 2006-10-12 at 17:30 +0300, Paul Chitescu wrote: > + /* Attempt to guess the encoding from the first several > bytes */ > + > + /* Extremely crude routine to convert to 8-bit */ Thanks for working on this Feature. As already mentioned, UNICODE is the better way. (You can loose Informations, when using ANSI) An Example to use Files with different encodings is in: dlls/kernel32/profile.c => PROFILE_DetectTextEncoding(const void * buffer, int * len) PROFILE_Load(HANDLE hFile, ENCODING * pEncoding) -- By by ... Detlef

1 0

Coverity scan should be up and running again within the next 24 hours
by Paul Vriens Oct. 12, 2006

Oct. 12, 2006

Hi, just received an email (after I'd asked) that the Wine scans should be available again within the next 24 hours. The current main page http://scan.coverity.com/, doesn't show Wine currently but that also will change in the next 24 hours. Cheers, Paul.

1 0

Re: msvcrt: fread: fill buffer on small reads
by Alexandre Julliard Oct. 12, 2006

Oct. 12, 2006

Markus Amsler <markus.amsler(a)oribi.org> writes: > > + /* fill empty buffer on small reads */ > + if(!file->_cnt && rcnt <= MSVCRT_BUFSIZ) { > + MSVCRT__filbuf(file); > + /* reset internal buffer */ > + file->_cnt++; > + file->_ptr = file->_base; > + } You need to handle errors properly, and MSVCRT__filbuf is probably not the most appropriate thing to use here, a simple read would be better. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: regedit: Allow importing UCS-2 and UTF-8 files created by Windows'regedit v5
by Dmitry Timoshkov Oct. 12, 2006

Oct. 12, 2006

"Paul Chitescu" <paulc(a)voip.null.ro> wrote: > + /* Attempt to guess the encoding from the first several bytes */ > + if (encoding < 0) { > + if (line [0] == '\377' && line [1] == '\376') { > + encoding = 2; /* FF FE => UCS-2 little endian */ > + offset = 2; > + } > + else if (line [0] == '\357' && line [1] == '\277' && line [2] == '\275') { > + encoding = 1; /* EF BF BD => UTF-8 */ > + offset = 3; > + if (line [3] == '\357' && line [4] == '\277' && line [5] == '\275') > + offset += 3; > + } > + else > + encoding = 0; /* default => ASCII (hope so...) */ That's quite confising to use hex numbers in the comments and not use them in actual comparisons. -- Dmitry.

1 0

Re: regedit: Allow importing UCS-2 and UTF-8 files created by Windows' regedit v5
by Robert Shearman Oct. 12, 2006

Oct. 12, 2006

Paul Chitescu wrote: > Changelog: regedit: Allow importing UCS-2 and UTF-8 files created by Windows' > regedit v5. > > The code tries to detect the encoding from the first read bytes. UTF-8 is not > modified while UCS-2 is converted by keeping only the lower byte. > The code that you have added is really nasty. At the very least, you should be using WideCharToMultiByte to convert the UCS-2 characters, instead of just truncating them. Ideally though, the code should be converted to call the Unicode versions of the registry APIs and then to use MultiByteToWideChar to process UTF-8 and ASCII (CP_UNIXCP?) files. -- Rob Shearman

1 0

Re: localspl: Implement InitializePrintMonitor
by Alexandre Julliard Oct. 12, 2006

Oct. 12, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > +BOOL WINAPI localmon_create_globals(void) > +{ > + if (g_monitorex == NULL) { > + g_monitorex = spl_alloc_zero(sizeof(MONITOREX)); > + if (g_monitorex == NULL) return FALSE; > + > + g_monitorex->dwMonitorSize = sizeof(MONITOREX) - sizeof(DWORD); > + } > + return TRUE; It seems to me a static variable would work just as well, and save a whole lot of trouble... -- Alexandre Julliard julliard(a)winehq.org

1 0

winetest question
by Mikołaj Zalewski Oct. 12, 2006

Oct. 12, 2006

Why does winetest start programs with STARTUPINFO.wShowWindow = SW_HIDE? I think this makes some of the toolbar tests fail as they depend UpdateWindow sending a WM_PAINT (they fail when launched by winetest but pass when running comctl32_test.exe from the command line). Could I remove this line or call ShowWindow twice to cancel this effect? Mikolaj Zalewski

1 0

ws2_32/socket16.c:319
by Michael [Plouj] Ploujnikov Oct. 12, 2006

Oct. 12, 2006

I was doing janitorial Win64 printf format work on ws2_32 and noticed the following warning: ws2_32/socket16.c:319: warning: passing arg 3 of `WS_ioctlsocket' from incompatible pointer type which belongs to this piece of code: INT16 WINAPI ioctlsocket16(SOCKET16 s, LONG cmd, ULONG *argp) { return WS_ioctlsocket( s, cmd, argp ); /* <- line 319 */ } It looks like WS_ioctlsocket's third argument is defined to point to a u_long (http://source.winehq.org/source/dlls/ws2_32/socket.c#L2276) which belongs to BSD (http://source.winehq.org/source/include/winsock.h#L118 for example). Is it wrong "BSD-only" u_long in this function? Should WS_ioctlsocket be fixed to use a ULONG pointer? -- () ASCII Ribbon Campaign /\ - against HTML mail & vCards

4 3

Re: cfgmgr32: Move cfgmgr32.h to include/ to match the SDK
by Alexandre Julliard Oct. 12, 2006

Oct. 12, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > Hi, > > Changelog: > * Move cfgmgr32.h to include/ to match the SDK. When moving or adding headers, you need to fix include/Makefile.in too. -- Alexandre Julliard julliard(a)winehq.org

1 0