- Wine-Devel - list.winehq.org

Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
by Dimitrie O. Paun Oct. 12, 2004

Oct. 12, 2004

> * - the modification time optionally follows the key name > - * - REG_EXPAND_SZ and REG_MULTI_SZ are saved as strings instead of hex > + * - REG_EXPAND_SZ are saved as strings instead of hex > + * - REG_MULTI_SZ are saved hex (as of 10/10/04 -- see Bug 824) > */ Well, I don't know if the fix is correct, but if it is, just remove the comment instead of saying it's fixed, otherwise we risk cluttering the real issues to the point where they are useless. -- Dimi.

1 0

Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
by Chris Morgan Oct. 12, 2004

Oct. 12, 2004

It would be useful to roll this test into the integrated winetests so we can check this behavior on all windows platforms and prevent it from breaking in the future. Chris > > From: Randy Galbraith <randy.galbraith(a)cox.net> > Date: 2004/10/11 Mon PM 09:19:42 EDT > To: wine-patches(a)winehq.org > Subject: Fix for bug 824 - proper handling of REG_MULTI_SZ > > This proposed patch addresses the concern raised by bug 824. This patch > changes the handling of REG_MULTI_SZ from REG_SZ to REG_BINARY. For > more details follow this URL: > > http://bugs.winehq.org/show_bug.cgi?id=824 > > To see a test program follow this URL: > > http://members.cox.net/~rgalbraith10/wine/bug824/demo824.c > http://members.cox.net/~rgalbraith10/wine/bug824/Makefile > > ===begin diff -u output of wine/server/registry.c 1.60=== > --- registry.c- 2004-10-10 10:46:15.000000000 -0700 > +++ registry.c 2004-10-10 12:26:35.000000000 -0700 > @@ -157,7 +157,8 @@ > * - strings and key names can contain \x escapes for Unicode > * - key names use escapes too in order to support Unicode > * - the modification time optionally follows the key name > - * - REG_EXPAND_SZ and REG_MULTI_SZ are saved as strings instead of hex > + * - REG_EXPAND_SZ are saved as strings instead of hex > + * - REG_MULTI_SZ are saved hex (as of 10/10/04 -- see Bug 824) > */ > > > static inline char to_hex( char ch ) > @@ -195,7 +196,6 @@ > { > case REG_SZ: > case REG_EXPAND_SZ: > - case REG_MULTI_SZ: > if (value->type != REG_SZ) fprintf( f, "str(%d):", value->type ); > fputc( '\"', f ); > if (value->data) dump_strW( (WCHAR *)value->data, value->len / > sizeof(WCHAR), f, "\"\"" ); > @@ -1123,7 +1123,7 @@ > { "\"", 1, REG_SZ, REG_SZ }, > { "str:\"", 5, REG_SZ, REG_SZ }, > { "str(2):\"", 8, REG_EXPAND_SZ, REG_SZ }, > - { "str(7):\"", 8, REG_MULTI_SZ, REG_SZ }, > + { "hex(7):", 8, REG_MULTI_SZ, REG_BINARY }, > { "hex:", 4, REG_BINARY, REG_BINARY }, > { "dword:", 6, REG_DWORD, REG_DWORD }, > { "hex(", 4, -1, REG_BINARY }, > ===end diff -u output=== > This is my first attempt at creating a patch for wine. Any feedback is > greatly appreciated. > > Kind regards, > -Randy Galbraith > > >

1 0

winetest fails enumerating test files
by Saulius Krasuckas Oct. 12, 2004

Oct. 12, 2004

It shows some message-box telling: "Can't enumerate test files: 1813" Greping programs/winetest/main.c gives: | report (R_STATUS, "Counting tests"); | if (!EnumResourceNames (NULL, MAKEINTRESOURCE(TESTRES), | EnumTestFileProc, (LPARAM)&nr_of_files)) | report (R_FATAL, "Can't enumerate test files: %d", | GetLastError ()); | wine_tests = xmalloc (nr_of_files * sizeof wine_tests[0]); I guess this may be some regression (have been running winetest a whole month ago last time). Am I alone with this?

2 3

Re: wineserver contexts for Alpha
by Steven Edwards Oct. 12, 2004

Oct. 12, 2004

Hi, --- Vincent B�ron <vberon(a)mecano.gme.usherb.ca> wrote: > There are two definitions of _CONTEXT for Alpha in winnt.h: one > protected by __ALPHA__ (added by Steven 2 years ago), and one > protected > by _ALPHA_, which is the same kind of protection as MSVC. Should we > dump > the __ALPHA__ one and change configure to define _ALPHA_ instead? Yes sorry dump the one I added. I totally missed it and did not have MSVC+PSDK installed then. Thanks Steven _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

1 0

tchar.h
by Martin Fuchs Oct. 11, 2004

Oct. 11, 2004

Hello, can anyone explain to me, what's the exact reason for the following error message in wine/include/tchar.h: #if defined(_UNICODE) || defined(_MBCS) #error You must use msvcrt when building in Unicode/MBCS mode #endif It disallows inclusion of this <tchar.h> header file when using the _UNICODE define. Just a few lines later in this file there are the following definitions: /***************************************************************************** * tchar mappings */ #ifndef _UNICODE # ifndef _MBCS # include <string.h> # define WINE_tchar_routine(std,mbcs,unicode) std # else # include <mbstring.h> # define WINE_tchar_routine(std,mbcs,unicode) mbcs # endif #else /* _UNICODE */ # include <wchar.h> # define WINE_tchar_routine(std,mbcs,unicode) unicode #endif Again asking for "_UNICODE" ! So something can't be right with this. The <tchar.h> header should really define constants like _tcschr dependend on the _UNICODE define. But currently this doesn't work because of the error message described above. Either there should be a overriding "wine/include/msvcrt/tchar.h" file with different defintions. Or the error message "You must use msvcrt when building in Unicode/MBCS mode" is simply superfluous. Regards, Martin

2 1

Re: [Bug 2388] WM_NEXTDLGCTL changes the default button ID and does not restore default control identifier
by Alexandre Julliard Oct. 11, 2004

Oct. 11, 2004

Katia Maculan <katia.maculan(a)isis-papyrus.com> writes: > part of the patch is not committed, is there a reason for that? Is > something wrong? It doesn't look right at all to do dialog management in the button code itself. Also, please submit a regression test showing that the proposed change is correct and that the current code is wrong. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: wine-devel digest, Vol 1 #3011 - 15 msgs
by Rolf Kalbermatter Oct. 11, 2004

Oct. 11, 2004

Vitaliy Margolen wrote: > Well, I tried to shuffle the order of creation of these > files. The results I got was as follows: > - On windows I was getting "sorted by name" order. > - On Linux I was getting creation order. Funny thing is I work on Suse Linux 9.0 with current wine CVS and IEnumIDList in the shelfolder test returns for me test.txt, testdir2, test1.txt, test2.txt, and test3.txt in that order. So I can't confirm the idea that Wine under Linux would always enumerate files in a directory nor in alphabetically order nor in order of creation. > I tested XP, 2003 and 98 all with same results. So my > assumption was that I would always get the "sorted by name" > order from windows no meter what. I could be wrong here. If > this is the case it has something to do with SHFolder's > heading information, that we currently ignore. If you mean the selected column in a shell folder view, that should not have any influence on the order of files returned for an IEnumIDList object. It does not and can't now about the column to use for ordering nor should it do any specific ordering AFAICS. This is supposed to be done by the IShellView through use of the IShellFolder's CompareIDs method Rolf Kalbermatter

3 2

Re: widl: added dispinterface and coclass
by Mike Hearn Oct. 11, 2004

Oct. 11, 2004

Jacek Caban wrote: > Changelog: > - Added creation of dispinterface header > - Added creation of coclass header > - Added messages when fopen failes Cool! How far away are we from having widl generate the proxy/stub marshalling code? I started writing some COM test cases last night but it's really hard to test anything non-trivial without a test object that supports marshalling and I doubt Alexandre would want MIDL code in the test suite (or maybe he would, that is what we have to run after all ...) thanks -mike

2 4

RFC re winmm/time.c
by Jeremy White Oct. 11, 2004

Oct. 11, 2004

Hi Folks, I ran into a problem with PowerPoint and winmm timer events, that has led me to radically alter this file. However, I'd appreciate a gut check from anyone more experienced with it than I. The fundamental problem is that Powerpoint does a timeBeginPeriod(1), trying to set timer resolution to 1 ms; we steadfastly discard that, and continue generating time updates and events on a roughly 10 ms interval, this can, in rare situations, lead to some awkward delays. Some investigation with a test program shows that most Windows systems start with a default resolution of 1 ms. This test program is attached; the 'average' reported at the top is the default resolution. Further, Windows seem to steadfastly ignore any timeBeginPeriod(x) where x > the current period. I surveyed about 6 systems; a mix on Win98/Win2k and Win XP. All but one rogue Win 2K system had a 1 ms timer interval (the rogue system had a 10 ms interval; why, I do not know). The MSDN pages suggest (but don't state clearly) that this is the expected behavior. This behavior essentially means that on most Windows systems the timer resolution of winmm is 1ms and can not be changed. So, question #1: anyone object if I fix the timer resolution at 1 ms? Next, if I make this change, it makes the code in time.c, which is fairly awkward imho, even less efficient. We'll basically be scanning a loop every ms for no particularly good reason. I couldn't stomach this, so I rewrote it. Question #2: anyone object to my change? I have tested it with my attached test program, and I appear to have gotten it right, but... Thoughts? Comments? Flames? Suggestions I go back to my day job? <grin> Cheers, Jeremy

3 5

Re: Warcraft 3 Copy Protection (regression?)
by Brian Gunlogson Oct. 11, 2004

Oct. 11, 2004

Warcraft 3 will not run without a crack after the following commit: http://www.winehq.org/hypermail/wine-cvs/2004/03/0093.html If no one wants to tackle this immediately I'd like to fix it. Any ideas? Brian G. > > I don't know whether the difference was something about the version of WC3, or > > because I'd just upgraded to a 2.6 kernel, or because of the Wine > > version (20040309), but having upgraded Wine to 20040505 it no longer works. > Some work was done to load the copy protection drivers, it would be very nice to > get this working again. Can you try wine-20040408 to see if it works with that > version? You can then pinpoint the regression by running CVS regression testing, > instructions are at http://www.winehq.com/site/docs/wine-devel/cvs-regression > > Ivan. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com

2 1