December 2003 - Wine-Devel - list.winehq.org

Re: new old winetests

by Ferenc Wagner

Alexandre Julliard <julliard(a)winehq.org> writes: > Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > >> #ifdef _WIN32 >> # include <io.h> >> # include <process.h> >> #else >> # include "config.h" >> # include "wine/port.h" >> # define mkdir(d) mkdir (d, 0777) >> #endif > > I'm not sure why you don't want to use the normal > mechanism for that. Well, I did try the method you suggested (cross configuring in a separate build tree), and to my amazement it almost worked without even issuing make in the top directory (I am jumpy to do that on my 200 MHz machine with no free space on the HD). Of course it did not find -lwine and -lwine_port, but did not need them either, so copying the failed linker command from make's output worked after omitting those two libs. This clean and elegant method obviously saves on the number of lines in maketests and Makefile.in, but has a rather big space and time overhead. And, basically, this program belongs to the tests, so why not use the same solution for the same problem again? > I don't think we want to add such #ifdefs to all the > programs. That #ifdef is necessary anyway because of the mkdir() prototype mismatch, I am afraid. And it's only a single program... Having said that, a cross configuring version in the tree is better than three in my hands, but please give this a last consideration before your final decision! Thanks, Feri.

Dec. 1, 2003

Re: Mysterious icon-change

by Jakob Eriksson

On Mon, Dec 01, 2003 at 12:38:19AM +0100, Ivan Leo Murray-Smith wrote: > There is a very simple solution: Don't run winetests.exe from the desktop, and > the desktop icons will stay intact, at least on win2k3. It would be a good idea > to put a warning in the readme and on the download page. Done. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News

Dec. 1, 2003

Question about libwine_unicode functions and others in WINE

by Steven Edwards

Hello, We are looking at porting more code from WINE to ReactOS and I am having trouble understanding the need for libwine_unicode as a shared library. Some of the functions that it exports such as CompareString are implemented in ntdll as RtlCompareString and then also used in shlwapi as per a recent patch. Wouldnt it better to import the function from ntdll and hide libwine_unicode or make the parts that we need to share a static library? In ReactOS we have created NT compatible NLS files. Could WINE do this also and dump libwine_nicode? Also I was looking at the HeapAlloc stuff in WINE and code we have ported from ReactOS such as the FormatMessage function in kernel32. Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc? Can we submit patches to WINE so that everything just calls RtlHeapAlloc so we dont have to change the sources? Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

Dec. 1, 2003