- wine-devel - winehq.org

Edit box input problem
by Brad Campbell 01 Apr '03

01 Apr '03

G'day all, I'm having a strange problem with any application that uses a delphi TMaskEdit component. I have knocked up a simple test application. http://www.seme.com.au/masktest.tgz It's in Borland Delphi 4 and contains both the .exe and the source for the interested or security conscious. Can someone else run this up on their wine build and see if it's doing the same thing? Under windows, it will only accept three numeric characters, under wine I'm unable to edit the field, it accepts over 3 characters and of any type, plus the first one or two character entries create a message storm as watched with a --debugmsg +message. Also, I'm willing to have a crack at fixing this, which .dll source should I start looking at? I also tried this with native comctl32, commdlg and oleaut32 dll's just in case. Problem remains. A normal Edit component works fine, and if I remove the mask it works fine, so it must be something the in the delphi code for the TMaskEdit component that is triggering a wine bug. -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

Question about kernel32 resources
by Maxime Bellengé 01 Apr '03

01 Apr '03

I am currently working on the EnumSystemLanguageGroups/EnumLanguageGroupLocales functions. I have finished everything but there is one thing I don't know. The different language group names are stored in the kernel32.dll resources in a string table. They are indexed from 1 to 17 in the win2k/winxp kernel32 dll. However, in wine it seems these ID are used. So I am wondering how can I workaround that. I can't change the ID for the groups because they are defined in winnls.h from 1 to 17. At the present time I have a version ready to work but with the group names not stored in the resources (so only one language is possible). Do I have to change the kernel32 resources ( a lot of work) or does anyone have an idea ? Thanks Max -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

2 1

Problem with debugging: XIO: fatal IO error 0 (Success) on X server ":0.0"
by Juraj Hercek 01 Apr '03

01 Apr '03

Hi, I have troubles with debugging winelib applications. This is what makes me unhappy: --- $ gdb wine (gdb) r notepad Starting program: /usr/local/bin/wine notepad XIO: fatal IO error 0 (Success) on X server ":0.0" after 187 requests (187 known processed) with 0 events remaining. Program exited with code 01. --- I'm getting similar results with winedbg (running "winedbg notepad") - there is just bunch of debug outputs before the error is printed. However, this happens only when I'm running winedbg from outside wine directory (checked out from cvs). It works when I'm running winedbg from wine directory. I was digging inside wine and problem occurs somewhere in MODULE_DllProcessAttach() function. This lead me to assumption that problem is probably caused by incorrect paths to libraries, which couldn't be found then. I think I should mention that also wineinstall failed because regedit couldn't find "programs/regedit/regedit.exe.so" (this file is definitely there) so I had to run regedit to insert winedefault.reg into registry manualy - I needed to copy winedefault.reg file to /tmp which is accessible from inside wine system as drive E:\. My working environment is mdk-9.1 with XFree86 version 4.3.0, native nvidia driver doesn't work, the same with nvidia driver v. 41.91). If you have any idea what could be wrong with my linux box, please let me know. I prefer gdb for debugging since I can use ddd with gdb. Thanks. --Juraj

2 1

Re: wine/ scheduler/timer.c scheduler/synchro.c in ...
by Bill Medland 31 Mar '03

31 Mar '03

On March 30, 2003 05:37 pm, Alexandre Julliard wrote: > ChangeSet ID: 7728 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/03/30 19:37:05 > > Modified files: > scheduler : timer.c synchro.c > include : winternl.h > dlls/ntdll : time.c sync.c om.c ntdll_misc.h ntdll.spec > > Log message: > Moved WaitForMultipleObjects to ntdll (based on a patch by Eric > Pouech). > Added NTDLL_get_server_timeout function to compute ntdll-style > timeouts and adapted the timer code to use it. > > Patch: http://cvs.winehq.com/patch.py?id=7728 > This breaks the build (on my machine at least) sync.c contains a LARGE_INTEGER time and takes time.s.* include/wtypes.h LARGE_INTEGER only contains a QuadPart as far as I can see. > Old revision New revision Changes Path > 1.17 1.18 +9 -22 wine/scheduler/timer.c > 1.45 1.46 +16 -189 wine/scheduler/synchro.c > 1.21 1.22 +1 -0 wine/include/winternl.h > 1.28 1.29 +42 -6 wine/dlls/ntdll/time.c > 1.23 1.24 +192 -5 wine/dlls/ntdll/sync.c > 1.25 1.26 +0 -13 wine/dlls/ntdll/om.c > 1.11 1.12 +2 -0 wine/dlls/ntdll/ntdll_misc.h > 1.101 1.102 +2 -2 wine/dlls/ntdll/ntdll.spec -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

1 0

Re: lostwages/. winehq.css
by Dimitrie O. Paun 31 Mar '03

31 Mar '03

On Mon, 31 Mar 2003, Jeremy Newman wrote: > ChangeSet ID: 7729 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/03/31 11:03:14 > > Added files: > . : winehq.css Should we move all CSS stuff in there (like the stuff I use in my Fun/Winelib/etc. pages)? -- Dimi.

2 3

Multicast options in WinSock with java
by Mike Hearn 31 Mar '03

31 Mar '03

Hi all, I have a bit of a problem. Essentially, the problem is that Java 1.4 is buggy, it includes winsock.h, but then proceeds to use winsock2. That wouldn't be an issue, except that my app uses multicast sockets, and for reasons known only to Redmond they decided to change the values of some of the multicast socket option constants. Java, therefore, passes in the winsock1 values to winsock2. Windows apparently can deal with this just fine (well, the appw works), despite there being no obvious way to remap them, both IP_MULTICAST_IF and IP_HDRINCL which both == 2 in different winsock versions would be valid at once on XP/2003 for instance. Marcus, I know you took a stab at implementing multicast support once, so if you have any tips that'd be appreciated. If anybody knows a way you might be able to detect that a program is using the wrong headers for the winsock2 dll, please let me know. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 2

Error in CVS?
by Vilppa Salt 31 Mar '03

31 Mar '03

<snip> gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D__WINESRC__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o signal_sparc.o signal_sparc.c gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D__WINESRC__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o sync.o sync.c sync.c: In function `call_apcs': sync.c:390: union has no member named `s' sync.c:390: union has no member named `s' make[2]: *** [sync.o] Error 1 make[2]: Leaving directory `/home/vilppa/wineCVS/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/home/vilppa/wineCVS/wine/dlls' make: *** [dlls] Error 2 This is what I get when building latest Wine CVS. --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

2 1

cross compiling Wine under MSVC
by Rolf Kalbermatter 31 Mar '03

31 Mar '03

Hello, I have just got the whole Wine sources on a Linux computer and shared the sources directory over samba to try to compile parts of it in MSVC. Here I get several problems which seem to me configuration related, but I wonder how I'm supposed to proceed to get everything working. I have run ./tools/winapi/msvcmaker to create the MSVC project files and hopefully anything else which is required for this. I can of course add some (the correct?) definitions by hand to config.h or port.h but I would rather like to do it the way it is supposed to be or if there is a problem get it resolved now. First problem: wine\tools\winebuild\spec32.c(213) and other lines in that file use macros __ASM_SHORT and __ASM_STRING which should be defined in config.h. How do I get a config.h which is compatible with MSVC? Is there a special tool for this? I obviously can't really run ./configure from my Windows machine ;-) Second problem: Some Wine files include headers which sooner or later include "windows.h" and that causes error messages that this should not be done for Wine sources. There is a macro COM_NO_WINDOWS_H in the Wine sources to avoid this inclusion. ./tools/winapi/msvcmaker does forget to add this macro as standard definition in all project files for the Wine sources, but obviously should not do this for the test project files, I think. I'm no Perl guy so I hesitate to even touch the msvcmaker tool. Up until now I fixed such problems by manualy editing port.h which made it work for my local operation, but it seems to me that we should try to get this resolved, so that not everone does privately reinvent the wheel here. Rolf Kalbermatter

1 0

Re: lostwages/templates/en fun_projects.template
by Dimitrie O. Paun 31 Mar '03

31 Mar '03

On March 30, 2003 11:23 am, Andreas Mohr wrote: > ChangeSet ID: 7720 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: amohr(a)wine.codeweavers.com 2003/03/30 10:23:41 > > Modified files: > templates/en : fun_projects.template > > Log message: > Update by Francois > > Patch: http://cvs.winehq.com/patch.py?id=7720 > > Old revision New revision Changes Path > 1.2 1.3 +1 -1 > lostwages/templates/en/fun_projects.template It's better if you send these to me directly, as I maintain these pages (Fun Project, Winelib, etc.) separately, and so we don't run the risk of losing them on next update. I'll apply this one to my page as well. -- Dimi.

1 0

Re: lostwages/templates/en contributing.template
by Dimitrie O. Paun 31 Mar '03

31 Mar '03

On March 30, 2003 10:59 am, Andreas Mohr wrote: > ChangeSet ID: 7718 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: amohr(a)wine.codeweavers.com 2003/03/30 09:59:45 > > Modified files: > templates/en : contributing.template > > Log message: > Update by Francois > > Patch: http://cvs.winehq.com/patch.py?id=7718 > > Old revision New revision Changes Path > 1.4 1.5 +67 -62 > lostwages/templates/en/contributing.template I take my critiques back for now -- changes look good. Hopefully we'll fix the smaller things from my TODO, and move the larger ones as individual bugs so we can track them better. I'll do that soon. -- Dimi.

1 0

Re: Contributing page needs fixing
by Dimitrie O. Paun 30 Mar '03

30 Mar '03

On March 30, 2003 03:30 pm, Francois Gouget wrote: > Yes, definitely. Now is not the time to say the 'web site is finished we > don't need anyone'. That's simply not true. That will not cut it, sorry. I've posted a list of "still TODO", and asked for comments. Nobody bothered to reply to it. The web site is not the open ended project Wine is. We can reach a state where we are happy with it, and I think that state is not far away. What we need is a list of things that we think we need. I've started such a list. If you want to add something, please say so. Simply saying "we need more stuff" isn't good enough. -- Dimi.

1 0

Re: bin2rc
by Alexandre Julliard 30 Mar '03

30 Mar '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I've just stupidly lost an hour or so trying to figure out > how to convert a .bmp to a .rc script. Such a simple problem... That's what tools/bin2res is for... -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: Contributing page needs fixing
by Dimitrie O. Paun 30 Mar '03

30 Mar '03

On March 29, 2003 09:48 pm, Francois Gouget wrote: > Wine-Develipmont</a>. > + <p>WineHQ has been redisigned recently. But there is still work to do. > + So you would feel like writing about Wine or coding in Php your > + contribution will be appreciated. You can find the current task list I think we should remove this section altogether. The page is already way too big, and this is as bad as a not enough info. The site has been redesigned, and there are only a few things that are missing -- and those can't be done by just anyone. Really, now the last thing we need is people comming over and messing with the site. Let's have a *focused* page on where we need help, not a laundry list of just about everything. -- Dimi.

2 2

SHFileOperation regression test
by Rolf Kalbermatter 30 Mar '03

30 Mar '03

While working on SHFileOperation in shell32.dll I came across the error in line 286 and 287 which happens on Win98/ME/2K/XP but not on 95/NT. Investigation showed that the copy operation of multiple files with one source file not existing in the list, has different behaviour on these two groups of OS Versions. Win 95/NT abort the copy operation at the first file not existing, and return WITHOUT any error indication whatsoever, leaving the already copied files in the target directory. Win 98/ME/2K/XP have obviously fixed this bug in a rather strict manner, in that such a copy operation is aborted with error return value 1026 (undocumented, resp. meaningless in this cicumstance other than that it is non-zero), and no file is copied at all. (There still exists a small bug, at least in 2K, in that the fAnyOperationsAborted flag in the SHFILEOPSTRUCT structure is not set at all in this case on return.) Obviously our shlfileop.c test needs fixing but I'm not sure how to proceed as I'm fairly new to the Wine regression testing. From what I gathered it is not really acceptable to create Windows version dependant tests in the regression framework, which leaves only two other options, IMO: 1) Remove this particular test altogether or 2) Test only the behaviour which is consistent on all platforms which in this case would be only the non-existence of the test2.txt file. Both options leave out possibly important regression test cases for the future. Any comments on this issue from the more seasoned guys into regression test writing? Appended is the patch which is correct for Win 98/ME/2K/XP but will cause test failure on 95/NT. Rolf Kalbermatter Index: dlls/shell32/tests/shlfileop.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/tests/shlfileop.c,v retrieving revision 1.6 diff -u -r1.6 shlfileop.c --- dlls/shell32/tests/shlfileop.c 14 Jan 2003 23:43:42 -0000 1.6 +++ dlls/shell32/tests/shlfileop.c 30 Mar 2003 08:52:58 -0000 @@ -278,13 +278,15 @@ ok(file_exists(".\\testdir2\\test2.txt"), "The file is copied"); clean_after_shfo_tests(); + /* Copying multiple files with one not existing as source, fails the + entire operation in Win98/ME/2K/XP with return value 1026, but only + the files after the one not existing and without any error indication + in 95/NT, ! */ init_shfo_tests(); tmp_flags = shfo.fFlags; set_curr_dir_path(from, "test1.txt\0test10.txt\0test2.txt\0"); ok(!file_exists(".\\testdir2\\test1.txt"), "The file is not copied yet"); ok(!file_exists(".\\testdir2\\test2.txt"), "The file is not copied yet"); - ok(!SHFileOperationA(&shfo), "Files are copied to other directory "); - ok(file_exists(".\\testdir2\\test1.txt"), "The file is copied"); + ok(SHFileOperationA(&shfo), "Files are copied to other directory "); + ok(!file_exists(".\\testdir2\\test1.txt"), "The file is copied"); ok(!file_exists(".\\testdir2\\test2.txt"), "The file is copied"); shfo.fFlags = tmp_flags; }

1 0

Re: Compiling WINE - Hopeless situation? :)
by Dan Kegel 30 Mar '03

30 Mar '03

Sylvain wrote: > --- Michael Stefaniuc <mstefani(a)redhat.de> a écrit : > On Sun, Mar 30, > 2003 at 12:44:31AM +0100, Sylvain Petreolle wrote: >> > The code that has problem for now is C code, not C++, am I right >> here ? >> > Then it has nothing to do with C++ thing. >> Yeah, but the page you pointed to is for C++ incompatibilities, not >> C. >> And a newer 2.96 is stable for C. > If there is one, it isnt shipped with RH 8, or not by default. Red Hat 8 uses gcc3.2. If you have Red Hat 8, you don't need gcc2.96. > "Current snapshots of GCC, and any version labeled 2.96, produce object > files that are not compatible with those produced by either GCC 2.95.2 > or the forthcoming GCC 3.0." This is true only for C++. For C code, Red Hat's gcc2.96's have been just fine. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: Compiling WINE - Hopeless situation? :)
by Sylvain Petreolle 30 Mar '03

30 Mar '03

Please update gcc to version 3.x.x, gcc2.96 was a broken unofficial version of RedHat and all dependancies must be updated too. (like binutils) Time to put an entry in README or something else ? Is gcc version checked by configure ? --- Matt Bailey <mattb(a)rtccom.net> a écrit : > Hi, > > Any ideas on that last error message I sent? One detail I did not > mention > is that I still have libstdc++2.10 installed, it says it's version > 2.96-0.76mdk. I knew there was some 2.96 package still installed but > I had > forgotten what it was called. I can't uninstall this package because > it is > needed by a BUNCH of other apps........looks like it would just about > trash > my Mandrake install to remove this package. Do I need to upgrade this > > package, and if so, how would I go about it without completely > uninstalling > it? I also have installed libstdc++5, version 3.2-1mdk. > Is it hopeless? I don't blame you if you gave up on this problem. :) > Anyway, > your advice has been greatly helpful already, much appreciated. > > -Matt Bailey ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 8

Re: Possible regression: wine/dlls/kernel/tests/process crashes
by Sylvain Petreolle 29 Mar '03

29 Mar '03

> Here is what I did: > > cd ../wine/dlls/kernel/tests > > rm process.o > > > make test > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.exe.so process.c && touch process.ok you can run it with wine/winedbg without runtest : wine kernel32_test.exe.so process > and after some time this automatically pops up: > process.c:382: Test failed: Child process termination > wine: process.c:400: test_Startup: Assertion `DeleteFileA(resfile) != > 0' > failed. now you know approximatively where the test fail. > The debugger starts again and again. if winedbg fails to debug it, use winedbg --gdb instead. winedbg -- --gdb kernel32_test.exe.so process > > How do I run those test on Win? Can you point me to a document > describing > the procedure? see Francois 's pages or it : http://fgouget.free.fr/wine/tests-en.shtml ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Possible regression: wine/dlls/kernel/tests/process crashes
by Uwe Bonnes 29 Mar '03

29 Mar '03

Hallo, wine/dlls/kernel/tests/process crashed. I was not able to decipher what is going on. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

More QEMU fixes
by Ulrich Weigand 29 Mar '03

29 Mar '03

Hello Fabrice, I've played a bit with your qemu-0.1.2 release, and got putty running under Wine under qemu on s390-ibm-linux (using a wineserver also running under qemu on s390). To make this work I've had to add a bunch of missing byteorder conversions and other fixes, which I've appended here. Mostly, the changes concern the socket area; wine and wineserver extensively use sockets (sendmsg/recvmsg with ancillary data), and also the X connection needed fixes (setsockopt). There were also some other fixes required (poll, select, execve). I haven't found any problem with the actual CPU emulation, however! Here's the detailed list of changes: glibc-2.3.2 compile fix: Recent glibc supports nanosecond resolution file timestamps in their struct stat, using this construct struct timespec st_atim; /* Time of last access. */ struct timespec st_mtim; /* Time of last modification. */ struct timespec st_ctim; /* Time of last status change. */ # define st_atime st_atim.tv_sec /* Backward compatibility. */ # define st_mtime st_mtim.tv_sec # define st_ctime st_ctim.tv_sec This breaks the use of st_atime etc. as struct members; I've renamed them to target_st_atime etc. Missing data conversion: - socketcall on-stack arguments need to be byteswapped - struct sockaddr (sa_family) needs to be byteswapped - sendmsg/recvmsg ancillary data needs to be converted - execve arg and env vectors need to be byteswapped - select fdset conversion wasn't done due to typo in #if - added marginal support for setsockopt Incorrect data conversion: - poll pollfd array was clobbered (even on native) If you like, I could also send you the patch to make qemu actually work on s390; I'm not sure if you are interested in that at this point ... Bye, Ulrich diff -ur qemu-0.1.2/syscall-i386.h qemu-0.1.2-s390/syscall-i386.h --- qemu-0.1.2/syscall-i386.h 2003-03-26 23:34:59.000000000 +0100 +++ qemu-0.1.2-s390/syscall-i386.h 2003-03-29 02:33:28.000000000 +0100 @@ -255,11 +255,11 @@ target_ulong st_size; target_ulong st_blksize; target_ulong st_blocks; - target_ulong st_atime; + target_ulong target_st_atime; target_ulong __unused1; - target_ulong st_mtime; + target_ulong target_st_mtime; target_ulong __unused2; - target_ulong st_ctime; + target_ulong target_st_ctime; target_ulong __unused3; target_ulong __unused4; target_ulong __unused5; @@ -290,13 +290,13 @@ target_ulong st_blocks; /* Number 512-byte blocks allocated. */ target_ulong __pad4; /* future possible st_blocks high bits */ - target_ulong st_atime; + target_ulong target_st_atime; target_ulong __pad5; - target_ulong st_mtime; + target_ulong target_st_mtime; target_ulong __pad6; - target_ulong st_ctime; + target_ulong target_st_ctime; target_ulong __pad7; /* will be high 32 bits of ctime someday */ unsigned long long st_ino; diff -ur qemu-0.1.2/syscall.c qemu-0.1.2-s390/syscall.c --- qemu-0.1.2/syscall.c 2003-03-26 23:34:59.000000000 +0100 +++ qemu-0.1.2-s390/syscall.c 2003-03-29 04:45:12.000000000 +0100 @@ -26,6 +26,7 @@ #include <errno.h> #include <unistd.h> #include <fcntl.h> +#include <time.h> #include <sys/types.h> #include <sys/wait.h> #include <sys/time.h> @@ -40,6 +41,7 @@ #include <sys/uio.h> #include <sys/poll.h> //#include <sys/user.h> +#include <netinet/tcp.h> #define termios host_termios #define winsize host_winsize @@ -166,7 +168,7 @@ static inline fd_set *target_to_host_fds(fd_set *fds, target_long *target_fds, int n) { -#if !defined(BSWP_NEEDED) && !defined(WORD_BIGENDIAN) +#if !defined(BSWP_NEEDED) && !defined(WORDS_BIGENDIAN) return (fd_set *)target_fds; #else int i, b; @@ -188,7 +190,7 @@ static inline void host_to_target_fds(target_long *target_fds, fd_set *fds, int n) { -#if !defined(BSWP_NEEDED) && !defined(WORD_BIGENDIAN) +#if !defined(BSWP_NEEDED) && !defined(WORDS_BIGENDIAN) /* nothing to do */ #else int i, nw, j, k; @@ -256,55 +258,267 @@ return ret; } -static long do_socketcall(int num, long *vptr) +static inline void target_to_host_sockaddr(struct sockaddr *addr, + struct target_sockaddr *target_addr, + socklen_t len) +{ + memcpy(addr, target_addr, len); + addr->sa_family = tswap16(target_addr->sa_family); +} + +static inline void host_to_target_sockaddr(struct target_sockaddr *target_addr, + struct sockaddr *addr, + socklen_t len) +{ + memcpy(target_addr, addr, len); + target_addr->sa_family = tswap16(addr->sa_family); +} + +static inline void target_to_host_cmsg(struct msghdr *msgh, + struct target_msghdr *target_msgh) +{ + struct cmsghdr *cmsg = CMSG_FIRSTHDR(msgh); + struct target_cmsghdr *target_cmsg = TARGET_CMSG_FIRSTHDR(target_msgh); + socklen_t space = 0; + + while (cmsg && target_cmsg) { + void *data = CMSG_DATA(cmsg); + void *target_data = TARGET_CMSG_DATA(target_cmsg); + + int len = tswapl(target_cmsg->cmsg_len) + - TARGET_CMSG_ALIGN(sizeof (struct target_cmsghdr)); + + space += CMSG_SPACE(len); + if (space > msgh->msg_controllen) { + space -= CMSG_SPACE(len); + gemu_log("Host cmsg overflow"); + break; + } + + cmsg->cmsg_level = tswap32(target_cmsg->cmsg_level); + cmsg->cmsg_type = tswap32(target_cmsg->cmsg_type); + cmsg->cmsg_len = CMSG_LEN(len); + + if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) { + gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); + memcpy(data, target_data, len); + } else { + int *fd = (int *)data; + int *target_fd = (int *)target_data; + int i, numfds = len / sizeof(int); + + for (i = 0; i < numfds; i++) + fd[i] = tswap32(target_fd[i]); + } + + cmsg = CMSG_NXTHDR(msgh, cmsg); + target_cmsg = TARGET_CMSG_NXTHDR(target_msgh, target_cmsg); + } + + msgh->msg_controllen = space; +} + +static inline void host_to_target_cmsg(struct target_msghdr *target_msgh, + struct msghdr *msgh) +{ + struct cmsghdr *cmsg = CMSG_FIRSTHDR(msgh); + struct target_cmsghdr *target_cmsg = TARGET_CMSG_FIRSTHDR(target_msgh); + socklen_t space = 0; + + while (cmsg && target_cmsg) { + void *data = CMSG_DATA(cmsg); + void *target_data = TARGET_CMSG_DATA(target_cmsg); + + int len = cmsg->cmsg_len - CMSG_ALIGN(sizeof (struct cmsghdr)); + + space += TARGET_CMSG_SPACE(len); + if (space > tswapl(target_msgh->msg_controllen)) { + space -= TARGET_CMSG_SPACE(len); + gemu_log("Target cmsg overflow"); + break; + } + + target_cmsg->cmsg_level = tswap32(cmsg->cmsg_level); + target_cmsg->cmsg_type = tswap32(cmsg->cmsg_type); + target_cmsg->cmsg_len = tswapl(TARGET_CMSG_LEN(len)); + + if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) { + gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); + memcpy(target_data, data, len); + } else { + int *fd = (int *)data; + int *target_fd = (int *)target_data; + int i, numfds = len / sizeof(int); + + for (i = 0; i < numfds; i++) + target_fd[i] = tswap32(fd[i]); + } + + cmsg = CMSG_NXTHDR(msgh, cmsg); + target_cmsg = TARGET_CMSG_NXTHDR(target_msgh, target_cmsg); + } + + msgh->msg_controllen = tswapl(space); +} + +static long do_setsockopt(int sockfd, int level, int optname, + void *optval, socklen_t optlen) +{ + if (level == SOL_TCP) { + /* TCP options all take an 'int' value. */ + int val; + + if (optlen < sizeof(uint32_t)) + return -EINVAL; + + val = tswap32(*(uint32_t *)optval); + return get_errno(setsockopt(sockfd, level, optname, &val, sizeof(val))); + } + + else if (level != SOL_SOCKET) { + gemu_log("Unsupported setsockopt level: %d\n", level); + return -ENOSYS; + } + + switch (optname) { + /* Options with 'int' argument. */ + case SO_DEBUG: + case SO_REUSEADDR: + case SO_TYPE: + case SO_ERROR: + case SO_DONTROUTE: + case SO_BROADCAST: + case SO_SNDBUF: + case SO_RCVBUF: + case SO_KEEPALIVE: + case SO_OOBINLINE: + case SO_NO_CHECK: + case SO_PRIORITY: + case SO_BSDCOMPAT: + case SO_PASSCRED: + case SO_TIMESTAMP: + case SO_RCVLOWAT: + case SO_RCVTIMEO: + case SO_SNDTIMEO: + { + int val; + if (optlen < sizeof(uint32_t)) + return -EINVAL; + val = tswap32(*(uint32_t *)optval); + return get_errno(setsockopt(sockfd, level, optname, &val, sizeof(val))); + } + + default: + gemu_log("Unsupported setsockopt SOL_SOCKET option: %d\n", optname); + return -ENOSYS; + } +} + +static long do_getsockopt(int sockfd, int level, int optname, + void *optval, socklen_t *optlen) +{ + gemu_log("getsockopt not yet supported\n"); + return -ENOSYS; +} + +static long do_socketcall(int num, int32_t *vptr) { long ret; switch(num) { case SOCKOP_socket: - ret = get_errno(socket(vptr[0], vptr[1], vptr[2])); + { + int domain = tswap32(vptr[0]); + int type = tswap32(vptr[1]); + int protocol = tswap32(vptr[2]); + + ret = get_errno(socket(domain, type, protocol)); + } break; case SOCKOP_bind: - ret = get_errno(bind(vptr[0], (struct sockaddr *)vptr[1], vptr[2])); + { + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + socklen_t addrlen = tswap32(vptr[2]); + void *addr = alloca(addrlen); + + target_to_host_sockaddr(addr, target_addr, addrlen); + ret = get_errno(bind(sockfd, addr, addrlen)); + } break; case SOCKOP_connect: - ret = get_errno(connect(vptr[0], (struct sockaddr *)vptr[1], vptr[2])); + { + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + socklen_t addrlen = tswap32(vptr[2]); + void *addr = alloca(addrlen); + + target_to_host_sockaddr(addr, target_addr, addrlen); + ret = get_errno(connect(sockfd, addr, addrlen)); + } break; case SOCKOP_listen: - ret = get_errno(listen(vptr[0], vptr[1])); + { + int sockfd = tswap32(vptr[0]); + int backlog = tswap32(vptr[1]); + + ret = get_errno(listen(sockfd, backlog)); + } break; case SOCKOP_accept: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[2]); - ret = get_errno(accept(vptr[0], (struct sockaddr *)vptr[1], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[2] = size; + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + uint32_t *target_addrlen = (void *)tswap32(vptr[2]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(accept(sockfd, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_getsockname: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[2]); - ret = get_errno(getsockname(vptr[0], (struct sockaddr *)vptr[1], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[2] = size; + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + uint32_t *target_addrlen = (void *)tswap32(vptr[2]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(getsockname(sockfd, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_getpeername: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[2]); - ret = get_errno(getpeername(vptr[0], (struct sockaddr *)vptr[1], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[2] = size; + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + uint32_t *target_addrlen = (void *)tswap32(vptr[2]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(getpeername(sockfd, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_socketpair: { + int domain = tswap32(vptr[0]); + int type = tswap32(vptr[1]); + int protocol = tswap32(vptr[2]); + int32_t *target_tab = (void *)tswap32(vptr[3]); int tab[2]; - int32_t *target_tab = (int32_t *)vptr[3]; - ret = get_errno(socketpair(vptr[0], vptr[1], vptr[2], tab)); + + ret = get_errno(socketpair(domain, type, protocol, tab)); if (!is_error(ret)) { target_tab[0] = tswap32(tab[0]); target_tab[1] = tswap32(tab[1]); @@ -312,27 +526,64 @@ } break; case SOCKOP_send: - ret = get_errno(send(vptr[0], (void *)vptr[1], vptr[2], vptr[3])); + { + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + + ret = get_errno(send(sockfd, msg, len, flags)); + } break; case SOCKOP_recv: - ret = get_errno(recv(vptr[0], (void *)vptr[1], vptr[2], vptr[3])); + { + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + + ret = get_errno(recv(sockfd, msg, len, flags)); + } break; case SOCKOP_sendto: - ret = get_errno(sendto(vptr[0], (void *)vptr[1], vptr[2], vptr[3], - (struct sockaddr *)vptr[4], vptr[5])); + { + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + void *target_addr = (void *)tswap32(vptr[4]); + socklen_t addrlen = tswap32(vptr[5]); + void *addr = alloca(addrlen); + + target_to_host_sockaddr(addr, target_addr, addrlen); + ret = get_errno(sendto(sockfd, msg, len, flags, addr, addrlen)); + } break; case SOCKOP_recvfrom: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[5]); - ret = get_errno(recvfrom(vptr[0], (void *)vptr[1], vptr[2], - vptr[3], (struct sockaddr *)vptr[4], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[5] = size; + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + void *target_addr = (void *)tswap32(vptr[4]); + uint32_t *target_addrlen = (void *)tswap32(vptr[5]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(recvfrom(sockfd, msg, len, flags, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_shutdown: - ret = get_errno(shutdown(vptr[0], vptr[1])); + { + int sockfd = tswap32(vptr[0]); + int how = tswap32(vptr[1]); + + ret = get_errno(shutdown(sockfd, how)); + } break; case SOCKOP_sendmsg: case SOCKOP_recvmsg: @@ -344,11 +595,11 @@ struct iovec *vec; struct target_iovec *target_vec; - msgp = (void *)vptr[1]; + msgp = (void *)tswap32(vptr[1]); msg.msg_name = (void *)tswapl(msgp->msg_name); msg.msg_namelen = tswapl(msgp->msg_namelen); - msg.msg_control = (void *)tswapl(msgp->msg_control); - msg.msg_controllen = tswapl(msgp->msg_controllen); + msg.msg_controllen = 2 * tswapl(msgp->msg_controllen); + msg.msg_control = alloca(msg.msg_controllen); msg.msg_flags = tswap32(msgp->msg_flags); count = tswapl(msgp->msg_iovlen); @@ -361,17 +612,43 @@ msg.msg_iovlen = count; msg.msg_iov = vec; - fd = vptr[0]; - flags = vptr[2]; - if (num == SOCKOP_sendmsg) - ret = sendmsg(fd, &msg, flags); - else - ret = recvmsg(fd, &msg, flags); - ret = get_errno(ret); + fd = tswap32(vptr[0]); + flags = tswap32(vptr[2]); + if (num == SOCKOP_sendmsg) { + target_to_host_cmsg(&msg, msgp); + ret = get_errno(sendmsg(fd, &msg, flags)); + } else { + ret = get_errno(recvmsg(fd, &msg, flags)); + if (!is_error(ret)) + host_to_target_cmsg(msgp, &msg); + } } break; case SOCKOP_setsockopt: + { + int sockfd = tswap32(vptr[0]); + int level = tswap32(vptr[1]); + int optname = tswap32(vptr[2]); + void *optval = (void *)tswap32(vptr[3]); + socklen_t optlen = tswap32(vptr[4]); + + ret = do_setsockopt(sockfd, level, optname, optval, optlen); + } + break; case SOCKOP_getsockopt: + { + int sockfd = tswap32(vptr[0]); + int level = tswap32(vptr[1]); + int optname = tswap32(vptr[2]); + void *optval = (void *)tswap32(vptr[3]); + uint32_t *target_len = (void *)tswap32(vptr[4]); + socklen_t optlen = tswap32(*target_len); + + ret = do_getsockopt(sockfd, level, optname, optval, &optlen); + if (!is_error(ret)) + *target_len = tswap32(optlen); + } + break; default: gemu_log("Unsupported socketcall: %d\n", num); ret = -ENOSYS; @@ -880,7 +1157,27 @@ ret = get_errno(unlink((const char *)arg1)); break; case TARGET_NR_execve: - ret = get_errno(execve((const char *)arg1, (void *)arg2, (void *)arg3)); + { + char **argp, **envp; + int argc = 0, envc = 0; + uint32_t *p; + char **q; + + for (p = (void *)arg2; *p; p++) + argc++; + for (p = (void *)arg3; *p; p++) + envc++; + + argp = alloca(argc * sizeof(void *)); + envp = alloca(envc * sizeof(void *)); + + for (p = (void *)arg2, q = argp; *p; p++, q++) + *q = (void *)tswap32(*p); + for (p = (void *)arg3, q = envp; *p; p++, q++) + *q = (void *)tswap32(*p); + + ret = get_errno(execve((const char *)arg1, argp, envp)); + } break; case TARGET_NR_chdir: ret = get_errno(chdir((const char *)arg1)); @@ -1404,7 +1701,7 @@ case TARGET_NR_ioperm: goto unimplemented; case TARGET_NR_socketcall: - ret = do_socketcall(arg1, (long *)arg2); + ret = do_socketcall(arg1, (int32_t *)arg2); break; case TARGET_NR_syslog: goto unimplemented; @@ -1468,9 +1765,9 @@ target_st->st_size = tswapl(st.st_size); target_st->st_blksize = tswapl(st.st_blksize); target_st->st_blocks = tswapl(st.st_blocks); - target_st->st_atime = tswapl(st.st_atime); - target_st->st_mtime = tswapl(st.st_mtime); - target_st->st_ctime = tswapl(st.st_ctime); + target_st->target_st_atime = tswapl(st.st_atime); + target_st->target_st_mtime = tswapl(st.st_mtime); + target_st->target_st_ctime = tswapl(st.st_ctime); } } break; @@ -1644,17 +1941,17 @@ unsigned int nfds = arg2; int timeout = arg3; struct pollfd *pfd; - int i; + unsigned int i; pfd = alloca(sizeof(struct pollfd) * nfds); for(i = 0; i < nfds; i++) { - pfd->fd = tswap32(target_pfd->fd); - pfd->events = tswap16(target_pfd->events); + pfd[i].fd = tswap32(target_pfd[i].fd); + pfd[i].events = tswap16(target_pfd[i].events); } ret = get_errno(poll(pfd, nfds, timeout)); if (!is_error(ret)) { for(i = 0; i < nfds; i++) { - target_pfd->revents = tswap16(pfd->revents); + target_pfd[i].revents = tswap16(pfd[i].revents); } } } @@ -1859,9 +2156,9 @@ target_st->st_size = tswapl(st.st_size); target_st->st_blksize = tswapl(st.st_blksize); target_st->st_blocks = tswapl(st.st_blocks); - target_st->st_atime = tswapl(st.st_atime); - target_st->st_mtime = tswapl(st.st_mtime); - target_st->st_ctime = tswapl(st.st_ctime); + target_st->target_st_atime = tswapl(st.st_atime); + target_st->target_st_mtime = tswapl(st.st_mtime); + target_st->target_st_ctime = tswapl(st.st_ctime); } } break; diff -ur qemu-0.1.2/syscall_defs.h qemu-0.1.2-s390/syscall_defs.h --- qemu-0.1.2/syscall_defs.h 2003-03-26 23:34:59.000000000 +0100 +++ qemu-0.1.2-s390/syscall_defs.h 2003-03-29 02:36:30.000000000 +0100 @@ -19,6 +19,11 @@ #define SOCKOP_sendmsg 16 #define SOCKOP_recvmsg 17 +struct target_sockaddr { + uint16_t sa_family; + uint8_t sa_data[14]; +}; + struct target_timeval { target_long tv_sec; target_long tv_usec; @@ -49,6 +54,43 @@ unsigned int msg_flags; }; +struct target_cmsghdr { + target_long cmsg_len; + int cmsg_level; + int cmsg_type; +}; + +#define TARGET_CMSG_DATA(cmsg) ((unsigned char *) ((struct target_cmsghdr *) (cmsg) + 1)) +#define TARGET_CMSG_NXTHDR(mhdr, cmsg) __target_cmsg_nxthdr (mhdr, cmsg) +#define TARGET_CMSG_FIRSTHDR(mhdr) \ + ((size_t) tswapl((mhdr)->msg_controllen) >= sizeof (struct target_cmsghdr) \ + ? (struct target_cmsghdr *) tswapl((mhdr)->msg_control) : (struct target_cmsghdr *) NULL) +#define TARGET_CMSG_ALIGN(len) (((len) + sizeof (target_long) - 1) \ + & (size_t) ~(sizeof (target_long) - 1)) +#define TARGET_CMSG_SPACE(len) (TARGET_CMSG_ALIGN (len) \ + + TARGET_CMSG_ALIGN (sizeof (struct target_cmsghdr))) +#define TARGET_CMSG_LEN(len) (TARGET_CMSG_ALIGN (sizeof (struct target_cmsghdr)) + (len)) + +static __inline__ struct target_cmsghdr * +__target_cmsg_nxthdr (struct target_msghdr *__mhdr, struct target_cmsghdr *__cmsg) +{ + if (tswapl(__cmsg->cmsg_len) < sizeof (struct target_cmsghdr)) + /* The kernel header does this so there may be a reason. */ + return 0; + + __cmsg = (struct target_cmsghdr *) ((unsigned char *) __cmsg + + TARGET_CMSG_ALIGN (tswapl(__cmsg->cmsg_len))); + if ((unsigned char *) (__cmsg + 1) > ((unsigned char *) tswapl(__mhdr->msg_control) + + tswapl(__mhdr->msg_controllen)) + || ((unsigned char *) __cmsg + TARGET_CMSG_ALIGN (tswapl(__cmsg->cmsg_len)) + > ((unsigned char *) tswapl(__mhdr->msg_control) + + tswapl(__mhdr->msg_controllen)))) + /* No more entries. */ + return 0; + return __cmsg; +} + + struct target_rusage { struct target_timeval ru_utime; /* user time used */ struct target_timeval ru_stime; /* system time used */ -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0

Fwd: Re: Installshield.... no way!
by Davide Giannotti 29 Mar '03

29 Mar '03

Oh yeah... i have the native std*tlb files... i unpacked them from my WinXP Pro cd. I'm currently running wine without windows installation. Don't know what to say... are you sure that latests installshield work with wine? I think this is a priority task... I recompiled wine from a clean tarballz... and as i said, some apps works fine. But nothing to do with installshield.... :-( Thanks Subject: Re: Installshield.... no way! Date: Saturday 29 March 2003 11:54 From: Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> To: Davide Giannotti <davide.giannotti(a)itsplanet.com> Cc: wine-devel(a)winehq.com >>>>> "Davide" == Davide Giannotti <davide.giannotti(a)itsplanet.com> writes: Davide> I give up, after 2 days of try.. Nothing to do with some Davide> setups. I'm using latest wine on redhat 8.1 with glibc 2.3.1 Davide> recompiled for my processor (athlon xp). Davide> Apps are launched with winelauncher and the Davide> LD_ASSUME_KERNEL=2.2.5 var. set. Wine has been compiled from Davide> source, everything went fine and some apps work fine and Davide> fast. (like ms office viewers) There's no original dll or config Davide> setting or suggestion in the mailing lists that brought me Davide> further. My $800 macromedia studio hangs after extracting files Davide> and preparing the setup. So do some other apps. I'm still Davide> hanging on Windozz... :-( You don't tell about the std*tlb files, so I guess you don't have them. To state it again: The native std*tlb Files from a windows installation are nescessary for InstallShield6 application. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- ------------------------------------------------------- -- Davide Giannotti ITS Planet s.n.c davide.giannotti(a)itsplanet.com www.itsplanet.com

1 0

Installshield.... no way!
by Davide Giannotti 29 Mar '03

29 Mar '03

I give up, after 2 days of try.. Nothing to do with some setups. I'm using latest wine on redhat 8.1 with glibc 2.3.1 recompiled for my processor (athlon xp). Apps are launched with winelauncher and the LD_ASSUME_KERNEL=2.2.5 var. set. Wine has been compiled from source, everything went fine and some apps work fine and fast. (like ms office viewers) There's no original dll or config setting or suggestion in the mailing lists that brought me further. My $800 macromedia studio hangs after extracting files and preparing the setup. So do some other apps. I'm still hanging on Windozz... :-( If somebody has any idea.... thank you all guys. On Wednesday 26 March 2003 13:34, Davide Giannotti wrote: > > There's nothing i can do to make some installers work. > > I always get the > > "The installshield engine (ikernel.exe) could not be installed" message. > > > > I tried to install the dcom98, and it unpacked the files in the > > windows\system dir, and that's ok, but i don't think there was much more. > > > > When i try to install the microsoft installer (InstMsi.exe) it seems > > working, and it gives me the "succesfull installed" popup windows too... > > but i know it didn't cause it unpacks and doesn't even ask me if i want to > > proceed, it just jumps... to the end of process. > > > > And when i try to install some progs like Dreamweaver MX, i get the darn > > message above. > > > > Any suggestion? > > > > Thank you all guys > > > > P.s: The "export LD_ASSUME_KERNEL=2.2.5" command seems to work (at least > > partially). i added the line in my winelauncher script and konqueror uses > > winelauncher to start my win apps. > > Shouldn't you check for glibc version and add that line as default in the > > winelauncher script? > > -- > Davide Giannotti > ITS Planet s.n.c > davide.giannotti(a)itsplanet.com > www.itsplanet.com -- Davide Giannotti ITS Planet s.n.c davide.giannotti(a)itsplanet.com www.itsplanet.com

2 1

Re: Debugging winedbg
by Eric Pouech 29 Mar '03

29 Mar '03

Ulrich Spoerlein wrote: > Can anyone please explain this to me? every module (in the Wine sense) is create with a .init section. the code in this section is executed as soon as the module is loader (by the ELF loader). But the code in this section expects a bit of Wine environment to be already present (basically the wine executable) with preloading the .exe.so file, this code gets executed with the wine executable being loaded > And what would be the easiest way to break into gdb on DEBUG_MainLoop? add a breakpoint instruction at the start of DEBUG_MainLoop code __asm__("int 3"); would do A+ -- Eric Pouech

1 0

Some shell32 questions and pictures
by Steven Edwards 29 Mar '03

29 Mar '03

Hello, I was taking a look at the current shell32 sources from winehq and trying to see if we needed to merge in the reactos shell32 fork stuff. We have forked a small part of shell32 to be able to run the control panel application with our own dll. After doing some testing I wanted to see from you guys if our implementation was right and if it would be accepted to the winehq tree. I was wondering if this really needs to go in to the shell32 or in to the explorer clone. Thanks Steven Standard Win2k Control Panel http://mail.gleneagle.net/sedwards/control-with-win2k-shell32.jpg Now with the WINE shell32 from the current CVS you get this under Windows2000 http://mail.gleneagle.net/sedwards/control-with-wine-shell32.jpg And with the ReactOS shell32 you get this http://mail.gleneagle.net/sedwards/control-with-ros-shell32.jpg

2 1

Irc channel topic modification
by Sylvain Petreolle 28 Mar '03

28 Mar '03

Could you remove the WineX from the freenode #winehq topic, as #winex exists too ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Is it as nontrivial as it appears
by Bill Medland 28 Mar '03

28 Mar '03

I've now got to the stage where I have to look at whether it is possible for a linux process to call into windows dlls. (Don't bother telling me to use winelib to make the linux executable into a winelib one). I've never really thought too hard about it; it has always seemed to me that it ought to be quite trivial; just make sure you call the correct initialisaton functions and there you go. Indeed that has been my response on occasions on c.e.m.w and no-one had corrected me. I've just started looking at it and I get the distinct impression that due to the multiple processes and threads involved it may not be as trivial as I though. Anyone care to comment? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

2 1

WineHQ: still TODO
by Dimitrie O. Paun 28 Mar '03

28 Mar '03

Hi folks, Here is my personal TODO list for our very beautiful WineHQ site. Big Items --------- 1. Integrate Bugzilla into the site 2. Integrate AppDB into the site 3. Integrate the guids into the site Jer, silly question: Bugzilla and AppDB seem to already be written with the 'boxed' approach. I haven't looked at the code, but any fundamental reason we can't simply stick the main Bugzilla or AppDB main box into WineHQ? Medium Items ------------ 4. The Who's Who page is terribly out of date. Also, the organization with VIPs/Core/etc. sucks IMO. The page should include only the active developers, the rest should go into an Acknowledgements page. 5. Speaking of which, we're missing an Acknowledgements page. This should include significant contributors, significant corporate sponsors, funding sources. 6. The Download pages don't feel like. They should refer to the HowTo rather than duplicate the information. Also the Download/Sources is too skinny, needs more meat. 7. The HowTo needs improvements. There's a lot more stuff that we need to add to it. 8. We're missing a History page, that would put everything in context and a nice narative. Small Items ----------- 9. The Contributing page is too heavy, needs better integration with the new Fun Projects/Winelib/Janitorial pages. 10. The Sending Patches needs a bit more work. The .cvsrc link is wrong, maybe a bit more info on how to configure various email clients to not mangle patches, make it more clear that only uniffied diff is acceptable, show an example .cvsrc, how to email a patch (ChangeLog, one patch/per message, etc). Stuff we've been discussing for so long. Tony, I know you've been doing work in this area, maybe you can look into it? 11. TODO/Fun Projects/Janitorial/Winelib pages need constant updating from my site. I'll do that. 12. The Status/UI Status page still needs some work. Help wanted. 13. Get rid of the Miscellaneous section from Status/Core Status. 14. The Search box is too low, one needs to scroll to get to it, even in high resolutions. Any other requests? BTW, why aren't WineHQ CVS commits visible on wine-cvs anymore? -- Dimi.

2 1

Re: Fix incorrect documentation
by Andreas Mohr 28 Mar '03

28 Mar '03

Hi, On Fri, Mar 28, 2003 at 04:35:36PM +0000, Mike Hearn wrote: > I'm surprised nobody caught this one in my previous (duff) patch... the > "uninstaller" app appears to have been forgotten about. Well, I'd caught this in my update, but your version is somewhat better. Applied it ;-) I'm *almost* done with that stuff... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

RE: fix compiling of libs/wine/loader.c on NetBSD
by Patrik Stridvall 28 Mar '03

28 Mar '03

> On Thu, Mar 27, 2003 at 09:12:58PM +0200, Yorick Hardy wrote: > > It seems the stdint. header file should be included for > > compiling on NetBSD. > > This reminds me: Into which deep hole did Patrik disappear? In the deep hole of having other things to do. :-) Don't worry, I will be back.

1 0

Re: Java in wine?
by Dan Kegel 28 Mar '03

28 Mar '03

Mike wrote: > Perhaps a bit offtopic, but my company has asked me to try and get a > desktop java app we use/are developing here running under Linux. You'd > think, being written in Java, that it'd just be a case of installing the > JVM and running it. Unfortunately, because Java is rather poor at > desktop apps, they've used a load of windows extensions via JNI to try > and make it integrate better. > > That means, the only solution is probably to run a JVM under Wine (short > of rewriting all the native code, which they don't want to do). Now, I > tried the Sun JRE, and it wasn't happy. I expect HotSpot does some wierd > stuff under the covers. So I'm wondering if anybody has walked this road > before, and if there are any other JVMs that might work better under > Wine? What version of Java does the app require? I wonder if perhaps some older Sun JREs run better on Wine than hotspot does. I haven't tried any, but who knows, it might be worth trying. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 15

Contributing page needs fixing
by Mathew McBride 28 Mar '03

28 Mar '03

Web Site matenence: "We are in the process of redoing the web site and we really could use some help. The current beta is located at http://lostwages.winehq.org Here is the current list of bugs that needs attention: 597, 598, 600, 601, 605, 607, 608.If you would like to offer assistance with web maintenace feel free to contact Wine-Develipmont <mailto:wine-devel@winehq.com>." 1) lostwages. 2) D-e-v-e-l-o-p-m-e-n-t Oh, add a link to the mailing lists in the menu if you can.

1 0

Re: I/O Completion Ports (1 of 2)
by Alexandre Julliard 28 Mar '03

28 Mar '03

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > +static int io_completion_send_data( struct thread *thread, void *cookie, struct io_completion_data * data ) > +{ > + struct io_completion_send_data_reply reply; > + int ret; > + > + reply.cookie = cookie; > + reply.signaled = STATUS_SUCCESS; > + reply.bytes_transferred = data->bytes_transferred; > + reply.completion_key = data->completion_key; > + reply.overlapped = data->overlapped; > + if ((ret = write( get_unix_fd( thread->wait_fd ), &reply, sizeof(reply) )) == sizeof(reply)) > + return 0; You cannot send different message sizes into the wait_fd pipe, this won't work since pipes don't preserve message boundaries. I'd suggest simply using the normal wait mechanism and then doing a separate call to retrieve the rest of the info. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Any DCOM experts?
by Bill Medland 28 Mar '03

28 Mar '03

On March 27, 2003 12:48 pm, Gregory M. Turner wrote: > On Thursday 27 March 2003 01:08 pm, Bill Medland wrote: > > Hi guys > > > > For the next part of the work I am doing I am trying to figure out if > > there is any way that the DCOM part of one of our products is going to > > work under Wine at the server end. > > > > I am not having much success so far and I was wondering if anyone knows > > whether this is because I don't have things set up properly or if it is > > because of some inherent known lack of functionality. > > > > To start the ball rolling I was working with MSDN's DCOMTST test program > > pair. > > > > I managed to get that working using the local server (after adding the > > definition of IStream to the registry) but am having no luck getting the > > client under Wine to talk to the server under Win98. In fact the client > > side doesn't even seem to send out a single TCP/IP packet. > > There is no implementation of the TCP/IP transport at this time. Wine will > fail to make interprocess calls without any indication of this failure in > some cases. Frankly, I'm pleasantly surprised to hear that even DCOMTST > works. Ah, yes. But the local DCOMTST case is only going to use named pipes or something. And I am actually using the native dlls. And I know that I can use the native rpc across the net (using the "simple" sample program) > The RPC implementation in wine is not up to par yet. DCOM needs RPC to do > it's dirty work, so interprocess RPC is very shaky, and interprocess > between wine and real windows is non-existant. > > The good news is that there are people working on this, in particular, Ove > Kaaven and myself, although we are not exactly making headlines with our > earth-shaking progress at this moment. The bad news is that getting wine > to talk to windows via RPC is a pretty distant target right now; there are > lots of "lower hanging fruit" that will presumably be addressed first. > > > (Aside - Nice demonstration of lazy Microsoft code; in their error > > reporting they call FormatMessage, ignore the return code and somehow > > print the returned error message, even when one hasn't been allocated; I > > guess it only works under Windows because the print routine traps the > > access violation) > > or maybe the thing was supposed to be allocated and wine didn't do it > properly. Always presume wine is at fault, not Microsoft; you will usually > be correct, especially in DCOM territory! No. If a function has a return code that indicates failure then you should test for that failure and not blithely continue as if everything was OK. They call FormatMessage, asking for FormatMessage to allocate the returned string. If nothing else, it could fail to allocate memory in which case it would be stupid to use the "returned pointer" which is just whatever happened to be on the stack at the time. And I noted it failing on Windows too; the printf or whatever simply stopped processing half-way along the format string. > > I am currently running native ole32 and native rpcrt4. > > Then you are really using Microsoft's DCOM implementation, and not wine's. > Which may not be a bad choice if you want it to "just work" Yes please > as much as > possible. I have successfully used native ole32 and rpcrt4 to talk to SQL > server via the MMC interface, quite a bit of RPC involved. It didn't work > too well, but it was interesting to see it work at all. Hm. So something at least is possible (i.e. it is possible to get ole32 to put tcpip packets across the wire) > > The builtin rpcrt4 fails on a call to unimplemented > > RpcServerInqDefaultPrincName but I don't understand why it is even > > calling that; why does it think I have Netware only and why does it think > > this is a server process. > > This is another unimplemented chunk of DCOM: the RPC name services do not > exist. Samba and dce rpc have this feature so it's not unattainable... but > it ain't there yet. The name services and other networked DCOM services > require priveleged ports that wine can't even use without some kind of > medium-scale reconceptualization of the basic wine security model anyhow... > it's easy to imagine reasonable solutions to that too, but it will take > some thought... > > > Anyone an expert in any of this stuff? > > Yes, but unfortuantely, they all seem to work for Microsoft ;) Seriously, > some of it is undocumented, some of it is well documented. There are > probably only a handful of people in the world who could answer some of the > hard questions without reverse-engineering the answers, and they probably > do work for Microsoft. So for wine, we must read the specs and reverse > engineer the rest. It's not a pretty landscape and you will need to be > patient, but I believe there is a light at the end of the tunnel. Good to know. Unfortunately it isn't my patience we are talking about. Do you know of any decent low level documentation that I could read that would explain why the native OLE doesn't even appear to be trying to hit the network? BTW, on the subject of specs, create_marshalled_proxy includes a reference to a figure at MSDN. Unfortunately the link is out of date. Any idea what it is a reference to? I had a quick look through the 1999 MSJ articles but didn't see anything obvious. Also, if I get bored and can find a few hours I was going to correct the arrangement of CoCreateInstance and CoCreateInstanceEx and tighten up the CoGetClassObject order of testing; does that conflict with anyone? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

1 0

Re: fix compiling of libs/wine/loader.c on NetBSD
by Joerg Mayer 27 Mar '03

27 Mar '03

On Thu, Mar 27, 2003 at 09:12:58PM +0200, Yorick Hardy wrote: > It seems the stdint. header file should be included for > compiling on NetBSD. This reminds me: Into which deep hole did Patrik disappear? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want ist just stuff that works. Some say that should read Microsoft instead of technology.

1 0

Re: PATCH: Make.rules.in
by Dimitrie O. Paun 27 Mar '03

27 Mar '03

On Wed, 26 Mar 2003, Gerald Pfeifer wrote: > In the FreeBSD port of Wine I inherited the following and > /usr/include/features.h on my Debian systems states > > _THREAD_SAFE Same as _REENTRANT, often used by other systems. > > so I'd like to propose the following. On FreeBSD these two are not > exactly synonyms (yet?), and on Linux it doesn't hurt anybody. Well, it does make the compiler command line longer and uglier. In this case, a configure test would work a bit better I believe. -- Dimi.

1 0

Re: TreeView notifications fix (take 2)
by Mike Hearn 27 Mar '03

27 Mar '03

Hi Alexandre, Any reason this wasn't applied, or is it still in the queue? On Wed, 2003-03-19 at 14:08, Mike Hearn wrote: > As per Dimis suggestion, here is a more streamlined version of the > patch. > > ChangeLog: > > - Make IsWindowUnicode check dialog wndprocs -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

5 11

2 things with the new library system
by Steven Edwards 27 Mar '03

27 Mar '03

1. I'm getting this error in the current cvs - patch is at the end of the message isolation@PH33R /g/src/wine-dev/wine/libs/wine $ make dllwrap --def ./wine.def -o libwine.dll config.o debug.o errno.o ldt.o loader.o -L../../libs/port -lwine_port -lmsvcrt libwine.exp(.edata+0xa4):fake: undefined reference to `wine_errno_location' libwine.exp(.edata+0xcc):fake: undefined reference to `wine_h_errno_location' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [libwine.dll] Error 1 2. I can build wrc, winebuild, widl and etc but when I go to run these programs they are bitching about not being able to fund NULL. It seems that dllwrap and gcc dont like having our dlls not have a library name in the .def file. If I add LIBRARY libwine_unicode.dll or LIBRARY libwine.dll to the proper file then all is great. My question is will this break Unix? with a .so or will LD just not care about this? cvs diff -u wine.def Index: wine.def =================================================================== RCS file: /home/wine/wine/libs/wine/wine.def,v retrieving revision 1.1 diff -u -r1.1 wine.def --- wine.def 23 Mar 2003 00:28:53 -0000 1.1 +++ wine.def 27 Mar 2003 20:09:55 -0000 @@ -27,7 +27,6 @@ wine_dll_unload wine_dlopen wine_dlsym - wine_errno_location wine_get_config_dir wine_get_cs wine_get_ds @@ -37,7 +36,6 @@ wine_get_server_dir wine_get_ss wine_get_user_name - wine_h_errno_location wine_ldt_alloc_entries wine_ldt_alloc_fs wine_ldt_copy __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com

1 0

Re: building a windows API database
by David Miller 27 Mar '03

27 Mar '03

Hi, I have attached the script I am working on for this project. It is not finished. Currently it will ignore APIs with no name or ordinal ### simply because I haven't figured out how to handle them yet. There seems to be a general consensus on wine-devel we don't need a MySQL database so I am working toward a text file solution instead. I do think MySQL could be useful though if someone made a nice interface to query the database. Any help, comments, and suggestions are always welcome. :) Currently this script will: locate dlls and dump import and/or export information with dumpbin cross reference imports in an HTML map parse the dumped exports and try to determine the status of each API based on entries in the wine .spec files. If you do not have access to perl on a windows system and dumpbin (from visual C++) I can provide sample output. At 11:35 AM 3/25/2003 -0800, you wrote: >Hi, I am interested in your project of >having an API database. > >I am building it, storing the information >in a server (MySQL), in order to retreive >from it any information about apis >and their relationship with other apis >and constants. > >I don't know if you have something yet, >and would like to share with you >the project. > >Greetings... > >__________________________________________________ >Do you Yahoo!? >Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! >http://platinum.yahoo.com

2 1

new site nit
by Dan Kegel 27 Mar '03

27 Mar '03

It would be nice if the site recognized normal URLs without the ?page= prefix. That ought to be easy to hack up. The extra verbiage makes links posted in news articles look ugly. Where's the code so I can fix it? I can't see it at http://cvs.winehq.com/cvsweb/ for some reason... I thought the site's code was in cvs... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 8

Wine, win4lin, vmware, bochs, plex86 can we build an alternative Windows yet ?
by Jacobus Erasmus 27 Mar '03

27 Mar '03

Hi, I've been following the Wine development for years now. I was surprized when I learned of vmware and win4lin being able to run Windows. After some investigation it seems that they have consentrated on a simpler task that of building a virtual machine that can run Windows on top of linux. Wine on the other hand is concentrating on replacing Windows a much harder task. My question to the Wine comminuty is this ? Whithout stopping the current development would it be possible to build a striped down wine version that can run most Windows apps if you have windows available and are willing to install it in our Wine Virtual Environment. Given that Wine already contains most of the code to read and use DLL's. Most of the drivers is already available what would it take to setup such a wine version. (Interim solution ) -- Jacobus Erasmus <jacobus(a)kewlconcepts.co.za> Kewlconcepts

3 2

Transient registry entries?
by Mike Hearn 27 Mar '03

27 Mar '03

Hi, My app reads the registry to figure out network information, in particular it queries the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards\] key to discover network cards, then [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] to figure out the IP address of each one (this program can bind to multiple adaptors). These entries don't exist in Wine, and clearly they should be generated from the system configuration. There are three places that could be done: a) In initial setup, ie when you install Wine b) At Wine startup c) On demand, ie by writing special cases into the registry access code. Which of these is the one that should be used? Some stuff, like the IP address, can presumably be retrieved from other API calls, but other things, like the adaptors in the system might require new code to query the kernel. Has anybody got any tips? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: treeview click notification
by Alexandre Julliard 27 Mar '03

27 Mar '03

Mike Hearn <m.hearn(a)signal.qinetiq.com> writes: > Alexandre - I noticed my last treeview patch wasn't applied, I have been > diffing against old copies rather than CVS.... is it that my patches are > no longer applying cleanly? If so, then I'll resubmit when I have CVS > access again. If there was a problem with the patch, could you please > say what it was so I can fix it now, while I have time? It's still in the queue. I can't apply all patches on the day I receive them; sometimes I simply don't have time for another compile/test/commit round that day, sometimes I wait a bit to leave other people a chance to comment, etc. If one of your patches is dropped by all means ask me about it, but please give me at least a few days before assuming it was dropped. Thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

server/signal.c portability issue
by Gerald Pfeifer 27 Mar '03

27 Mar '03

Unfortunately, the new server/signal.c doesn't seem to be portable: wine/server% make /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -D__WINESRC__ -D_REENTRANT -o signal.o signal.c signal.c: In function `do_sigio': signal.c:201: structure has no member named `si_fd' I'd love to provide a patch, but I have now idea what it should looke like. :-( If that helps, here is siginfo_t on FreeBSD 4.8: : typedef struct __siginfo { int si_signo; /* signal number */ int si_errno; /* errno association */ /* * Cause of signal, one of the SI_ macros or signal-specific * values, i.e. one of the FPE_... values for SIGFPE. This * value is equivalent to the second argument to an old-style * FreeBSD signal handler. */ int si_code; /* signal code */ int si_pid; /* sending process */ unsigned int si_uid; /* sender's ruid */ int si_status; /* exit value */ void *si_addr; /* faulting instruction */ union sigval si_value; /* signal value */ long si_band; /* band event for SIGPOLL */ int __spare__[7]; /* gimme some slack */ } siginfo_t; #endif /* _P1003_1B_VISIBLE */ Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

1 0

Re: wrc: -a -C -w
by Alexandre Julliard 27 Mar '03

27 Mar '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > The -w options wanted to be merged into the -O option. > It makes sense: we want to control the input and output > format independently, and what better way than through > already existing -J and -O option? I don't mind removing -w, but it would be nice if you could also fix the makefiles so that things compile <g> -- Alexandre Julliard julliard(a)winehq.com

2 1

[RFC] wrc: remaining TODOs
by Dimitrie O. Paun 27 Mar '03

27 Mar '03

Folks, Few things remain before I'm satisfied with the state of wrc. Here is a list of them: -- the -B option: I think this is a the wrong interface. The Win32 API has been ported to Big Endian machines IIRC, and there is no point allowing people to mock with alignment like so: it opens up a BIG can of worms for future support and maintenance. And I don't see how it can be useful -- the Wine code assumes a certain endianess, and that's exactly what wrc should output. NOTE: Of course, I just realized that the argument holds as long as the .res format has a fixed endianess on all platform. I hope it does. Anyone cares to enlighten me? -- we may need a -r option for compatibility with rc. rc used to have a -r option, it is now ignored for backwards compatibility. Anyone know if this is old enough that we can safely ignore? Up to what version was the option required? It is curretly used in the Mozilla source, so we were wondering if we could remove it from there as well. -- the -m option. rc doesn't have it, why do we need it? We are using it in the Wine tree, do we really need it? Personally, I'd be happier if we could get rid of it, so we don't depend on Wine-only extensions. -- I would like to add a -U option (undefine), for compatibility with rc. In fact, wpp should support it as well, for compatibility with cpp. That's it. Any more ideas? I would like to get this out of the way soon, any comments or suggestions are most welcome. -- Dimi.

3 4

Winemaker : problem with wrc -J ?
by Sylvain Petreolle 27 Mar '03

27 Mar '03

Trying to compile the test application from bug #1338, running 'make' gives me the wrc usage message. I paste the command run by make and the generated Makefile. I used 'winemaker .' to create configure and so on. [syl@snoop MaximizeBox]$ make sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' ./wineapploader.in >wineapploader || rm -f wineapploader LD_LIBRARY_PATH=":$LD_LIBRARY_PATH" /usr/local/bin/wrc -J -m -I. -I/usr/local/include/wine/windows -o About2.res About2.rc /usr/local/bin/wrc: invalid option -- J ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

(1st) Implement msvcrt._wfullpath
by Sylvain Petreolle 27 Mar '03

27 Mar '03

Taking _fullpath as a model, I implemented msvcrt._wfullpath (patch attached). My unique problem : it makes use of an internal helper called msvcrt_fln_fix, which I dont understand. It seems to work without it, so I think its useful only in specific cases. Could someone explain what it does ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

wine-20030318 and C0000005 errors
by Paul McNett 27 Mar '03

27 Mar '03

I'm not sure what the change was, but handling of fatal errors appears to have gotten much better in the past month. I'm primarily using Visual Foxpro in Wine, and C0000005 errors happen in various places in both Windows and Wine when using Visual FoxPro. Up until recently, Wine would hang with the C5 and I'd have to kill it manually. Now, Wine exits cleanly after I say "ok" to the C5 dialog box. -- Paul McNett - p(a)ulmcnett.com Hollister, California, USA

1 0

Re: Java in wine?
by David.Goodenough＠DGA.co.uk 26 Mar '03

26 Mar '03

There are always at least two threads, because of the garbage collection which runs on a separate thread. I do not think any if the JVMs run the gc synchnonously. David Sylvain Petreolle <spetreolle@yahoo To: Mike Hearn <m.hearn(a)signal.qinetiq.com>, Wine Devel .fr> <wine-devel(a)winehq.com> Sent by: cc: wine-devel-admin@ Subject: Re: Java in wine? winehq.com 26/03/2003 17:13 youpi youpi yay ! --- Mike Hearn <m.hearn(a)signal.qinetiq.com> a écrit : > It seems that if WinVer is set to nt40, java runs happily (although > not > without issues of course). > > Uwe found it was due to threading some time ago, I think wine stores > something at the wrong place. I still get warnings about stack > guards, > but they don't seem to cause issues. even when running hello world or CUI class ? :) > Next problem - java appears to use DirectDraw? It wipes out the > screen > contents in the same way QuickTime did when using DirectDraw, which > obviously gets in the way of working with the app :) > > More debugging needed.... > > ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: question about commdlg
by Mike Hearn 26 Mar '03

26 Mar '03

I see. So basically Win2K only has one button, which gives a drop down for switching between list/details view, whereas we have 2 buttons. I suppose if there's an app that depends on this difference, it makes sense to implement the drop down button, and space things out so they are like on 2K. One alternative would be to make the button a toggle, rather than a drop down menu, that'd probably be easier. I wouldn't bother doing a fully fledged Win2K dialog with the sidebar, although it's up to you of course. On Wed, 2003-03-26 at 19:54, Maxime Bellengé wrote: > Here is a screenshot of the win2k open dialog, you can see 4 buttons > whereas in wine (like in win9x) you have 5 buttons with space between. > So if wine is set up as win2k, WineHex places the button too far on the > left. The button overlaps with the toolbar because it is too large. > > > > > On Wed, 2003-03-26 at 20:33, Mike Hearn wrote: > > What are the extra buttons? > > > > If an app depends on it, and looks wrong without it, then I guess you > > should make it dependant on the Windows version. If we always used a W2K > > dialog, then if WinVer was set to 9x the app would get confused. > > > > On Wed, 2003-03-26 at 18:06, Maxime Bellengé wrote: > > > I was wondering why the "default mode" button in the open file dialog of > > > WinHex was misplaced. > > > I figured out that WinHex places this button according to the version of > > > Windows. If you run WinHex in win98 or win2k mode with wine, you can see > > > that the button is not at the same location. > > > It comes from the fact that the toolbar does not have the same amount of > > > buttons. > > > > > > Thus, as I asked once, I am wondering if we should have a win2k like > > > open/save file dialog box. > > > > > > I plan to add the missing stuffs in commdlg so I am wondering if I > > > should add a win2k behavior or do nothing because there are too few apps > > > that use that feature. > > > > > > Max

1 0

question about commdlg
by Maxime Bellengé 26 Mar '03

26 Mar '03

I was wondering why the "default mode" button in the open file dialog of WinHex was misplaced. I figured out that WinHex places this button according to the version of Windows. If you run WinHex in win98 or win2k mode with wine, you can see that the button is not at the same location. It comes from the fact that the toolbar does not have the same amount of buttons. Thus, as I asked once, I am wondering if we should have a win2k like open/save file dialog box. I plan to add the missing stuffs in commdlg so I am wondering if I should add a win2k behavior or do nothing because there are too few apps that use that feature. Max -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

2 1

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