February 2005 - Wine-Devel - list.winehq.org

riched20 patch preview

by Krzysztof Foltman

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

Feb. 27, 2005

Re: vartest.c - major pain in the build process

by Dmitry Timoshkov

"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.

Feb. 27, 2005

Re: vartest.c - major pain in the build process

by Dmitry Timoshkov

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > Also, that won't stop people from running winetest on linux, I'll bet > $5 winetest.exe downloads from WRT will keep showing up. I'd actually rise the question of sending the results of running winetest on an invisible desktop under Windows. For instance I'm interested to see how my recently added user32 tests behave on different Windows platforms, but the tests which currently present on http://test.winehq.org/data are completely unusable. I strongly ask to stop posing tests running on an invisible desktop and consider that tests broken, since almost all win32 APIs are influenced by the fact of running in that environment. Moreover, Wine doesn't run in that mode at all, so we can't compare apples to apples in that case. And the apps most of the developers/users care about should be run on a visible desktop anyway. > That said, maybe winetest should not build by default. That > doesn't sound like a lot of fun. Alexandre already stated many times that there is no point to have anything in the CVS tree if it's not compiled by default. A not used code tends to be rotten very fast. -- Dmitry.

Feb. 27, 2005

Re: Problem using winelib to compile Std Lib strings

by Boaz Harrosh

Rob D wrote: > > The files I cant seem to compile are ones that use std string. > > If you are using msvcrt, You cannot use native g++ std with Winelib. In this case you'll need to grab STLPort. And hack on it to compile over wine & msvcrt headers. This is for two reason. 1- The headers are incompatible (Headers separation is really bad especially gcc's) 2. you'll have a risk of runtime memory corruption, as programmers usually mix between allocation methods. So you'll have some buffers allocated in Wine system that try to released on g++ heap and vis versa. If you want I can package for you an OLD STLPort. The dynamic Libraries you will not be able to use as it uses a very old wine build. But you should be able to compile and use the static libraries. > 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. > Yes this is very important! If they're used to Windows MSDEV. they might like KDevelop3, and the debugger is also nice for Winelib. You do have KDE libs for Sun right??? Free life Boaz

Feb. 27, 2005

Re: winedbg hanging

by Alex Woods

On Sat, Feb 26, 2005 at 09:00:04PM +0000, Alex Woods wrote: > 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? It was a bit of both. There is a dbghelp.dll in the apps directory. I'm off to wallow in shame. Later ;) -- Alex

Feb. 26, 2005

Re: vartest.c - major pain in the build process

by Krzysztof Foltman

Jakob Eriksson wrote: > Also, that won't stop people from running winetest on linux, I'll bet > $5 winetest.exe downloads from WRT will keep showing up. Yes. But should something that's useless for the majority of users and developers be enabled by default ? Looks like significant cost with little benefit. > That said, maybe winetest should not build by default. That > doesn't sound like a lot of fun. Sounds like a good idea. And, by the way, a configure switch to disable all the DirectX modules would be nice too. One doesn't need DirectX to run business software. Or to work on a non-multimedia control like RichEdit20 ;) Or, maybe, a switch to skip building particular DLLs. Krzysztof

Feb. 26, 2005

winedbg hanging

by Alex Woods

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

Feb. 26, 2005

Re: MSVCRT: Generating relay stubs for libc forwards/varargs

by Jon Griffiths

> For the varargs and libc-forwarded function in msvcrt, I think all > that we > need is already in out spec file. So no need for the MS SDK. If you want to write the tracing code by hand, yes. If you have the headers winedump will generate the TRACE() statements for you as well. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

Feb. 26, 2005

Re: MSVCRT: Generating relay stubs for libc forwards/varargs

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > in msvcrt a lot of functions are of type vararg (e.g. printf) or are > forwards into the Linux libc (e.g. strstr) and so leave no trace in a +relay > log. This makes it harder to debug. The forwards into libc show up in relay just fine, they are not different from other functions. The varargs one can't since we have no idea how much stack to copy, but what you can do is add some traces in the function itself. -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2005

Re: vartest.c - major pain in the build process

by Jakob Eriksson

Mike Hearn wrote: >I disable winetest in my tree entirely, and have done for a long time. It >should be disabled in CVS as well, nobody should be building winetest on >Linux, it just encourages people to submit useless results by saying "oooh >I wonder what happens if I do this". Worse this isn't just about it taking > > Actually there may be some value in running winetest on Linux. [*] Also, that won't stop people from running winetest on linux, I'll bet $5 winetest.exe downloads from WRT will keep showing up. * - We not only get statistics of how the Windows API works. We also get coverage of how well Wine is implemented in the wild, with different versions of Linux. >too long, on my machine attempting to compile winetest actually crushes >it totally. It descends into swap hell and never seems to re-emerge. > > That said, maybe winetest should not build by default. That doesn't sound like a lot of fun. regards, Jakob

Feb. 26, 2005