- Wine-Devel - list.winehq.org

GetDriveTypeW crash
by Robert Reif April 27, 2004

April 27, 2004

I'm having problems with several programs crashing in GetDriveTypeW. I recently did a fresh install from source with tools/wineinstall so it may be a config problem. Any ideas where to start? Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x404944b0). In 32-bit mode. 0x404944b0 (GetDriveTypeW+0xac [volume.c:110] in KERNEL32.DLL): movw 0x0(%edi),%ax 111 { Wine-dbg>bt Backtrace: =>0 0x404944b0 (GetDriveTypeW+0xac(root=0x0) [volume.c:110] in KERNEL32.DLL) (ebp=4081e8b8) 1 0x40493294 (GetVolumeInformationW+0x300(root=0x0, label=0x0, label_len=0x0, serial=0x0, filename_len=0x4081fb34, flags=0x4081fb38, fsname=0x0, fsname_len=0x0) [volume.c:683] in KERNEL32.DLL) (ebp=4081f7b8) 2 0x40493551 (GetVolumeInformationA+0x91(root=0x0, label=0x0, label_len=0x0, serial=0x0, filename_len=0x4081fb34, flags=0x4081fb38, fsname=0x0, fsname_len=0x0) [volume.c:780] in KERNEL32.DLL) (ebp=4081f7fc) 3 0x01004012 (PPView97.exe..text+0x3012 in PPView97.exe) (ebp=4081fb48) 4 0x01004c0c (PPView97.exe..text+0x3c0c in PPView97.exe) (ebp=4081fc8c) 5 0x0100577f (PPView97.exe..text+0x477f in PPView97.exe) (ebp=4081fdb0) 6 0x01005970 (PPView97.exe..text+0x4970 in PPView97.exe) (ebp=4081fec4) 7 0x01005aa8 (PPView97.exe..text+0x4aa8 in PPView97.exe) (ebp=4081ff2c) 8 0x404773ca (start_process+0xf2(arg=0x0) [process.c:785] in KERNEL32.DLL) (ebp=4081fff4) 9 0x4002921d (wine_switch_to_stack+0x11 in libwine.so.1) (ebp=00000000)

2 1

Re: Make dlls-kernel-tests-file.c work on Windows 95 and XP.
by Alexandre Julliard April 27, 2004

April 27, 2004

Jakob Eriksson <jakov(a)vmlinux.org> writes: > +static int test_win9x_based() > +{ > + OSVERSIONINFOEX ver; > + > + ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > + ok( GetVersionEx ((OSVERSIONINFO *) &ver), " --- Can't get OS version.\n" ); > + if ((4 == ver.dwMajorVersion && 0 == ver.dwMinorVersion && 1381 == ver.dwBuildNumber) > + || ver.dwMajorVersion >= 5) > + { > + return 0; > + } > + > + return 1; You should not do version checks in tests, the checks should be based on the features we are testing. Otherwise the results are going to depend on the Windows version that Wine is configured for, which is the wrong thing to do since the behavior of the Wine code in that case does not depend on the version. -- Alexandre Julliard julliard(a)winehq.org

2 3

Hmm.. something strange in winetest reporting
by Jakob Eriksson April 26, 2004

April 26, 2004

Check out http://test.winehq.org/data/20040425-1000/ OSR2 shell32:string. It says "0", but if you click, there seems to be some kind of error. Is it the test output somehow erratic, or is the log parser doing something bad? regards, Jakob

2 1

Re: msvcrt: compatibility fixes
by Alexandre Julliard April 26, 2004

April 26, 2004

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > ChangeLog > Fix the _WCHAR_T_DEFINED/_WCHAR_T_DEFINED sentries for > compatibility with the MSVCRT ones. Unfortunately _WCHAR_T_DEFINED is also used by gcc in stddef.h. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: String constification
by Dmitry Timoshkov April 26, 2004

April 26, 2004

"Francois Gouget" <fgouget(a)free.fr> wrote: > We find the same issues with an added twist: now that we can use > literals we can write things like: > > const char* str = "String literal"; > > However this is slightly different from: > > static const char* str[] = "String literal"; > > The difference is that in the first case sizeof(str) returns 4 (on 32 > bit machines<g>) while in the latter we get 15. Some of our code relies > on this so care must be taken when converting the latter to the former. My understanding of this is that in the first case you declare a const pointer and hope that a compiler is smart enough to place a pointed by it object into a read only section, while in the second case you explicitly say to a compiler to place the whole object into a read only section. I prefer to not rely on a compiler's good will. -- Dmitry.

4 5

Re: RPCRT4: make the on-wire protocol Windows compatible
by Steven Edwards April 26, 2004

April 26, 2004

Hiya Filip, You should leave this part out. I dont think Alexandre will remove it for you. +#ifndef __REACTOS__ __TRY { - if (func) func(&msg); + if (func) func(msg); } __EXCEPT(rpc_filter) { /* failure packet was created in rpc_filter */ } __ENDTRY +#else + if (func) func(msg); +#endif Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

Re: Remove debugmsg from guides
by Ivan Leo Murray-Smith April 26, 2004

April 26, 2004

> Please don't do that, we've been over this a thousand times, > let's not rehash it. Do either or, otherwise you end up > confusing Alexandre's script, etc. Inlining is prefered > for a lot of reasons, so if you're using a decent mail client > (and you seem to be), just inline it and don't look back :) I'm not using an email client, my ESP only allows that if I connect via their dial-up service. That's why I can't have text/plain attachments. Ivan.

1 0

Re: Remove debugmsg from guides
by Dimitrie O. Paun April 26, 2004

April 26, 2004

On Mon, 26 Apr 2004, Ivan Leo Murray-Smith wrote: > attaching as text/plain can't be done for various reasons, so I'll both attach > and inline. Please don't do that, we've been over this a thousand times, let's not rehash it. Do either or, otherwise you end up confusing Alexandre's script, etc. Inlining is prefered for a lot of reasons, so if you're using a decent mail client (and you seem to be), just inline it and don't look back :) -- Dimi.

1 0

Re: RFH: RPC patch
by Ivan Leo Murray-Smith April 26, 2004

April 26, 2004

Running server and client with wine CVS current returns Hello Implicit RPC World! but I can't test with your patch because it doesn't cleanly apply against the current CVS code. Ivan.

1 0

service.cgi: script generation
by Dimitrie O. Paun April 26, 2004

April 26, 2004

Currenly we send a script to run and execute all published versions that we have. This is currently problematic, because an error in one causes the abort the entire script. Moreover, releases may no arrive at the server at the same time, and if we're going to receive the poll event in between them, we'll miss some of them. What we need to do is to ask the client to execute one thing at a time. Problem is that we need to keep track of what the client did execute already. Here's a way to do it without storing state on the server side, which is problematic. We need to introduce three new cookies: build_id: the current build ID that we execute. It's going to be something like '200405031000' current: the name of the test that was just executed history: a comma separated list of filenames that where already executed by the client for this current build. It's going to look like so: 'wine-200405031000-paul-mingw.zip,wine-200405031000-kevin-mingw.zip' The algorithm is simple: if $build_id != $current_build_id $build_id = $current_build_id $history = "" else $history = $history . "," . $current $current = pick_next_test($history) # send script to run $current, and to set the values of the # three cookies to the values in our variables where: pick_next_test picks the next test to run from the pool of tests avaiable for our current build, so that it doesn't appear in $history Comments? -- Dimi.

1 0