April 2011 - Wine-devel - list.winehq.org

ERROR: Compile wine tests on WINDOWS with MS C/C++
by Gerold Jens Wucherpfennig 25 Apr '11

25 Apr '11

Regarding: 5.5.4. Standalone, using the Microsoft C++ Toolkit of http://www.winehq.org/docs/winedev-guide/testing-windows : I tried to compile dlls/rasapi32/test/rasapi.c on Windows and got these error messages: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. rasapi.c .\wine/test.h(66) : error C2143: syntax error : missing '{' before 'const' .\wine/test.h(70) : error C2054: expected '(' to follow 'inline' .\wine/test.h(71) : error C2085: 'winetest_strcmpW' : not in formal parameter li st .\wine/test.h(71) : error C2143: syntax error : missing ';' before '{' -- Gerold

2 1

Re: [PATCH 6/6] mmdevapi/tests: Add tests for IAudioClock
by Alexandre Julliard 25 Apr '11

25 Apr '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > + pcpos = 0; > + hr = IAudioClock_GetPosition(acl, &pos, &pcpos); > + ok(hr == S_OK, "GetPosition failed: %08x\n", hr); > + ok(pos == 0, "GetPosition returned non-zero pos before being started: %lld\n", pos); Please avoid %ll formats. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] wineoss.drv: Add MMDevAPI driver
by Alexandre Julliard 25 Apr '11

25 Apr '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > +{ > + int i, mixer_fd; > + oss_sysinfo sysinfo; > + static int print_once = 0; > + > + TRACE("%d %p %p %p\n", flow, ids, num, def_index); > + > + mixer_fd = open("/dev/mixer", O_RDONLY, 0); > + if(mixer_fd < 0){ > + ERR("OSS /dev/mixer doesn't seem to exist\n"); > + return AUDCLNT_E_SERVICE_NOT_RUNNING; > + } > + > + if(ioctl(mixer_fd, SNDCTL_SYSINFO, &sysinfo) < 0){ > + close(mixer_fd); > + > + if(errno == EINVAL){ > + ERR("OSS version too old, need at least OSSv4\n"); > + return AUDCLNT_E_SERVICE_NOT_RUNNING; You'll need a configure check too, things like the oss_sysinfo type don't exist on OSSv3. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 2)
by Alexandre Julliard 25 Apr '11

25 Apr '11

Charles Davis <cdavis(a)mymail.mines.edu> writes: > Try 2: don't depend on the existence of scsi-generic entries in the HAL tree. It's still not listing my /dev/hda CD drive. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/3] d3dx9: Implement ID3DXBaseEffect::GetParameterByName().
by Henri Verbeet 25 Apr '11

25 Apr '11

2011/4/20 Rico Schüller <kgbricola(a)web.de>: > +inline LPSTR get_partial_string(LPCSTR name, char initial, char final) That should probably be static instead of inline. Also, get_parameter_by_name() looks like it could be split up, and you can probably avoid the copy in get_partial_string().

2 1

Style updates for source.winehq/patches
by Jerome Leclanche 24 Apr '11

24 Apr '11

Attached patch to tools.git/patches/patches.css adds the necessary styling for a WineHQ-style patch status page: http://i.imgur.com/5ToSc.png The div class="main" needs to be replaced by the html attached in the other file. I can write a patch for it if it's to be included, but I cannot test it. Is it worth doing? J. Leclanche

1 0

Re: VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales
by Nikolay Sivov 23 Apr '11

23 Apr '11

On 4/23/2011 22:46, John Fremlin wrote: > Nikolay Sivov<bunglehead(a)gmail.com> writes: > >> On 4/23/2011 22:22, John Fremlin wrote: >>> Nikolay Sivov<bunglehead(a)gmail.com> writes: >>> >>>> On 4/23/2011 19:00, John Fremlin wrote: >>>>> Europeans write dates generally as dd-mm-yyyy. This makes sense. So does >>>>> yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some >>>>> reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere >>>>> as far as I know and contradicts the MS behaviour. >>>>> >>>>> I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 >>>>> >>>>> I've included a patch which fixes the problem and adds a testcase. Is >>>>> there anything I can do to improve the chances that this fairly >>>>> unambiguous fix meets the next release? -- I have some secret and >>>>> cunning plans which are unfortunately predicated on this being fixed. >>>>> @@ -3458,6 +3458,7 @@ static void test_VarDateFromStr(void) >>>>> DFS("02.01.1970"); EXPECT_DBL(25570.0); >>>>> DFS("02.13.1970"); EXPECT_DBL(25612.0); >>>>> DFS("02-13-1970"); EXPECT_DBL(25612.0); >>>>> + DFS("2020-01-11"); EXPECT_DBL(43841.0); >>>> Hi, John. >>>> >>>> This is locale-dependent thing, so it will need at least more tests >>>> for different locales (locales with different default month/day order >>>> I mean). >>> Hi Nikolay, >>> >>> Is there really ever a locale which actually parses ydm under the native >>> implementation? >> Not really, as far as I know. My point was to test with different >> pattern anyway. For example for >> yyyy/mm/dd and dd/mm/yyyy locales. Also this particular test is not >> very descriptive cause >> month and day in it both fit month or day range, so you can't tell how >> it's interpreted. > I don't understand the confusion here? > > The single test extra test is explicitly for a date that can only be > converted either as y-m-d or the imaginary Wine-only y-d-m format. That > should be interpreted in exactly one way, and it is interpreted > incorrectly at the moment. The patch fixes that. Yes, I got it. Wine converts 2020-01-11 string as 1st of November while native treats it as 11th of January. What I meant that test data should be clear about what field is day and what's a month. For your case it could be '2020-01-30' to make 30 invalid value for a month. > If you want extra tests, I'm sure they'd be great, but I think this > pretty unambiguously represents an improvement. About additional tests, what about cases like '2020-20-01' on locales that use 'mm/dd/yyyy' or '2020-01-30' for locales that are 'dd/mm/yyyy'? Even if you're sure patch doesn't break that it's always better to add more tests (maybe some tests for that are in already). > Who has authority to approve it? A patch? Alexandre Julliard, he's the only project maintainer. Send a patch to wine-patches(a)winehq.org when you think it's ready and you'll get some feedback if it's not.

1 0

VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales
by John Fremlin 23 Apr '11

23 Apr '11

Europeans write dates generally as dd-mm-yyyy. This makes sense. So does yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere as far as I know and contradicts the MS behaviour. I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902 I've included a patch which fixes the problem and adds a testcase. Is there anything I can do to improve the chances that this fairly unambiguous fix meets the next release? -- I have some secret and cunning plans which are unfortunately predicated on this being fixed.

2 3

Re: Matching Windows 7 folder locations?
by newsletter [at] Schiermeier-Software 23 Apr '11

23 Apr '11

Hello Dan, wdrwo> Windows 7 changed the folders in c:/users/$USERNAME around a bit. not only 'a bit'. There are a lot of changes in the folder structure since Vista: See URL: <http://msdn.microsoft.com/en-us/library/dd378457(v=VS.85).aspx> -- Joerg Schiermeier

1 0

Missing backtrace when debugging a game
by Jerome Leclanche 23 Apr '11

23 Apr '11

I'm currently trying to debug http://bugs.winehq.org/show_bug.cgi?id=25977. Even when running "winedbg bin/release/loader.exe", this is what happens: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00365327). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00365327 ESP:0033dd20 EBP:000003d9 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:00000000 ECX:0018e268 EDX:00000011 ESI:0018e268 EDI:0016e560 Stack dump: 0x0033dd20: 00000000 0018e268 003670f9 0033dd9c 0x0033dd30: 0033fb68 0002002a 001712b0 00000005 0x0033dd40: 100d2e46 00401920 0002002a 0033e39c 0x0033dd50: 0033ddc8 7edb2ff4 00000000 00000000 0x0033dd60: 00000000 00000000 00000690 0000041a 0x0033dd70: 0000002c 00000000 00000001 ffffffff 000c: sel=0067 base=00000000 limit=00000000 16-bit rw- Backtrace: 0x00365327: movl 0x0(%eax),%ecx Wine-dbg>bt Backtrace: Any advice, or idea why this would happen? Furthermore, is it a bug with winedbg, and worth filing? J. Leclanche

3 2