- wine-devel - winehq.org

DCOM (was Re: Fix CoMarshalInterThreadInterfaceInStream)
by Robert Shearman 01 Jun '04

01 Jun '04

On Sat, 2004-05-29 at 00:44, Mike Hearn wrote: > Of course calling CoMarshalInterface in this case doesn't actually do > much, but if it helps InstallShield OK. Actually, it does. It appears as though the interface marshaling functions are all compatible with each other on Windows (even though MSDN says that they aren't and then says they use the same code as the others). Presumably InstallShield was quite understandably passing the IStream from on the two functions that were fixed into one of the other (supposedly compatible) functions and then that function failed because it wasn't the right format. Even on Wine, those other functions, such as CoMarshalInterface do actually attempt to get a marshaller or just use the standard one and > If you are interested in this > stuff I'd say trying to merge the TransGaming patch would be a good > start. I assume you mean this: http://www.winehq.com/hypermail/wine-devel/2003/07/att-0179/01-ole.diff__ch… I've had a look at what is in there. The way I interpret it, there are a couple of sections: o Auto-generated marshaling code -- this is fine to be included in Wine and could probably be done so at any point o Converting COM (ole32) to using RPC -- as you can see by the comments in the code, this isn't really done through the correct interfaces yet (and this is stuff that you only want implement once) and hence I'm not confident that the related stuff is done correctly. There are useful bits, but I doubt I will use all of that code. o Rewriting the Type Library marshaller -- this isn't much better than the code we have at the moment. Again, this isn't done through the correct interfaces - I would prefer to use the stubless RPC to do the same, but it would probably mean writing half of MIDL into RPCRT4. o Miscellaneous header and bug fixes -- I'll check whether they are included in Wine already and check whether they are correct or workarounds for something in the patch > This includes a lot of what you've done lately such as proper > apartments, proper inter-thread marshalling and so on. Otherwise the > codebase drift is going to get even worse :( I would prefer it if we could all work on the same codebase, but as you know the licensing restrictions largely prevent that. I hope (wish?) that Transgaming will use more and more LGPL modules from Wine and only develop separately the ones that are core to their business. They have been kind of informally doing that by submitting their RPC / OLE patches back to Wine, but they are working from the ReWind codebase, not Wine and they are not in sync. Rob P.S. I am currently putting together a plan for tackling RPC / DCOM and will present it to wine-devel soon.

2 4

Re: Various MDI children activation fixes
by Dmitry Timoshkov 01 Jun '04

01 Jun '04

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > I'm also attaching latest cersion of my MDI tool which I'm using > for all MDI related investigations, perhaps it will be useful for > somebody else. Here it is. -- Dmitry.

1 0

Current Wine CVS status
by Dmitry Timoshkov 01 Jun '04

01 Jun '04

Hello all (mostly Alexandre :-)), running today's ~/wine/wine under an old RH 6.2 install I get the following: Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we get handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RPATH information in object names in LIST -- Dmitry.

2 2

Re: Wine bug with delphi Menus
by Robert van Herk 01 Jun '04

01 Jun '04

Dan Kegel wrote: > Please do put the source and executable of your demo > app online at some web page, and post the URL on wine-devel. Okay, please feel free to grab it from http://www.students.cs.uu.nl/people/rherk/DelphiMenuTest.tar.gz . Greetings, Robert P.S. Hope I got the bonus :-P

1 0

broken mingw build
by Kevin Koltzau 01 Jun '04

01 Jun '04

This patch http://cvs.winehq.org/patch.py?id=12495 seems to have broken the mingw build, currently getting i386-mingw32msvc-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c {standard input}: Assembler messages: {standard input}:124: Error: unknown pseudo-op: `.previous' {standard input}:135: Error: unknown pseudo-op: `.previous' {standard input}:145: Error: unknown pseudo-op: `.previous' {standard input}:155: Error: unknown pseudo-op: `.previous' {standard input}:165: Error: unknown pseudo-op: `.previous' make[2]: *** [interlocked.o] Error 1

3 2

Re: Use TRACE rather than FIXME for check_resource_write
by Dmitry Timoshkov 01 Jun '04

01 Jun '04

[forgot to cc wine-devel] "Mike Hearn" <mh(a)codeweavers.com> wrote: > No need for this to be a fixme, we can't fix broken apps anyway and it > just confuses people. > > Mike Hearn <mh(a)codeweavers.com> > Use TRACE rather than FIXME for check_resource_write I have found and fixed at least one bug in Wine itself thanks to this fixme message. -- Dmitry.

1 0

Re: [DInput] Fix RailroadTycoon
by Christian Costa 31 May '04

31 May '04

Lionel Ulmer wrote: >Sorry for the huge diff, but I got sick when I saw my previous 2-space >indenting style, so I had to re-indent everything... For people who want to >do a code review, I could send them a 'diff -w' version :-) > Now, you're proposing, that would be cool. :-) > >And before anyone complains, yeah, I should have sent two patches (one >cosmetic, one with the real meat in it) :-) > > Lionel > >Changelog: > - some TRACEing improvements > - fix mouse Acquire which switched right and middle buttons > - reset the mouse cursor at its original location on Unacquiring the device > > > > > Bye, Christian

2 2

Making a system DLL unavailable (problem with COMMCTRL)
by Samuel Audet 31 May '04

31 May '04

Hello, I have a Windows 3.1 application here that uses the OWL library. I have problems running it properly, and I have found the following: http://www.xploiter.com/programming/c/borland/3031.html Looking at what wine outputs when I use "WINEDEBUG=dll" or loaddll, I see that my program tries to load commctrl.dll and always succeeds. The problem is, I want it not to succeed, since AFAIK, 16 bit COMMCTRL functionality is not implemented in WINE, and the OWL library has a backup plan where it emulates some of the controls (like described on the site above) when it can't find COMMCTRL, which is what it does in Windows 2000 or XP for example. I have confirmed that the COMMCTRL is at the source of the problem by using one from a Windows 98 installation. Dialogs that are not showing using WINE's builtin COMMCTRL are now showing (although they are having sizing problems... anybody might know why?). Is there like a "disable" option in the [DllOverrides] section? Or some other way to disable a system DLL? I can't seem to just be able to "remove" commctrl.dll since even 32 bits builtin DLL (in this case comctl32.dll) require the 16 bit counterpart. In this case, when comdlg32 tries to load, it loads comctl32 and fails because it can't load commctrl. I don't think it's a good idea to make 32 bits DLL be dependent of their 16 bit counterpart. Thank for any input! -- Samuel Audet <guardia(a)step.polymtl.ca> http://www.step.polymtl.ca/~guardia/

3 5

Using objdump
by James Courtier-Dutton 31 May '04

31 May '04

I have used objdump in the past to disassemble and check the code that is generated in a .so or .o file. How do I modify objdump so I can get it do the same with win32 .exe and .dll files ? Cheers James

4 4

Crash due to _fini
by Rajeev Bansal 31 May '04

31 May '04

Hi i am trying to link wine library(msvcrt.dll.so) with my code but i getting segv in _fini call of msvcrt library Please tell me a way so that i can use wine libraries directly without winegcc or specs file on using winegcc for code which contains new and delete operator it gives undefined reference to following symbols operator new(unsigned) operator delete[](void*) _Unwind_Resume __gxx_personality_v0 please help me to resolve above symbols waiting for response Thanks Rajeev Test Program : #include <dlfcn.h> #include <direct.h> #include <math.h> #include <stdio.h> main() { char *a; char *b; double d; void *mod, *ker; const char *error; mod=dlopen("msvcrt.dll.so",RTLD_LAZY); ker=dlopen("kernel32.dll.so",RTLD_LAZY); if(mod) { if ((error = dlerror())) { printf("Couldn't find getcwd: %s\n", error); } if(dlsym(mod, "getcwd")){ printf("found"); b=getcwd(a,20); } dlclose(mod); dlclose(ker); } //end if return (0); } //end main Build command : g++ -g -Wall -c -I/home/timex/wine/wine-20040505/include -I. -I/home/timex/wine/wine-20040505/include/msvcrt test.cpp g++ -g -ldl /home/timex/wine/wine-20040505/dlls/msvcrt.dll.so test.o Debugger output [me@cvs TUCP]$ gdb -n GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". (gdb) file ./a.out Reading symbols from ./a.out...done. (gdb) break test.cpp:10 Breakpoint 1 at 0x80486cc: file test.cpp, line 10. (gdb) run Starting program: /home/a.out Breakpoint 1, main () at test.cpp:14 14 mod=dlopen("msvcrt.dll.so",RTLD_LAZY); (gdb) next 15 ker=dlopen("kernel32.dll.so",RTLD_LAZY); (gdb) disp mod 1: mod = (void *) 0x40013578 (gdb) disp ker 2: ker = (void *) 0x4026cc40 (gdb) next 16 if(mod) 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) next 19 if(dlsym(mod, "getcwd")) 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) next 20 {printf("found"); 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) next 21 b=getcwd(a,20); 2: ker = (void *) 0x8049b60 1: mod = (void *) 0x40013578 (gdb) step getcwd (buf=0x4026cc40 "T\v\022", size=20) at direct.h:73 73 static inline char* getcwd(char * buf, int size) { return _getcwd(buf, size); } (gdb) step _getcwd (buf=0x4026cc40 "T\v\022", size=20) at dir.c:424 424 int dir_len = GetCurrentDirectoryA(MAX_PATH,dir); Current language: auto; currently c (gdb) step 422 { (gdb) step 424 int dir_len = GetCurrentDirectoryA(MAX_PATH,dir); (gdb) step 422 { (gdb) step 424 int dir_len = GetCurrentDirectoryA(MAX_PATH,dir); (gdb) step Program received signal SIGTRAP, Trace/breakpoint trap. 0x40062179 in _fini () from /home/timex/wine/wine-20040505/dlls/msvcrt.dll.so (gdb) bt #0 0x40062179 in _fini () from /home/timex/wine/wine-20040505/dlls/msvcrt.dll.so #1 0x08048790 in getcwd (buf=0x4026cc40 "T\v\022", size=20) at direct.h:73 #2 0x08048730 in main () at test.cpp:21 #3 0x40161b84 in __libc_start_main () from /lib/libc.so.6 (gdb) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/24/2004

2 1

segfault fault at startup
by Florian Goth 31 May '04

31 May '04

H! I have the same Problem. I get a segfault, when I do "wine myapp" and when I do "wine-pthread" I'm using a SuSE System ( ~ 9.0 ) with kernel 2.6.6 and gcc 3.4.0 this is the gdb output: (gdb) set follow-fork-mode child (gdb) r Starting program: /usr/local/bin/wine [New Thread 16384 (LWP 5206)] [New Thread 32769 (LWP 5209)] [New Thread 16386 (LWP 5210)] Cannot find user-level thread for LWP 5206: generic error (gdb) this is some of the last strace output I get: t_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 writev(4, [{"$\0\0\0002\0\0\0\0\0\0\0\0\0\0\200\0\0\0\0\1\0\0\0\1\0"..., 64}, {"/home/sifff/.wine/dosdevices/c:/"..., 50}], 2) = 114 read(5, "\0\0\0\0\0\0\0\0000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0A\0\0\0\5\0\17\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "I\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0000M\0A\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "&\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\377\377\377\377\1\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"4\0\0\0", 4}], msg_controllen=16, msg_control=0xbfffab68, , msg_flags=0}, 0) = 4 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\26\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\t\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(9) = 10 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "&\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\t\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 dup(9) = 11 fstat64(11, {st_mode=S_IFREG|0755, st_size=5054496, ...}) = 0 fstatfs(11, {f_type="MSDOS_SUPER_MAGIC", f_bsize=4096, f_blocks=358741, f_bfree=57991, f_files=0, f_ffree=0, f_namelen=260}) = 0 close(11) = 0 mmap2(NULL, 5124096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40860000 munmap(0x40d33000, 65536) = 0 mmap2(0x40860000, 5058560, PROT_READ, MAP_PRIVATE|MAP_FIXED, 10, 0) = 0x40860000 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\27\0\0\0\0\0\0\0\0\0\0\0\377\377\377\3774\0\0\0\377\377"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0008\0\0\0\377\377\377\377\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(10) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 write(4, "\25\0\0\0\0\0\0\0\0\0\0\0004\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 read(5, "\0\0\0\0\0\0\0\0\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 close(9) = 0 getpid() = 5154 open("/tmp/reg14220000.tmp", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9 fcntl64(9, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) fstat64(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d33000 _llseek(9, 0, [0], SEEK_CUR) = 0 brk(0) = 0x7800a000 brk(0x7800b000) = 0x7800b000 write(9, "WINE REGISTRY Version 2\n[MIME\\\\D"..., 131072) = 131072 write(9, "trolSet\\\\Control\\\\DeviceClasses\\"..., 131072) = 131072 write(9, "&PID_0095&INST_0\"\n\"RefCount\"=dwo"..., 131072) = 131072 write(9, "ixer f\\xfcr Aureon 5.1 Fun\"\n\n[Sy"..., 131072) = 131072 write(9, "0,00,00,00,00,00,00,00,00,00,00,"..., 131072) = 131072 write(9, "stem\\\\CurrentControlSet\\\\Service"..., 131072) = 131072 brk(0) = 0x7800b000 brk(0x7800c000) = 0x7800c000 brk(0) = 0x7800c000 brk(0x7800d000) = 0x7800d000 brk(0) = 0x7800d000 brk(0x7800e000) = 0x7800e000 brk(0) = 0x7800e000 brk(0x7800f000) = 0x7800f000 brk(0) = 0x7800f000 brk(0x78010000) = 0x78010000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Thanks, Flo

1 0

segfault fault at startup
by terra＠gnome.org 31 May '04

31 May '04

A newly built wine segfaults for me. No args: welinder@anemone:~/wine> ./wine Segmentation fault No core. gdb just reports: welinder@anemone:~/wine> LD_LIBRARY_PATH=/home/welinder/wine/libs/wine gdb loader/wine ... (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 28622)] [New Thread 32769 (LWP 28624)] [New Thread 16386 (LWP 28625)] Cannot find user-level thread for LWP 28622: generic error This is with a suse 9.0 system. Ideas? Morten

4 4

Re: segfault fault at startup
by terra＠gnome.org 31 May '04

31 May '04

No change with 'set follow-fork-mode child', or even '... ask'. With strace, I get... strace -i $WINELOADER [...] [40113d71] close(9) = 0 [400f0c37] getpid() = 30133 [40113ce3] open("/tmp/reg75b50000.tmp", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 9 [401140b8] fcntl64(9, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) [40112dcb] fstat64(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 [4011e6ed] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40032000 [40121ce7] _llseek(9, 0, [0], SEEK_CUR) = 0 [400b7fdc] --- SIGSEGV (Segmentation fault) @ 0 (0) --- upeek: ptrace(PTRACE_PEEKUSER,30133,48,0): No such process [????????] +++ killed by SIGSEGV +++ Hmm... welinder@anemone:~/wine> printenv | grep WINE WINESERVER=/home/welinder/wine/server/wineserver WINELOADER=/home/welinder/wine/loader/wine WINEDLLPATH=/home/welinder/wine/dlls:/home/welinder/wine/programs:/home/welinder/wine/dlls:/home/welinder/wine/programs welinder@anemone:~/wine> gdb $WINELOADER GNU gdb 5.3.92 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... (gdb) tb main Breakpoint 1 at 0x8048857: file glibc.c, line 76. (gdb) r Starting program: /home/welinder/wine/loader/wine [New Thread 16384 (LWP 30150)] [Switching to Thread 16384 (LWP 30150)] main (argc=1, argv=0xbffff414) at glibc.c:76 76 const char *loader = getenv( "WINELOADER" ); (gdb) info symbol 0x400b7fdc nl_langinfo + 60 in section .text (I'm not sure I believe that) Morten

1 0

Help with winedbg
by Shachar Shemesh 30 May '04

30 May '04

Hi, I'm trying to get a Visual C compiled program to run on Wine. I have the sources and full debug info for the PE part of the program. Obviously, however, it was not compiled on the same machine on which it is running. To make things even more interesting, I would rather use some GUI frontend for the debugger. As far as I can tell, I have two options to go about this: 1. Use Visual Studio's remote debugging 2. Use winedbg as a gdb backend for ddd Option 1 fails miserably. I suspect the project is just too complex for Visual Studio to handle over the wire. When I try to do that, the Visual Studio front end (the one running on a Windows machine) crashes. This leaves me with just option 2. When I try to run it like that (winedbg --gdb --no-start), winedbg starts ok. When I hook ddd to it, however, winedbg complains about a missing source file (one that is not in the Windows source, btw). In the mean while, ddd claims to time out on the connection, and closes down. Am I missing something? Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/

2 7

Tainted code in User32?
by Steven Edwards 30 May '04

30 May '04

Hello this line: "However, disassembling NT implementation (WIN32K.SYS) reveals that........." in http://source.winehq.org/source/windows/win.c#L845 was introduced in to winehq by the following patch: http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61&r2=1.62 Does this not violate a clean rooming the implementation? The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it. Thanks Steven __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

4 3

Re: EnumDateFormats patch
by Alexandre Julliard 29 May '04

29 May '04

Wililam <computerman413(a)ezrs.com> writes: > Here is the ChangeLog entry: > > * dlls/kernel/lcformat.c > William Lahti <computerman413(a)ezrs.com> > > - Implemented the EnumDateFormatsW function and vastly improved upon the > EnumDateFormatsA function. This stuff clearly needs to be stored as data in the nls resource files, not in the code. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [Fwd: winetest: copy and submit manually]
by Dimitrie O. Paun 29 May '04

29 May '04

On Fri, May 28, 2004 at 07:42:54AM -0400, Robert Reif wrote: > It appears that the locale.c test on line 1866 and 1867 fail a lot > (0xffff?). Can you try to see why this happens on your box? > File too big (# > 1 MB), copy and submit manually > > where # is around 8 meg. Yeah, there's no point in submitting such a large file, it will be rejected by the server. The message about submitting manually is confusing, it should be 'this is a problem, please report (and investigate, if at all possible :))' -- Dimi.

2 1

Re: Print thread ID in 16-bit snoop traces in the noargs case
by Rein Klazes 29 May '04

29 May '04

On Fri May 28 23:42:14 BST 2004, you wrote: > Mike Hearn <mh(a)codeweavers.com> > Print thread ID in 16-bit snoop traces in the noargs case Too late: http://cvs.winehq.org/patch.py?id=12478 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Upcoming breakage warning
by Mike Hearn 29 May '04

29 May '04

Hi, On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation. Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area. This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it. There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this: wine: unable to create process heap Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes. thanks -mike

4 5

Re: wine/ loader/main.c loader/glibc.c loader/Make ...
by Mike Hearn 29 May '04

29 May '04

On Fri, 28 May 2004 15:59:23 -0500, Alexandre Julliard wrote: > Log message: > Initial version of the Wine preloader, used to reserve memory > areas at startup. Based on the work of Mike McCormack. For those who haven't been following the execshield/prelink saga, this commit is the result of the various prototypes and patches that were posted to wine-devel since we got back from WineConf. The result of it should be that we no longer need to switch off execshield nor prelink in order to run Wine reliably, also the huge BSS array hack is also no longer needed. Binaries of every size should work. Combined with the patch Alexandre checked in a few days ago to do an iterative binary search of the upper 2gig of address space, we should now also be functional when the 4G/4G VM split is enabled. It could use some testing! Please update to latest CVS and run wine as you would normally. If you are on a prelink/execshield enabled system, make sure they are both switched on and that prelink is using exec-shield mode (should be by default). If you observe any odd breakage please let us know. keep on truckin' -mike

3 3

Re: Fix CoMarshalInterThreadInterfaceInStream
by Mike Hearn 29 May '04

29 May '04

( again wishing pan respected reply-to fields ... ) On Sat, 29 May 2004 00:33:24 +0100, Robert Shearman wrote: > This patch fixes CoMarshalInterThreadInterfaceInStream and > CoGetInterfaceAndReleaseStream to match what MSDN says - calling > CoMarshalInterface and CoUnmarshalInterface respectively. Without this > patch a particular InstallShield installer would just hang. With this > patch it gets a bit further (to an unimplemented function). Calling CoMarshalInterface in this case doesn't actually do much, but if it helps InstallShield OK. If you are interested in this stuff I'd say trying to merge the TransGaming patch would be a good start. This includes a lot of what you've done lately such as proper apartments, proper inter-thread marshalling and so on. Otherwise the codebase drift is going to get even worse :( thanks -mike

1 0

Re: EnableWindow
by Alexandre Julliard 29 May '04

29 May '04

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > EnableWindow should not remove the focus of child windows Thanks for providing a test, but could you please merge it with the existing win.c and/or msg.c tests? We can't create a new file for every API being tested. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Unsupported feature in SHFileOperationW
by Phillip.Ezolt＠hp.com 28 May '04

28 May '04

Hi all, Here is patch for the SHFileOperationW problem. (Which I originally sent out in January. ) It isn't perfect, and it fixes the problem for my application. (which happens to be the same as Lionel's) According to Lionel the fix is better than what is there today, but it falls short of windows behavior in the following manner (for the record): > But it's not 100 % correct as, for example, it does not work if one needs to > create more than one level of directories (which is working fine in Windows, > I just checked it). Moreover, there should be a message box (if not disabled > like in RollerCoasterTycoon) asking if the users wants or not to create the > directory (I checked this on Windows too). --Phil Hewlett-Packard: High Performance Technical Computing/Visualization --------------------------------------------------------------------------- Phillip.Ezolt(a)hp.com Performance/Development ---------- Forwarded message ---------- Date: Fri, 30 Jan 2004 12:54:48 -0500 (EST) From: Phillip Ezolt <phillip.ezolt(a)hp.com> To: wine-patches(a)winehq.org Subject: SHFileOperationW: Create subdir on Copy Hi All, Here's a small fix. Comments/questions are welcomed. Summary ------- This patch allows SHFileOperationW to automatically create subdirectories if they don't exists. (The Microsoft documentation states that this is correct.) This patch fixes bug #1954. I have verified that it works with Today's CVS. (January 30,2004) I ran into this problem with the Rollercoaster Tycoon demo installer. It can successfully copy files to this newly created directory, but coping into any (currently non-existant) directories below it fail. According to MS: (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl…) " Copy and Move operations can specify destination directories that do not exist and the system will attempt to create them. " (See footnote #1 for more info) For example, this succeeds: trace:shell:SHNotifyCopyFileW (L"E:\\WZS21db.tmp\\English\\rct.exe" L"C:\\Program Files\\Hasbro Interactive\\RollerCoaster Tycoon Demo\\rct.exe" ) But this fails: trace:shell:SHNotifyCopyFileW (L"E:\\WZS21db.tmp\\Saved Games\\001" L"C:\\Program Files\\Hasbro Interactive\\RollerCoaster Tycoon Demo\\Saved Games\\001" ) The directory "Saved Games" should be created before "001" is copied into it. Instead, the call fails. --Phil Hewlett-Packard: High Performance Technical Computing/Visualization --------------------------------------------------------------------------- Phillip.Ezolt(a)hp.com Performance/Development

1 0

Re: wine/ windows/win.c server/user.c
by Uwe Bonnes 28 May '04

28 May '04

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.org> writes: Alexandre> ChangeSet ID: 12496 CVSROOT: /opt/cvs-commit Module name: Alexandre> wine Changes by: julliard(a)wine.codeweavers.com 2004/05/28 Alexandre> 14:35:37 Alexandre> Modified files: windows : win.c server : user.c Alexandre> Log message: Only allocate even-numbered window handles, MS Alexandre> Project depends on that (found by Dmitry Timoshkov). Alexandre> Patch: http://cvs.winehq.org/patch.py?id=12496 When Opera sued MS for having non compatible Webpages and won, we should consider the same for this stupid thing :-) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Add documentation on the address space layout in Wine
by Mike Hearn 28 May '04

28 May '04

On Fri, 28 May 2004 09:10:22 +0200, Pouech Eric DMI AEI CAEN wrote: > Hi Mike > I've started to revisit the architecture.sgml file, and started to write > also about this matters (and a few others). For coherency reasons, if > you don't mind, I'll reintegrate your bits in the architecture.sgml file > (what you wrote covers also process image loading...). Sure, go ahead and do what you want with it. Do you know when you'll have something to submit? Also what else have you written about? I'm keen on getting as much of this low level technical detail down in writing so developers new to Wine stand a chance of understanding the scarier bits of the code. I was thinking of tackling DCOM next. thanks -mike

2 1

Re: Unsupported feature in SHFileOperationW
by fenix＠club-internet.fr 28 May '04

28 May '04

LOL I have seen (and sent a patch) a problem on FindExecutable who seems equivalent: trying to create a Link to an executable while executable not already present. Installers are funny :) Regards, Raphael ----Message d'origine---- >De: Lionel Ulmer <lionel.ulmer(a)free.fr> >A: wine-devel(a)winehq.org >Sujet: Unsupported feature in SHFileOperationW >Date: Fri, 28 May 2004 18:02:50 +0200 > >Hi all, > >A game demo installer uses SHFileOperationA to copy files over... And it >expects also the destination directories to be created when the copy is >done. > >Basically, it gives a list of fully qualified source files and their >corresponding fully qualified destination files and cann the >SHFileOperationA function with the 'FO_COPY' function and >'FOF_MULTIDESTFILES FOF_NOCONFIRMATION FOF_NOCONFIRMMKDIR' flags. > >This seems to not be handled properly in the current Wine tree as it fails >as soon as it needs to create the directory on the destination files. I >tested this on Windows and it works just fine (with nice MessageBoxes if one >ommits the 'NOCONFIRMMKDIR' flag :-) ). > >Is anyone (Martin, Ge ?) currently working on Shell32 who has an updated >tree with fixes in the Shell file operations ? > >If not, I will try to fix it on my own (be aware though that as I find the >style of coding used in this file particularely hard to decipher, I may do a >'NIH' on it and rewrite most of it to fit my tastes :-) ). > > Lionel > >-- > Lionel Ulmer - http://www.bbrox.org/ > >

1 0

msvcmaker - fix building makefiles on Windows
by Steven Edwards 28 May '04

28 May '04

Hello, I am not 100% sure if this is correct as I dont have a Windows box handy and dont know perl but this has been a known bug where msvcmaker did not properly build Makefiles when using Perl on Windows. A anonymous slashdot reader sent me this patch to fix this oversite. He saif to either attribute the changelog entry to Fred Patrik or to me. If someone has a Windows box handy could you test msvcmaker with this patch and see if it generates the makefiles properly now? Thanks Steven Changelog: Fix generation of MS_VC Makfiles on Windows __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

Unsupported feature in SHFileOperationW
by Lionel Ulmer 28 May '04

28 May '04

Hi all, A game demo installer uses SHFileOperationA to copy files over... And it expects also the destination directories to be created when the copy is done. Basically, it gives a list of fully qualified source files and their corresponding fully qualified destination files and cann the SHFileOperationA function with the 'FO_COPY' function and 'FOF_MULTIDESTFILES FOF_NOCONFIRMATION FOF_NOCONFIRMMKDIR' flags. This seems to not be handled properly in the current Wine tree as it fails as soon as it needs to create the directory on the destination files. I tested this on Windows and it works just fine (with nice MessageBoxes if one ommits the 'NOCONFIRMMKDIR' flag :-) ). Is anyone (Martin, Ge ?) currently working on Shell32 who has an updated tree with fixes in the Shell file operations ? If not, I will try to fix it on my own (be aware though that as I find the style of coding used in this file particularely hard to decipher, I may do a 'NIH' on it and rewrite most of it to fit my tastes :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

focused code review
by Glen Kaukola 28 May '04

28 May '04

Hi, So one project suggested on the website is to do a focused code review. In particular it talks about getting rid of inefficient uses of strcat. But that leaves me wondering what exactly constitutes an inefficient use of strcat? If anyone could provide an example I'd appreciate it. Thanks. Glen

2 1

Re: Default to 96dpi for the no config file case
by Rolf Kalbermatter 28 May '04

28 May '04

>If you mean via DDC then I guess this should work in most places, but for >whatever reason it does not work here :( In particular, xdpyinfo says: > >screen #0: > dimensions: 1024x768 pixels (321x241 millimeters) > resolution: 81x81 dots per inch > >So it appears to know the screen size (I measured with a ruler and >321x241 is right), but it gets the DPI too small anyway. At 81 dpi the >text is hardly readable. But: 1024/321*25.4 = 81.026 768/241*25.4 = 80.943 Seems to me X has it very right. That Windows usually doesn't care about real resolutions and instead fudges with it (consider the Large Font setting in the Display Control Panel) is probably another issue. Or the metrics this function requires are not dots per inch but something else. Rolf Kalbermatter

1 0

Re: Default to 96dpi for the no config file case
by Rein Klazes 28 May '04

28 May '04

On Thu, 27 May 2004 22:18:20 +0100, you wrote: > wineprefixcreate doesn't create a config file. This means we use a (wrong) > formula to decide what the DPI is supposed to be. Why do you mean (wrong) ? Do you not get the dpi values used by X? Or is it that is uses the X values but those are wrong? > It's wrong because > nobody tells the system how big their monitor is these days so it always > picks a DPI that is too small. Here X gets it from the monitor at start-up (via the logic of the video card). I did not realize that my situation is not normal. Somehow, I think setting a proper dpi should ideally be done in X. But in practice ... I agree with you that 95 dpi is about the minimum that is being used today. But I would keep this the minimum: if the dpi is set bigger then it is probably intentional. Either monitor magic or from a careful system administration. Rein. -- Rein Klazes rklazes(a)xs4all.nl

4 4

Re: Add documentation on the address space layout in Wine
by Pouech Eric DMI AEI CAEN 28 May '04

28 May '04

Hi Mike I've started to revisit the architecture.sgml file, and started to write also about this matters (and a few others). For coherency reasons, if you don't mind, I'll reintegrate your bits in the architecture.sgml file (what you wrote covers also process image loading...). A+ > Message du 28/05/04 01:35 > De : "Mike Hearn" > A : wine-patches(a)winehq.com > Copie à : > Objet : Add documentation on the address space layout in Wine > Mike Hearn > Add documentation on the address space layout in Wine > > Generated from: > * mike(a)navi.cx--2004/wine--mainline--0.9--patch-25 > > --- /dev/null 2003-09-15 14:40:47.000000000 +0100 > +++ documentation/address-space.sgml 2004-05-28 00:26:06.000000000 +0100 > @@ -0,0 +1,175 @@ > + > + > + > + > + Every Win32 process in Wine has its own dedicated native process on the host system, and > + therefore its own address space. This section explores the layout of the Windows address space > + and how it is emulated. > + > + > + > + Firstly, a quick recap of how virtual memory works. Physical memory in RAM chips is split > + into frames, and the memory that each process sees is split > + into pages. Each process has its own 4 gigabytes of address space (4gig > + being the maximum space addressable with a 32 bit pointer). Pages can be mapped or unmapped: > + attempts to access an unmapped page cause an EXCEPTION_ACCESS_VIOLATION which has the > + easily recognizable code of 0xC0000005. Any page can be mapped to any frame, therefore you can > + have multiple addresses which actually "contain" the same memory. Pages can also be mapped to > + things like files or swap space, in which case accessing that page will cause a disk access to > + read the contents into a free frame. > + > + > + > + > + > + > + When a Win32 process starts, it does not have a clear address space to use as it pleases. Many pages > + are already mapped by the operating system. In particular, the EXE file itself and any DLLs it > + needs are mapped into memory, and space has been reserved for the stack and a couple of heaps > + (zones used to allocate memory to the app from). Some of these things need to be at a fixed > + address, and others can be placed anywhere. > + > + > + > + The EXE file itself is almost always mapped at address 0x400000 and up: indeed, most EXEs have > + their relocation records stripped which means they must be loaded at their base address and > + cannot be loaded at any other address. > + > + > + > + DLLs are internally much the same as EXE files but they have relocation records, which means > + that they can be mapped at any address in the address space. Remember we are not dealing with > + physical memory here, but rather virtual memory which is different for each > + process. Therefore OLEAUT32.DLL may be loaded at one address in one process, and a totally > + different one in another. Ensuring all the functions loaded into memory can find each other > + is the job of the Windows dynamic linker, which is a part of NTDLL. > + > + > + > + So, we have the EXE and its DLLs mapped into memory. Two other very important regions also > + exist: the stack and the process heap. The process heap is simply the equivalent of the libc > + malloc arena on UNIX: it's a region of memory managed by the OS which malloc/HeapAlloc > + partitions and hands out to the application. Windows applications can create several heaps but > + the process heap always exists. It's created as part of process initialization in > + dlls/ntdll/thread.c:thread_init(). > + > + > + > + There is another heap created as part of process startup, the so-called shared or system > + heap. This is an undocumented service that exists only on Windows 9x: it is implemented in > + Wine so native win9x DLLs can be used. The shared heap is unusual in that anything allocated > + from it will be visible in every other process. This heap is always created at the > + SYSTEM_HEAP_BASE address or 0x65430000 and defaults to a megabyte in size. > + > + > + > + So far we've assumed the entire 4 gigs of address space is available for the application. In > + fact that's not so: only the lower 2 gigs are available, the upper 2 gigs are on Windows NT > + used by the operating system and hold the kernel (from 0x80000000). Why is the kernel mapped > + into every address space? Mostly for performance: while it's possible to give the kernel its > + own address space too - this is what Ingo Molnars 4G/4G VM split patch does for Linux - it > + requires that every system call into the kernel switches address space. As that is a fairly > + expensive operation (requires flushing the translation lookaside buffers etc) and syscalls are > + made frequently it's best avoided by keeping the kernel mapped at a constant position in every > + processes address space. > + > + > + > + On Windows 9x, in fact only the upper gigabyte (0xC0000000 and up) is used by the kernel, the > + region from 2 to 3 gigs is a shared area used for loading system DLLs and for file > + mappings. The bottom 2 gigs on both NT and 9x are available for the programs memory allocation > + and stack. > + > + > + > + There are a few other magic locations. The bottom 64k of memory is deliberately left unmapped > + to catch null pointer dereferences. The region from 64k to 4mb are reserved for DOS > + compatibility and contain various DOS data structures. Finally, the address space also > + contains mappings for the Wine binary itself, any native libaries Wine is using, the glibc > + malloc arena and so on. > + > + > + > + > + > + > + > + > + Up until about the start of 2004, the Linux address space very much resembled the Windows 9x > + layout: the kernel sat in the top gigabyte, the bottom pages were unmapped to catch null > + pointer dereferences, and the rest was free. The kernels mmap algorithm was predictable: it > + would start by mapping files at low addresses and work up from there. > + > + > + > + The development of a series of new low level patches violated many of these assumptions, and > + resulted in Wine needing to force the Win32 address space layout upon the system. This > + section looks at why and how this is done. > + > + > + > + The exec-shield patch increases security by randomizing the kernels mmap algorithms. Rather > + than consistently choosing the same addresses given the same sequence of requests, the kernel > + will now choose randomized addresses. Because the Linux dynamic linker (ld-linux.so.2) loads > + DSOs into memory by using mmap, this means that DSOs are no longer loaded at predictable > + addresses, so making it harder to attack software by using buffer overflows. It also attempts > + to relocate certain binaries into a special low area of memory known as the ASCII armor so > + making it harder to jump into them when using string based attacks. > + > + > + > + Prelink is a technology that enhances startup times by precalculating ELF global offset > + tables then saving the results inside the native binaries themselves. By grid fitting each > + DSO into the address space, the dynamic linker does not have to perform as many relocations > + so allowing applications that heavily rely on dynamic linkage to be loaded into memory much > + quicker. Complex C++ applications such as Mozilla, OpenOffice and KDE can especially benefit > + from this technique. > + > + > + > + The 4G VM split patch was developed by Ingo Molnar. It gives the Linux kernel its own address > + space, thereby allowing processes to access the maximum addressable amount of memory on a > + 32-bit machine: 4 gigabytes. It allows people with lots of RAM to fully utilise that in any > + given process at the cost of performance: as mentioned previously the reason behind giving > + the kernel a part of each processes address space was to avoid the overhead of switching on > + each syscall. > + > + > + > + Each of these changes alter the address space in a way incompatible with Windows. Prelink and > + exec-shield mean that the libraries Wine uses can be placed at any point in the address > + space: typically this meant that a library was sitting in the region that the EXE you wanted > + to run had to be loaded (remember that unlike DLLs, EXE files cannot be moved around in > + memory). The 4G VM split means that programs could receive pointers to the top gigabyte of > + address space which some are not prepared for (they may store extra information in the high > + bits of a pointer, for instance). In particular, in combination with exec-shield this one is > + especially deadly as it's possible the process heap could be allocated beyond > + ADDRESS_SPACE_LIMIT which causes Wine initialization to fail. > + > + > + > + The solution to these problems is for Wine to reserve particular parts of the address space > + so that areas that we don't want the system to use will be avoided. We later on > + (re/de)allocate those areas as needed. One problem is that some of these mappings are put in > + place automatically by the dynamic linker: for instance any libraries that Wine > + is linked to (like libc, libwine, libpthread etc) will be mapped into memory before Wine even > + gets control. In order to solve that, Wine overrides the default ELF initialization sequence > + at a low level and reserves the needed areas by using direct syscalls into the kernel (ie > + without linking against any other code to do it) before restarting the standard > + initialization and letting the dynamic linker continue. This is referred to as the > + preloader and is found in ld-winepreload.so (loader/preloader.c) > + > + > + > + Once the usual ELF boot sequence has been completed, some native libraries may well have been > + mapped above the 3gig limit: however, this doesn't matter as 3G is a Windows limit, not a > + Linux limit. We still have to prevent the system from allocating anything else above there > + (like the heap or other DLLs) though so Wine performs a binary search over the upper gig of > + address space in order to iteratively fill in the holes with MAP_NORESERVE mappings so the > + address space is allocated but the memory to actually back it is not. This code can be found > + in libs/wine/mmap.c:reserve_area. > + > + > + > + > + > --- documentation/wine-devel.sgml > +++ documentation/wine-devel.sgml > @@ -13,6 +13,7 @@ > > > > + > > > > @@ -138,6 +139,7 @@ > &implementation; > &porting; > &consoles; > + &address-space; > &cvs-regression; > > > > >

1 0

[Fwd: winetest: copy and submit manually]
by Robert Reif 28 May '04

28 May '04

oops, wrong list.

1 0

RE: FW: Edit Paste operation does not behave same as MS Windows
by Krishna Murthy 28 May '04

28 May '04

This means it is sufficient to return FALSE in EDIT_MakeFit if the honor limit is not set and size exceeds the buffer limit? static BOOL EDIT_MakeFit(EDITSTATE *es, UINT size, BOOL honor_limit) { HLOCAL hNew32W; if ((!honor_limit) && (es->buffer_limit > 0) && (size > es->buffer_limit)) { EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT"); return FALSE; } ... } I will verify with this change and if works in all condition, will submit the patch. Thanks for your help, Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard@winehq.org] Sent: Thursday, May 27, 2004 5:12 PM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: Edit Paste operation does not behave same as MS Windows Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > Actually the logic truncates the data which exceeded the buffer. If > the honor limit is set and the size exceeded, the EDIT_MakeFit will return TRUE. > The following code after the EDIT_MakeFit will try to take limit to > the buffer size. > > + /* Only replace or insert that many characters that can fit into the > + edit control. Do this only if honor_limit is TRUE */ > + if(honor_limit && strl > es->buffer_limit) > + strl = es->buffer_limit - (tl - (e-s)); That only takes into account the limit, not the current buffer size. It's very possible that you need to grow the buffer even when the limit is not exceeded. Also you only check the length of the inserted string against the limit, you should check the total resulting length instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: FW: Edit Paste operation does not behave same as MS Windows
by Krishna Murthy 28 May '04

28 May '04

Actually the logic truncates the data which exceeded the buffer. If the honor limit is set and the size exceeded, the EDIT_MakeFit will return TRUE. The following code after the EDIT_MakeFit will try to take limit to the buffer size. + /* Only replace or insert that many characters that can fit into the + edit control. Do this only if honor_limit is TRUE */ + if(honor_limit && strl > es->buffer_limit) + strl = es->buffer_limit - (tl - (e-s)); Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard@winehq.org] Sent: Thursday, May 27, 2004 2:30 PM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: Edit Paste operation does not behave same as MS Windows Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > - Change log Entry: > EDIT_MakeFit should return TRUE when the honor_limit is set and paste > buffer exceeds the limit. Also EDIT_EM_ReplaceSel should compute size > which could fit in the edit control by truncating the extra characters > to behave similar to MS Windows paste operation. You are bypassing the reallocation of the buffer when the limit is exceeded, but still adding the data to the buffer. I don't think this will work right. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Crash and corrupted registry
by Alexandre Julliard 27 May '04

27 May '04

Christian Costa <titan.costa(a)wanadoo.fr> writes: > This seems to be more a filesytem issue then because the file is in a > really bad shape. > I use reiserfs on a Mandrake 2.4.21-0.13mdk kernel. > It seems to happend on files that are open when the crash (freeze + > reboot) occurs. Yes, it very much looks like a filesystem issue, I prefer that <g> If you feel like trying to reproduce it, maybe you could try to add an fsync() in the saving code and see if this makes a difference. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: FW: Edit Paste operation does not behave same as MS Windows
by Alexandre Julliard 27 May '04

27 May '04

Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > - Change log Entry: > EDIT_MakeFit should return TRUE when the honor_limit is set and paste buffer > exceeds the limit. Also EDIT_EM_ReplaceSel should compute size which could > fit in the edit control by truncating the extra characters to behave similar > to MS Windows paste operation. You are bypassing the reallocation of the buffer when the limit is exceeded, but still adding the data to the buffer. I don't think this will work right. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Repaint the whole nonclient window area on SetWindowPos(SWP_FRAMECHANGED)
by Alexandre Julliard 27 May '04

27 May '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > SetWindowPos(SWP_FRAMECHANGED) causes the whole nonclient window area > to be repainted. > > Also, according to the tests Windows always repaints windows before > SetWindowPos has finished. > > This patch reduces number of message test failures from 56 to 47. The message order is wrong because we rely on X expose events to repaint the window. This is one of the reasons we need to go back to not using X windows for every window; but until that is done, your fix is going to cause every window to be repainted twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Add a test for accessing classes from another thread
by Alexandre Julliard 27 May '04

27 May '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > somebody on the ReactOS mailing list mentioned that Windows stores class > information in the per thread list, not a per process or per module list. > That would effecively meant that accessing classes or creating windows > from other threads would fail. > > So, I decided to write a test for that. The test passes under Wine. Not for me: class.c:258: Test failed: GetLastError() should be set to ERROR_CLASS_HAS_WINDOWS class.c:258: Test failed: GetLastError() should be set to ERROR_CLASS_HAS_WINDOWS -- Alexandre Julliard julliard(a)winehq.org

1 0

atoi and undefined usage
by andrejoh＠c2i.net 27 May '04

27 May '04

The atoi() function has undefined usage when trying to convert numbers outside the range of int. When parsing numbers >= 2^31, GNU libc seems to truncate the number to 2^31-1; however, with MSVC, such a number would wrap, and when cast to an unsigned integer, numbers within an unsigned int are preserved. Should Wine care about such undefined behaviour? Currently, it seems Wine uses the GNU libc implementation, giving a different result than when running in Windows. (In my case, an IP address was given as a string, and ended up as "127.255.255.255" when running in Wine. I've now fixed that specific bug in the source code, but with other programs, that might not be an option...) -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

2 1

Re: test for GetAcceptLanguagesA
by Martin Fuchs 27 May '04

27 May '04

On 27.05.2004 04:09:34 Alexandre Julliard wrote: > Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > > before removing the acsii calls from GetAcceptLanguagesW, i like to see > the > > results of the attached tests. This will hopefuly save me some work when > > rewriting the function. The tests passes on my Win2k system. > But they fail on Wine, so I can't apply the patch. I've seen some test cases wrapped in TODO sections, for example: todo_wine { SetWindowLong(hwnd1, GWL_EXSTYLE, GetWindowLong(hwnd1,GWL_EXSTYLE)|WS_EX_TOPMOST); ret = GetWindowLong(hwnd1,GWL_EXSTYLE)&WS_EX_TOPMOST? TRUE: FALSE; ok(!ret, "SetWindowExStyle(hwnd1, WS_EX_TOPMOST)\n"); } This prints a warning message about something yet to to in Wine, but the test doesn't fail. Can't you use this also for the patch in question? Regards, Martin

1 0

having problem in understanding debug channels
by zeeshaan umer 27 May '04

27 May '04

hi, its zee here, i am a student and i have just came to know about wine 2-3 weeks ago. i have started studying it for exploration purpose. its quite a great effort of u people. really it is........ nways the problem i m having is that i m not clearly understanding debug channels. i actually was trying to be a part of developers of wine and i tried to implement an API but when i wrote and included it in the source it could not be compiled i got an error " invalid debug channel specification ' ZEE_DEFAULT_DEBUG_CHANNEL( );' " i de have define ZEE_DEFAULT_DEBUG_CHANNEL in debug.h but frankly i have not actually understood the complete philosphy of these debug channels that how they work and how are they defined properly. plz,.......anybody help me. i m a student so dont mind if it is really rediculous type of problem......:-) zeeshan xeshaan(a)yahoo.co.in Yahoo! India Matrimony: Find your partner online.

2 1

Re: Additional downloads for winehq
by Ivan 27 May '04

27 May '04

OK, I don't see the utility of having a 3rd party download section just to list one download. But what about dcom95? We have a message in oleaut that tells the user to download dcom95, and it provides a link to sf, but we can't host dom on sf because it isn't open source, and people can download it free from m$ anyway. But Alexandre doesn't like long links, and the link to the dcom95 download page is just too long. It's http://www.microsoft.com/downloads/details.aspx?familyid=d7a4de78-81a9-4db7… and we want to keep the error log short. Ivan.

2 1

Re: Re: test for GetAcceptLanguagesA
by Pouech Eric DMI AEI CAEN 27 May '04

27 May '04

> Its not a fault of the tests that they fail on wine, its a fault of > wine. For my understanding the test are created to show that either the > behaviour of wine is correct (when the test succeeds) or that something > left to do one wine (when a test fails)!? check out the todo_wine construct in winetest Alexandre point is not that you cannot add a test that currently fails in Wine. His point is that you cannot add a test that will make the test process fail. The todo_wine is done for that: 1/ it marks a test as failing on wine 2/ it will report it (but not make the test fail) 3/ it will also make the test process fail if the test succeeds (so that we can remove the todo_wine mark) A+

1 0

Re: test for GetAcceptLanguagesA
by Alexandre Julliard 27 May '04

27 May '04

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > before removing the acsii calls from GetAcceptLanguagesW, i like to see the > results of the attached tests. This will hopefuly save me some work when > rewriting the function. The tests passes on my Win2k system. But they fail on Wine, so I can't apply the patch. -- Alexandre Julliard julliard(a)winehq.org

4 3

[Janitorial]: Missing inversion im Bit manipulation
by Uwe Bonnes 27 May '04

27 May '04

Changelog: wine/dlls/winmm/winmm.c: Add obvious missing inversion -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/winmm/winmm.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/winmm.c,v retrieving revision 1.33 diff -u -w -r1.33 winmm.c --- wine/dlls/winmm/winmm.c 27 Feb 2004 21:29:32 -0000 1.33 +++ wine/dlls/winmm/winmm.c 27 May 2004 07:56:13 -0000 @@ -1983,7 +1983,7 @@ lpMidiHdr = (LPMIDIHDR)msg->lParam; lpMidiHdr->lpNext = 0; lpMidiHdr->dwFlags |= MHDR_INQUEUE; - lpMidiHdr->dwFlags &= MHDR_DONE; + lpMidiHdr->dwFlags &= ~MHDR_DONE; lpMidiHdr->dwOffset = 0; break;

1 0

Re: Additional downloads for winehq
by Jeremy Newman 27 May '04

27 May '04

I don't think these belong on the download page. That would confuse the users. IMO the download page should only contain links to download Wine. All this should go in a HowTo or in the docs. I know we have the 3rd party tools section there. I was opposed to that as well. We just cleaned up the download page, and you people want to clutter it up again! <g> Btw, your link to the download page in the second patch in wrong. it should be: http://www.winehq.org/download (we need to keep consistent on the .org thing) On Wed, 2004-05-26 at 18:09, Ivan wrote: > These downloads can be useful for lots of wine users. > > Ivan.

1 0

Re: [DMUSIC] IDirectMusicSegment8 loading of Wave Segments
by Rok Mandeljc 26 May '04

26 May '04

> PS: > Rok, i have you have implemented IDirectMusicSegment8 interface on > IDirectMusicWaveImpl. > Why ? > What it your "sample" who permit to check this behavior ? > For testing my patch you only have, for example, to open a .wav file using > 3DAudio.exe sdk sample Hey, I'm sorry but I cannot really remember (have experienced computer crash and it will take some time for me to organise everything again). I'm not even sure if IDirectMusicSegment should be implemented for it, but i think my test was to create native IDirectMusicWave via CoCreateInstance and then try to QueryInterface it with all possible IIDs; I can't remember result, but I think it was supported (unless I made a mistake ;=) - Rok

2 1

Assume MAX_PATH length for pszDisplayName
by Uwe Bonnes 26 May '04

26 May '04

Changelog: dlls/shell32/brsfolders.c: SHBrowseForFolderA LPBROWSEINFOA->pszDisplayName is assumed to have MAX_PATH legth Fixes a crash in Xilinx ISE when vreating a new project with a long path -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/shell32/brsfolder.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/brsfolder.c,v retrieving revision 1.51 diff -u -w -5 -r1.51 brsfolder.c --- wine/dlls/shell32/brsfolder.c 19 Apr 2004 20:12:14 -0000 1.51 +++ wine/dlls/shell32/brsfolder.c 26 May 2004 13:56:29 -0000 @@ -460,11 +460,12 @@ bi.hwndOwner = lpbi->hwndOwner; bi.pidlRoot = lpbi->pidlRoot; if (lpbi->pszDisplayName) { len = MultiByteToWideChar(CP_ACP, 0, lpbi->pszDisplayName, -1, NULL, 0); - bi.pszDisplayName = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + /*lpbi->pszDisplayName is assumed to be MAX_PATH (MSDN) */ + bi.pszDisplayName = HeapAlloc(GetProcessHeap(), 0, MAX_PATH * sizeof(WCHAR)); MultiByteToWideChar(CP_ACP, 0, lpbi->pszDisplayName, -1, bi.pszDisplayName, len); } else bi.pszDisplayName = NULL;

1 0

Type in msvcrt
by Uwe Bonnes 26 May '04

26 May '04

Changelog: dlls/msvcrt/file.c: _setmode() Reset only the affected flag Make Xilinx ise not hang at startup Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/msvcrt/file.c =================================================================== RCS file: /home/wine/wine/dlls/msvcrt/file.c,v retrieving revision 1.67 diff -u -w -5 -r1.67 file.c --- wine/dlls/msvcrt/file.c 13 May 2004 00:23:25 -0000 1.67 +++ wine/dlls/msvcrt/file.c 26 May 2004 12:17:06 -0000 @@ -1437,11 +1448,11 @@ if (mode & (~(_O_TEXT|_O_BINARY))) FIXME("fd (%d) mode (0x%08x) unknown\n",fd,mode); if ((mode & _O_TEXT) == _O_TEXT) MSVCRT_fdesc[fd].xflag |= WX_TEXT; else - MSVCRT_fdesc[fd].xflag &= WX_TEXT; + MSVCRT_fdesc[fd].xflag &= ~WX_TEXT; return ret; } /********************************************************************* * _stati64 (MSVCRT.@)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel