May 2007 - Wine-devel - list.winehq.org

Re: RegDeleteTree [4th] [resend]
by James Hawkins 17 May '07

17 May '07

On 5/17/07, Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > Hello, > > is anything wrong with this patch? > +#if (_WIN32_WINNT >= 0x0600) +LONG WINAPI RegDeleteTreeA(HKEY,LPCSTR); +LONG WINAPI RegDeleteTreeW(HKEY,LPCWSTR); +#define RegDeleteTree WINELIB_NAME_AW(RegDeleteTree) +#endif /* (_WIN32_WINNT >= 0x0600) */ I don't think that's necessary. +static const WCHAR emptyW[] = {0}; You don't use this anywhere. + if (!ret) { You'll save a lot of indentation if you just return on error, for each error. -- James Hawkins

1 0

Re: Direct X 10 game demo
by Tom Spear 17 May '07

17 May '07

On 5/17/07, Michael Lothian <mike(a)fireburn.co.uk> wrote: > In my opinion games will check for DX version on Windows version. > Eventually once enough people have vista they will release DX10 on XP. > Probably about a month before the wine version is ready for XP. > > What do you guys think? Am I just being cynical? I think so. According to everything I have read DX10 is going to be tied in with the low level stuff even more so than DX9 was, and theres a lot of new low-level stuff for it to tie into that was not there with XP.. They would have to backport all of that stuff from Vista to XP, release it as either a Service Pack 3 or as XP Second Edition (groan), and then release DX10 for XP.. Now what they could/might do is offer a scaled down version of DX10 for XP, but there wouldnt be much real benefit over DX9.. Just SM4.0 etc -- Thanks Tom

1 0

debugging problem - winedbg: single stepping until exit from function, which has no line number information
by marcel busse 17 May '07

17 May '07

hello i'm on a project with wine but i can't get it debugged. not even a small hello world. here is the output of the hello world. My system opensuse 10.2 anyone help plz? Winedbg - Output: marcel(a)marcel-laptop-lan:~/prog/m5/m5/debug/src> winedbg m5.exe.so preloader: Warning: failed to reserve range 00000000-60000000 WineDbg starting on pid 000a 0x7b870749: movl %edi,0x0(%esp) Wine-dbg>step Single stepping until exit from function, which has no line number information. Invalid address (0x7b87074e) for breakpoint 0, disabling it Process of pid=000a has terminated Wine-dbg> Code: #ifdef HAVE_CONFIG_H #include <config.h> #endif #include <windows.h> int __stdcall WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) { MessageBox (NULL, "Hello, Windows!", "Hello", MB_OK); int test = 0; test = 1000; test += 100; return 0; } Configure-Output: cd '/home/marcel/prog/m5/m5/debug' && CC="winegcc" CXX="wineg++" LD="ld" CXXFLAGS="-O0 -gdwarf-2 -g3" "/home/marcel/prog/m5/m5/configure" --enable-debug=full checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether wineg++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of wineg++... gcc3 checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... winegcc checking whether we are using the GNU C compiler... yes checking whether winegcc accepts -g... yes checking for winegcc option to accept ISO C89... none needed checking dependency style of winegcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by winegcc... ld checking if the linker (ld) is GNU ld... yes checking for ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... winegcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... wineg++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from winegcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if winegcc supports -fno-rtti -fno-exceptions... no checking for winegcc option to produce PIC... -fPIC checking if winegcc PIC flag -fPIC works... yes checking if winegcc static flag -static works... no checking if winegcc supports -c -o file.o... yes checking whether the winegcc linker (ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by wineg++... ld checking if the linker (ld) is GNU ld... yes checking whether the wineg++ linker (ld) supports shared libraries... yes checking for wineg++ option to produce PIC... -fPIC checking if wineg++ PIC flag -fPIC works... yes checking if wineg++ static flag -static works... no checking if wineg++ supports -c -o file.o... yes checking whether the wineg++ linker (ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands *** Erfolg *** Make Output: cd '/home/marcel/prog/m5/m5/debug/src' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake m5 if wineg++ -DHAVE_CONFIG_H -I. -I/home/marcel/prog/m5/m5/src -I.. -O0 -gdwarf-2 -g3 -MT m5.o -MD -MP -MF ".deps/m5.Tpo" -c -o m5.o /home/marcel/prog/m5/m5/src/m5.cpp; then mv -f ".deps/m5.Tpo" ".deps/m5.Po"; else rm -f ".deps/m5.Tpo"; exit 1; fi /bin/sh ../libtool --tag=CXX --mode=link wineg++ -O0 -gdwarf-2 -g3 -o m5 -mwindows m5.o wineg++ -O0 -gdwarf-2 -g3 -o m5 -mwindows m5.o *** Erfolg *** --------------------------------- Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever.

1 0

Re: hnetcfg: [3/8] uuids for INetFwMgr interface
by Jeff L 17 May '07

17 May '07

For dlls, should the GUID's be put in uuids.h or kept local to the dll. In this case I don't think anything else cares about them, so they could be local. Jeff Latimer Jeff Latimer wrote: > Add public uuids for the interface. > > ------------------------------------------------------------------------ > > diff --git a/include/uuids.h b/include/uuids.h > +OUR_GUID_ENTRY(IID_INetFwMgr, 0xf7898af5, 0xcac4, 0x4632, 0xa2, 0xec, 0xda ,0x06, 0xe5, 0x11, 0x1a, 0xf2) > +OUR_GUID_ENTRY(CLSID_NetFwMgr, 0x304ce942, 0x6e39, 0x40d8, 0x94, 0x3a, 0xb9, 0x13, 0xc4, 0x0c, 0x9c, 0xd4) >

1 0

Re: msxml3 [2/6]: Add initial implementation of IXMLElement
by Alexandre Julliard 17 May '07

17 May '07

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Add initial implementation of IXMLElement. > > dlls/msxml3/Makefile.in | 1 + > dlls/msxml3/msxml_private.h | 2 + > dlls/msxml3/xmlelem.c | 426 ++++++++++++++++++++++++++++++++++++++ > dlls/msxml3/xmlelem_collection.c | 41 ++++- It's suggest to put everything inside xmlelem.c, there's no need to create a new file for every interface. -- Alexandre Julliard julliard(a)winehq.org

1 0

New Gecko package
by Jacek Caban 17 May '07

17 May '07

Hi all, It's time to update our Gecko package. I've prepared a new one. I'd like to avoid any regression, esp. ones that would require changing the package again. That's why I'd like to do a good test. I'm interested in regressions, so just a simple test if app that worked before still works will be fine. To do so download: http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_gecko.tar.bz2 1) if you already have installed Gecko, simply extract the package and replace c:\windows\wine_gecko with it. 2) otherwise extract the package and set GeckoPath variable of HKCU\Software\Winde\MSHTML registry key to its location. Then run an app and check if it still works. Note that you have to use current Git, older Wine is not compatible with the new Gecko. Expected visible difference should be: - Working scrollbars (still not perfect, they will be visible even if app sets it to not be, but it's better than before - I will work on it later) - Pages that require plugins will render like there was no plugin instead of offering downloading one (that doesn't work anyway) >From technical point of view this version differs much from previous one. Previous version was just a SeaMonkey with manually removed and changed some files. This one is my built from source (I will create a page on wiki about how to do so). It's based on XUL Runner 1.8.1.3, which has the same source as Firefox 2.0.0.3. After testing it, I will change Gecko installer a bit to be able to deal with different Gecko versions for different Wine version and upload it to SourceForge. Thanks, Jacek

1 0

Set background image for virtual desktop
by Vijay Kiran Kamuju 17 May '07

17 May '07

Hi, Is it possible to set background image for the virtual desktop in wine? If so how do we set it? (I am bored see same old single color virtual desktop ;) ) Cheers, VJ PS: ----- Any new areas I could work on since d3drm work is complete

2 1

Re: ntoskrnl.exe: Import MSVCRT which we are forwarding to.
by James Hawkins 17 May '07

17 May '07

On 5/17/07, Saulius Krasuckas <saulius.krasuckas(a)ieee.org> wrote: > I am testing "Microsoft Virtual CD-ROM Control Panel" from [*]. It > searches for "msvcrt._local_unwind2" and "msvcrt._except_handler3", but > doesn't find them and then makes stack overflow: > > 000d:trace:loaddll:load_native_dll Loaded module L"Z:\\mnt\\antras\\usr\\src\\wine-git\\VCDxp\\VCdRom.sys" : native > 000d:trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\ntoskrnl.exe" : builtin > 000d:err:module:find_forwarded_export module not found for forward 'msvcrt._local_unwind2' used by L"c:\\windows\\system32\\ntoskrnl.exe" > 000d:err:module:find_forwarded_export module not found for forward 'msvcrt._except_handler3' used by L"c:\\windows\\system32\\ntoskrnl.exe" > 000d:trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\hal.dll" : builtin > 000d:trace:process:set_entry_point setting FT_Thunk at 0x7b8ac080 to 00000000 > 000d:trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin > 000d:trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin > 000d:trace:ntoskrnl:IoCreateDevice (0x7ffdf000, 48, L"\\Device\\VirtualCdRom", 2, 3, 0, 0x34fee8) > wine: Call from 0x7b840d20 to unimplemented function ntoskrnl.exe.ExAllocatePoolWithTag, aborting > wine: Call from 0x7bc56dd5 to unimplemented function ntoskrnl.exe._except_handler3, aborting > wine: Call from 0x7bc56dd5 to unimplemented function ntoskrnl.exe._except_handler3, aborting > wine: Call from 0x7bc56dd5 to unimplemented function ntoskrnl.exe._except_handler3, aborting > ... > > Could that be a simple typo in Makefile.in? > > This is from bug 8408: ------- Additional Comments From julliard(a)winehq.com 2007-16-05 12:17 ------- That stuff is not supposed to work yet. ntoskrnl needs to be loaded from a service process that will take care of importing msvcrt. Currently the driver is executed directly which cannot work. -- James Hawkins

1 0

Re: ntoskrnl.exe: Import MSVCRT which we are forwarding to.
by Alexandre Julliard 17 May '07

17 May '07

Saulius Krasuckas <saulius.krasuckas(a)ieee.org> writes: > Could that be a simple typo in Makefile.in? No, it's deliberate. Importing msvcrt here will cause lots of trouble, it will be imported in the process that loads the driver. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntoskrnl.exe: Implemented IoCreateSymbolicLink
by Vitaliy Margolen 17 May '07

17 May '07

Alexandre Julliard wrote: > + attr.Attributes = OBJ_CASE_INSENSITIVE | OBJ_OPENIF; > + attr.SecurityDescriptor = NULL; > + attr.SecurityQualityOfService = NULL; > + > + TRACE( "%s -> %s\n", debugstr_us(name), debugstr_us(target) ); > + /* FIXME: store handle somewhere */ > + return NtCreateSymbolicLinkObject( &handle, SYMBOLIC_LINK_ALL_ACCESS, &attr, target ); How are you planning on removing them if you don't keep a handle to this symlink? Also why OBJ_CASE_INSENSITIVE? This is kernel, and last time I've checked NT kernel's name space was case-sensitive. Vitaliy.

2 1