- Wine-Devel - list.winehq.org

Re: [PATCH] Added 2 functions to shell32
by Dmitry Timoshkov Feb. 28, 2005

Feb. 28, 2005

"Gianluigi Tiesi" <sherpya(a)netfarm.it> wrote: > +BOOL WINAPI PathIsEqualOrSubFolder(LPCWSTR path1, LPCWSTR path2) > +{ > + int i; > + int len; > + if (!path1 || !path2) return FALSE; > + > + len = strlenW(path1); > + if (len > strlenW(path2)) return FALSE; > + > + for (i=0; i < len; i++) > + if (path1[i] != path2[i]) return FALSE; > + return TRUE; > +} You need to do a case insensitive comparison of paths. Also, if you could use a usual for Wine formatting style with 4 space indentation that would be very nice. -- Dmitry.

2 1

Re: comctl32 - SB_SETBORDERS
by Thomas Weidenmueller Feb. 28, 2005

Feb. 28, 2005

Steven Edwards wrote: >Filip implemented this for me when I was testing Office97 under ReactOS and I never got around to >merging it to the ros tree. > > SB_SETBORDERS does not exist in current versions of NT. It might be a something from the old 3.x days. NT 5.0 and 5.1 for sure don't implement them. Even though Office tries to use them I oppose implementing it. Best Regards, Thomas

2 2

status of winetest.exe
by Stefan Leichter Feb. 28, 2005

Feb. 28, 2005

Hello Paul, i have noticed that the winetest are not longer built since the middle of the week. Can you take a look if something is broken? Thanks Stefan

2 1

Re: shell32: formatting and unicodification
by Alexandre Julliard Feb. 27, 2005

Feb. 27, 2005

Juan Lang <juan_lang(a)yahoo.com> writes: > Mike's formatting changes got in, so here's one of my own. > > ChangeLog: convert tabs to spaces, make indenting consistent, convert more > calls to Unicode Please don't mix formatting changes with other things, it makes it very painful to review. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: setupapi: enumerate serial ports
by Alexandre Julliard Feb. 27, 2005

Feb. 27, 2005

Juan Lang <juan_lang(a)yahoo.com> writes: > + /* FIXME: it should be possible for more than four COM ports to exist, not > + * sure why we retain that limit, but winspool does too so go with it. > + */ > + for (i = 0, ret = 0; i < 4; i++) > + { > + if (SETUP_SerialPortExists(i)) > + ret++; > + } There's no reason to limit to 4 serial ports (and winspool should be fixed too). Probably the best way is to do a QueryDosDevice(NULL) which gets you a full device list and the return every COM device in that list. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Fix a race condtition in the server startup
by Bill Medland Feb. 27, 2005

Feb. 27, 2005

On February 26, 2005 03:43 pm, Francois Gouget wrote: > There is a race condition in the server startup code which arises if two > I propose the following fix: > > if (lstat( name, st ) == -1) > { > if (errno != ENOENT) fatal_perror( "lstat %s", name ); > if (mkdir( name, 0700 ) == -1 && errno != EEXIST) fatal_perror( > "mkdir %s", name ); > > Using the existing directory is ok because we then check its ownership, > permissions, etc. (which we have to do anyway in case it already existed). How about simply mkdir and if the error is already existed then fine.? Unchecked, but something like: if (mkdir (name, 0700) == -1) { if (errno != EEXIST) fatal_perror ("Ensuring directory %s", name) } > > > Changelog: > > * server/request.c > > Francois Gouget <fgouget(a)codeweavers.com> > Fix a race condition in create_dir(). -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

riched20 patch preview
by Krzysztof Foltman Feb. 27, 2005

Feb. 27, 2005

I've finally managed to make my riched20 code usable (hardly) and compatible with Wine. It's probably not good enough to go to CVS, but, at least, it's something you can try out. Comments are welcome. It should work with all programs that load RICHED20.DLL directly. For programs that load RICHED32.DLL you need a native version of that DLL (which is a wrapper for RICHED20.DLL, providing compatibility with 1.0 version of the control, the most important thing it does is loading RICHED20.DLL, which registers 2.0 window classes). http://foltman.com/riched20.tar.gz http://foltman.com/richeditpatch.diff Note, that EM_STREAMIN and EM_STREAMOUT don't work, so if your program uses RTF to insert text to the control, it won't work ! WinXP WordPad doesn't work either, as it uses RICHEDIT50W window class (what I provide is RichEdit20W control, haven't tried to fake it's 5.0). Have fun! Krzysztof

1 1

Re: vartest.c - major pain in the build process
by Dmitry Timoshkov Feb. 27, 2005

Feb. 27, 2005

"Krzysztof Foltman" <kfoltman(a)portal.onet.pl> wrote: > > Well, I'd argue that compilation time of full Wine tree is much longer > > than that single test. If you compile from source it's your choice. > > It's still an important percentage of the total compile time. And it's > not always possible to use binaries - particularly I'm not the best > candidate for that option, being a Wine hacker ;-) Then perhaps it's better to upgrade your hw/compiler/etc, or somehow schedule your development time to compile Wine while you are doing something else. > > Even more drastic route to go is to go and complain to gcc people, > > that's certainly not a Wine fault. > > Well, almost no other program triggers this misbehaviour, so it might be > useful to work around that bug. It's a very dubious statement. I'm certain that this is not a Wine bug since compiling that code with MSVC compiler works several times faster. > Or disable the test by default > completely. It could save hundreds of users from hours of wasted time. Ordinary users are not supposed to compile the code intented for developers only. > Looks like a pragmatic solution. It's not Wine's fault, but it's not the > user's fault either, so why punish him for gcc bugs if it's not necessary? Sure, that's why we have already compiled binaries for download. > It's a bit awkward to require everyone to upgrade a monster like gcc in > order to speed up a several minute long (10 minutes and more) > compilation of the module that has little use for most users and even > developers. Then just disable the code you don't want to compile in your tree before building Wine. Just do it locally, and not ask everybody to follow your preferences. -- Dmitry.

1 0

Problem using winelib to compile Std Lib strings
by Rob D Feb. 27, 2005

Feb. 27, 2005

Ive undertaken the task of converting 2 rather large Win32 applications to run on Solaris 10. I have managed to tweak nearly all of the files so they will compile with wine after running winemaker. The files I cant seem to compile are ones that use std string. I get a few errors like the following: error: ::div has not been declared error: ::ldiv has not been declared And tons about /usr/include/pthread.h like the following: error: uintptr_t does not name a type error: caddr_t has not been declared error: caddr_t does not name a type error: pthread_attr_t was not declared in this scope The files in question have lines like the following: #include <string> using namespace std; Ive tried including various additional header files like <sys/types.h> and <dtrace/h>, with varying success, but still approx 200 errors when trying to compile these files. The error lines say they are from include/c++/3.4.2, so Im assuming that it is using the 3.4.2 compiler as opposed to the 2.95 one also installed on these machines. The development Ive been tasked with will move several people off of winblows machines and onto Solaris 10 if I can succeed, so it is even more critical in my mind to get this to work. Rob

2 1

winedbg hanging
by Alex Woods Feb. 26, 2005

Feb. 26, 2005

Hello, When I try to run winedbg with the --gdb option, it simply hangs. I've tracked this down to dbg_get_debuggee_info returning false and then everything falling through to a wait(NULL). The callback that is getting passed SymEnumerateModules doesn't seem to be getting called at all. I've put traces into the SymEnumerateModules but they aren't spitting anything out. Here is the function getting called though: 0035:CALL dbghelp.SymEnumerateModules(<unknown, check return>(0x558b0000,00000002,00000040): returning 558c5de8) ret=55b1f6be 0035:RET dbghelp.SymEnumerateModules(0000003c,55b1f590,55c3f4b0) retval=00000001 ret=55b1f6be0 I'm not I believe that it is getting called, at least not the one in dbghelp/module.c. I've stuck an exit at the top of it, and it doesn't. I've noticed a SymEnumerateModules64 that is just a stub, and that's made me suspicious because I'm running a multilib compiled wine on an x86_64 platform. Also, could that be a problem, since gdb is compiled as 64-bit? I'm pretty sure I'm either being dense, or something is happening that I'm not aware of. Could someone point out which, please? ;) Cheers. -- Alex

1 1