November 2002 - Wine-Devel - list.winehq.org

winewrapper
by Dimitrie O. Paun Nov. 22, 2002

Nov. 22, 2002

Folks, Another problem developing Winelibs app while using your Wine tree. Say you have the following: -- a Winelib app you're working on -- a Wine tree you're working on -- you compile wine out-of-tree Now, say you build your myapp.exe.so OK, and you now want to create a symlink myapp -> winewrapper so you can start your Winelib app. Problem is that winewrapper resides in the source tree, and there is no way for it to figure out where the build tree is, and it needs that. Possible solution: -- have winewrapper somehow in the Wine build tree. One way to do that is to rename winewrapper to winewrapper.in, and generate winewrapper at build time -- link to the winewrapper in the build tree -- modify winewrapper slightly so that it looks where is resides, and if it's in the wine tree, is should try to use that to run the app. Alexandre, what do you say? -- Dimi.

4 13

Re: wine/tools wineinstall
by Dustin Navea Nov. 22, 2002

Nov. 22, 2002

On Thu, 2002-11-21 at 17:46, Alexandre Julliard wrote: > ChangeSet ID: 6362 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/11/21 17:46:06 > > Modified files: > tools : wineinstall > > Log message: > Matthew Davison <m.davison(a)virgin.net> > Remove obsolete --enable-opengl. > > Patch: http://cvs.winehq.com/patch.py?id=6362 > > Old revision New revision Changes Path > 1.47 1.48 +1 -1 wine/tools/wineinstall > > > I'm not totally sure that this should be done as my wine install comes with opengl disabled due to relying on libpthread for thread safety. If we remove the --enable-opengl from wineinstall FLC's will not know how to enable it... -Dustin

2 1

__int64
by Dimitrie O. Paun Nov. 22, 2002

Nov. 22, 2002

Hmm, Another header problem. When compiling Putty with Wine's headers, I get this errors: In file included from /home/dimi/dev/wine/wine.src/include/msvcrt/wchar.h:12, from wcwidth.c:9: /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:42: parse error before "__int64" /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:42: warning: no semicolon at end of struct or union /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:44: parse error before '}' token /home/dimi/dev/wine/wine.src/include/msvcrt/io.h:60: parse error before "__int64" ... Reason is that __int64 is not defined. Now, this happens when I compile a file that has only one include: #include <wchar.h> As a quick hack, I've added this: typedef long long __int64; to include/msvcrt/sys/types.h, but it doesn't look like the right fix. We define __int64 in here: include/basetsd.h:#define __int64 long long but why a define and not a typedef? Should we include this file from one of the msvcrt header files? I really don't like doing that, but than again, I don't know much about the organization of our headers, or most importantly, the way MS does it... -- Dimi.

4 7

PuTTY update
by Dimitrie O. Paun Nov. 21, 2002

Nov. 21, 2002

Folks, Here's a quick status update on PuTTY as a Winelib app: 1. It compiles, links, and runs perfectly (Yay!) 2. I've talked to the PuTTY folks, and they agreed to add Winelib as one of their targets in their build process (provided I do the patch :)) 3. I've modified they Makefile-generation Perl scrip to do just that. What is missing: 1. The winspool issue I've sent earlier is bugging me. They link against -lwinspool, we require -lwinspool.drv This is very awkward to implement, and my patch would become a lot more intrusive (and maybe unacceptable). We need to fix this on our end, so we're compatible. 2. The winewrapper thing I've just sent out. I can't send them a bunch (they generate like 7 apps) of silly wrapper scrips, that'd be ridiculous. Help in resolving these issues would be greatly appreciated. I'd like to send them the patch sooner rather than later, so that (1) they don't change their mind, and (2) I don't forget what I was doing! :) -- Dimi.

2 2

Seperating winelibs from main wine ( was "Winelib support" )
by Mark Hannessen Nov. 21, 2002

Nov. 21, 2002

Mmmm.. Doesn't sound like a basic windows app. I do not know any windows program that uses putty and there are plenty linux/unix alternatives. but it might be usefull to some people. ( i don't know anyone ) perhaps it is time to seperate all the winelib progs from the main wine package and create a winelib package. just how knows what people in the future might write. paint / control panel / media player / calculator / etc... comments please Mark Hannessen On Thursday 21 November 2002 10:50, wine-devel-request(a)winehq.com wrote: > Hi folks, > > I'm one of the Wine (http://www.winehq.org) developers, > and I just managed to build Putty under Winelib. That > is, Putty now runs as a native Linux application. > > The interesting part is that I've managed to do so with > virtually no changes to the source code, just a few > changes to the makefile.cyg file. > > Now, my question to you: are you interested in supporting > Putty under Wine, as a Winelib app? If so, I can clean up > my changes, and send you a patch for the build system to > incorporate in your tree.

7 13

[Fwd: Re: Wine developers want Pegasus Mail as a 'Gold' app]
by Rick Romero Nov. 21, 2002

Nov. 21, 2002

I contacted David Harris, author of Pegasus Mail, and here's what he had to say. I am totally lost when it comes to the windowing stuff, I'm not sure what's X and what's Windows. Hopefully that can help a little.. I know the patches thread was really self-explanatory, but was centered on the app being iconified. I don't know that this is really any different, but it just seems more of a 'hiding the taskbar' and not iconifying the app. Or am I just stubborn/thick-headed? (well, I am :) The "Setup Wizard" was something I thought would be good to have, but at this point, I think David would have to remove the actual file open code from Pegasus for it to work. HTH. Rick -----Forwarded Message----- From: David Harris <David.Harris(a)pmail.gen.nz> To: Rick Romero <rick(a)valeoinc.com> Subject: Re: Wine developers want Pegasus Mail as a 'Gold' app Date: 22 Nov 2002 10:52:12 +1300 On 21 Nov 2002 at 11:59, Rick Romero wrote: > I apologize for the direct email, I had hoped that a Win-PM list posting > would be sufficient, but it unfortunately hasn't been. Alas, I don't read any of the public lists any more - with more than 300 messages a day to deal with just on the local accounts, I simply don't have time. > But let me get right down the the issues. I was hoping you could give > me some insight into the workings of Pegasus Mail so that the Wine guys > could easily implement any Windows API's that you might be using, that > are missing from Wine. Please consider my mailbox open at any time of the day for this - both yourself and any Wine developer who would like to contact me directly. Given that I simply don't have the resources to produce my own Linux version of Pegasus Mail at this stage, Wine assumes considerable importance for me, so any collaboration offers clear mutual benefits. > The first, critical issue, has to do with hiding the taskbar entry. > The option: "Hide the Pegasus Mail taskbar entry when minimized" which > is on by default, causes Wine to not refresh the window after > minimizing, or changing virtual desktops. A one-line fix for Wine DOES > exist, (Essentially, the flag WS_VISIBLE is not checked within Wine) but > I was hoping you could give us a little more info on what flag you may > set on that checkbox, or if it's just a flag at all, or a quick couple > lines of code.. It's not as clean or tidy as a couple of lines of code - there are some messages involved, but overall it's pretty simple. When Pegasus Mail gets a WM_SIZE message with wParam set to SIZE_MINIMIZED, it simply calls ShowWindow (hWndFrame, SW_HIDE); where "hWndFrame" is the main WinPMail frame window. There's a little other cruft in there as well, but nothing that would affect this. Under Windows, the effect of this is to remove the application from the taskbar. That's really all there is to it. The preferences checkbox merely sets a preference field which is queried later when the application is actually minimized - it has no other immediate function when it is checked. > The second issue is just for user convienance. We've found that Pmail > checks for a physical winsock.dll (wsock32.dll for Wine), and if that > exists, it enables TCP/IP. What still doesn't occur though, is the > Internet Setup Wizard. A fresh install, with wsock32.dll existing, (We > assume) should start the Wizard upon startup. That doesn't happen, > Pegasus works just fine, but doesn't start the wizard for the new user. > Are there any other checks you make to start that wizard up? Looking through the code, it appears to me that the following conditions need to be true before the Internet Setup Wizard will run: 1: It must be the first time the program has ever run for this user (i.e, there needs to have been no PMAIL.INI file present in the mailbox when the program started). 2: The commandline -Z (flags) switch must not have bit 0 set (i.e, it cannot have "1" as one of its bit members) - this disables TCP/IP altogether. 3: The User's POP3 server, POP3 username and POP3 password must all be zero-length (i.e, not yet defined) internally. 4: The bit member 0x20000 must not be set in the -Z (flags) commandline switch (this bit simply disables the setup wizard). 5: The program must be able to locate WSOCK32.DLL in any of the usual places where LoadLibrary would look (the Windows System directory, the Windows directory, the path, the current directory). Note that the check in step 5 is unintentionally quite extensive - the file not only has to be present, but Pegasus Mail actually has to be able to open it for reading (this is because I have a general-purpose file existence checking routine that attempts to make sure that the file not only exists, but can be opened, and I use that as part of the process of searching for a DLL). Aside from (all) that, I can't see anything else in there that might cause the setup wizard not to run. -- If there were some reliable way that I could determine that I was running under Wine, I would be *happy* to add code to the program that gave it specific behaviours in that environment - all you need to do is tell me what behaviours you need modified, and how I can detect Wine. Cheers! -- David -- ------------------ David Harris -+- Pegasus Mail ---------------------- Box 5451, Dunedin, New Zealand | e-mail: David.Harris(a)pmail.gen.nz Phone: +64 3 453-6880 | Fax: +64 3 453-6612 Real newspaper headlines from U.S. papers: MAN HELD OVER GIANT L.A. BRUSH FIRE -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

1 0

Minor AIM bug
by Dustin Navea Nov. 21, 2002

Nov. 21, 2002

Hey now that I got AIM running, (have to copy from a windows install and force wine to use that winver) I noticed 2 small bugs.. Both are related to comctl32 AFAICT... 1) When going to sign on, the controls think that the left mouse button is pushed always, and so when you move the mouse over the screen name it selects it, that is more of a feature IMO, as it makes it easier to switch screen names 2) When resizing the chat windows, there is a significant amount of lag moving the controls, like you resize the window, but the controls all move a lot slower than the window does, hard to describe but if anyone wants a screenshot I can post one somewhere... -Dustin

1 0

PostMessage and NULL HWND's
by steve.lustbader＠philips.com Nov. 21, 2002

Nov. 21, 2002

PostMessage fails if you pass in NULL as the HWND argument. According to the MSDN, a NULL HWND means "The function behaves like a call to PostThreadMessage with the dwThreadId parameter set to the identifier of the current thread." Currently, PostMessage tries to get the thread id of the hwnd, which of course fails since it's NULL in this case, and of course the error is Invalid Window Handle. It seems like a simple fix is a test if hwnd is NULL and calling PostThreadMessage with the right thread ID, but I don't know how to get the current thread's ID. Any ideas/suggestions? -Steve

2 1

RE: Adding -lc when linking?
by Patrik Stridvall Nov. 21, 2002

Nov. 21, 2002

> Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > > > How should this be solved (in a portable way)? > > Adding -lc seems the right way. In fact I committed that fix last > night ;-) Yes I noticed. :-) However, it doesn't seem to be the 100% correct fix. DLLs using pthreads like the ones depending on OpenGL needs to link with -lc_r instead of -lc on FreeBSD. ---8<--- gcc -shared -Wl,-Bsymbolic,-z,defs d3d8.spec.o basetexture.o cubetexture.o d3d8_main.o device.o directx.o indexbuffer.o resource.o surface.o swapchain.o texture.o vertexbuffer.o volume.o volumetexture.o d3d8.dll.dbg.o -o d3d8.dll.so -L../../dlls -L../../library -lwine -L../../ole -lwine_uuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -lm -lc /usr/lib/libgcc.a(_eh.o): In function `__empty': _eh.o(.text+0x9e): undefined reference to `pthread_setspecific' /usr/lib/libgcc.a(_eh.o): In function `__get_eh_info': _eh.o(.text+0xec): undefined reference to `pthread_key_create' _eh.o(.text+0x1b9): undefined reference to `pthread_getspecific' _eh.o(.text+0x1d8): undefined reference to `pthread_setspecific' /usr/lib/libgcc.a(frame.o)(.text+0x44b): undefined reference to `pthread_mutex_lock' /usr/lib/libgcc.a(frame.o)(.text+0x492): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__register_frame_info': frame.o(.text+0x8d9): undefined reference to `pthread_mutex_lock' frame.o(.text+0x900): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__register_frame_info_table': frame.o(.text+0x969): undefined reference to `pthread_mutex_lock' frame.o(.text+0x990): undefined reference to `pthread_mutex_unlock' /usr/lib/libgcc.a(frame.o): In function `__deregister_frame_info': frame.o(.text+0x9dc): undefined reference to `pthread_mutex_lock' frame.o(.text+0xa27): undefined reference to `pthread_mutex_unlock' frame.o(.text+0xa4d): undefined reference to `pthread_mutex_unlock' *** Error code 1

3 2

Re: COM Enhancement patch
by John K. Hohm Nov. 21, 2002

Nov. 21, 2002

> Well, I was hoping some of the COM experts would comment on that. If > I understand it right you are avoiding writing some thunking routines > for older interfaces, at the cost of an extra pointer access in every > function. I'm not convinced it's a good trade-off, but I'd like to > hear other opinions. I might not exactly be an expert, but I don't like the extra work being done everywhere with the extra pointer. If writing the thunk functions is really so cumbersome, perhaps a macro for generating the thunk functions is in order.

3 2

re: RFC: console & curses
by Dan Kegel Nov. 21, 2002

Nov. 21, 2002

Eric wrote: > N2: one could try running wineconsole USER backend with ttydrv instead > of x11drv, but that's out of the scope of this (maybe for Dimi's fun > projects list ttydrv is not as far out as all that. I use ttydrv now to run commandline windows programs that output to stdout. I *cannot* use the current Debian wine, because *it uses curses*. Curses renders commandline windows programs useless. Imagine a program that outputs two lines of text. With Wine switching to the alternate text screen on entry, and switching back on exit, *you never see those lines of text, ever*. And with those escape characters gunking up the output, you certainly can't pipe the output of wine running that console program to a file and get anything sensible. Please help make wine safe for running commandline programs from the unix shell - let us select 'ttydrv, no curses' easily somehow! I'm tired of having a separate .wine directory for console programs, and I'm tired of debian's wine (and possibly also the main tree) breaking commandline programs so badly. - Dan

3 4

winspool
by Dimitrie O. Paun Nov. 21, 2002

Nov. 21, 2002

Folks, On windows people link to winspool as such: -lwinspool In Wine, we need to do: -lwinspool.drv Obviously, this causes problems. Should we create a winspool -> winspool.drv link in dlls/? -- Dimi.

1 0

Visual-MinGW
by Dimitrie O. Paun Nov. 21, 2002

Nov. 21, 2002

Folks, After a bit of hacking, I've got the Visual-MinGW project to compile, and link just fine. Problem is that it does not run. Dies right away with a segmentation fault, so I think I've messed something up with the building part. So, to help you help me, I've included the following: -- the command lines used to build the darn thing -- the script I've created to start the program -- an attempt to run it -- the last lines of a strace on the program Help with this would be greatly appreciated. BUILDING ======== I've not included the makefile, it's irrelevant I think, as long as the actual gcc invocations are here, right? [dimi(a)dimi src]$ make g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o CList.o CList.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o editor.o editor.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o main.o main.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o process.o process.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o project.o project.cpp g++ -W -Wall -fPIC -DSTRICT -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include -I ../include -O2 -fno-rtti -D_WIN32_IE=0x0400 -c -o winui.o winui.cpp winui.cpp: In constructor `CShellDlg::CShellDlg()': winui.cpp:2062: warning: comparison between signed and unsigned integer expressions /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -W -Wall -fPIC -DSTRICT -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm SCRIPT ====== #!/bin/sh appdir="/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src" winedir="/home/dimi/dev/wine/wine" LD_LIBRARY_PATH="$winedir/dlls:$winedir/library:$winedir/unicode:$LD_LIBRARY_PATH" WINEDLLPATH="$winedir/dlls" WINESERVER="$winedir/server/wineserver" WINELOADER="$winedir/miscemu/wine" export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER # and run the application exec "$WINELOADER" "$appdir/$0.exe.so" "$@" RUNNING ======= Not very exciting, is it? :( [dimi(a)dimi src]$ ./visual-mingw Segmentation fault STRACE ====== open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw", O_RDONLY|O_LARGEFILE) = 9 ioctl(9, VFAT_IOCTL_READDIR_BOTH, 0xbfffe6d0) = -1 ENOTTY (Inappropriate ioctl for device) close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 280 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 0 close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src", O_RDONLY|O_LARGEFILE) = 9 ioctl(9, VFAT_IOCTL_READDIR_BOTH, 0xbfffe6d0) = -1 ENOTTY (Inappropriate ioctl for device) close(9) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9 fstat64(9, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(9, F_SETFD, FD_CLOEXEC) = 0 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 1160 getdents64(0x9, 0x805cfd0, 0x1000, 0x1) = 0 close(9) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT ALRM IO], [RTMIN], 8) = 0 write(4, "\24\0\0\0\0\0\0\0\0\0\0\0\30\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\6\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(6) = 0 open("/home/dimi/dev/wine/Visual-MinGW/Projects/vmingw/src/visual-mingw.exe.so", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\300\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0775, st_size=284747, ...}) = 0 old_mmap(NULL, 265292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40560000 mprotect(0x40596000, 44108, PROT_NONE) = 0 old_mmap(0x40596000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x36000) = 0x40596000 old_mmap(0x4059d000, 15436, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4059d000 close(6) = 0 open("/home/dimi/dev/wine/wine/dlls/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/library/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/unicode/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/libstdc++.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0644, st_size=76534, ...}) = 0 old_mmap(NULL, 76534, PROT_READ, MAP_PRIVATE, 6, 0) = 0x40205000 close(6) = 0 open("/usr/lib/libstdc++.so.5", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\246"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=4181584, ...}) = 0 old_mmap(NULL, 727004, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x405a1000 mprotect(0x40639000, 104412, PROT_NONE) = 0 old_mmap(0x40639000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x98000) = 0x40639000 old_mmap(0x4064e000, 18396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4064e000 close(6) = 0 open("/home/dimi/dev/wine/wine/dlls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/library/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/unicode/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/dimi/dev/wine/wine/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libgcc_s.so.1", O_RDONLY) = 6 read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\10\23\0"..., 1024) = 1024 fstat64(6, {st_mode=S_IFREG|0755, st_size=854160, ...}) = 0 old_mmap(NULL, 32288, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) = 0x40248000 mprotect(0x4024f000, 3616, PROT_NONE) = 0 old_mmap(0x4024f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 6, 0x7000) = 0x4024f000 close(6) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ -- Dimi.

4 16

RE: Adding -lc when linking?
by Patrik Stridvall Nov. 21, 2002

Nov. 21, 2002

> When compiling Wine on FreeBSD, there are tons of warnings of the > following kind (and have been that way since I can remember) which > regularily cause confusion and support requests by people building > our port: [snip] Yes, I have noticed. :-) > Alfred (Cc:ed) verified that these warnings can be eliminated by > > o getting rid of the -Wl,-Bsymbolic option (which you probably want > to keep to actually get warnings linking symbols are hosed), or > > o explicitly adding -lc. > > Would you mind making one of these changes (neither should break > GNU/Linux)? If not, how should this problem be addressed? It it is also fixed by adding --allow-shlib-undefined after -Wl,-Bsymbolic Like: -Wl,-Bsymbolic,--allow-shlib-undefined I submitted a fix doing this to Alexandre but it was rejected (or forgotten). I'm personnally not sure what is correct --allow-shlib-undefined just suppresses the warnings AFAIK. > PS: Please Cc: Alfred and me when replying, as we are not on > this list. Sure.

3 2

Disabled OpenGL (???)
by Dustin Navea Nov. 21, 2002

Nov. 21, 2002

*** Warning: the OpenGL version you have installed relies on libpthread for *** thread-safety. To prevent crashes, OpenGL support has been disabled. *** A fix for glibc 2.1.3 that seems to work is included in this version of Wine, *** start configure with '--enable-opengl' to force OpenGL support. Configure finished. Do 'make depend && make' to compile Wine. I re-ran configure and forced OpenGL, but I would like to know how to get a non-libpthread version of OpenGL if at all possible.. -Dustin

2 1

Compiling wine problem: redhat 8 libperl-devel?
by Mike Hearn Nov. 21, 2002

Nov. 21, 2002

Hi, As the prospect of having to go back to XP is looming if I can't get the adobe svg plugin working properly, I'm trying to build my own Wine, and then point CrossOver to it so stuff like IE will (hopefully) continue to work well. Unfortunately the compile dies when it tries to build winetest, as I think it needs the libperl development headers. Unfortunately I can't find an RPM of these headers anywhere, does anybody know where I could find them? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

3 3

Pegasus Mail 4.02 ('Silver' App)
by Rick Romero Nov. 21, 2002

Nov. 21, 2002

Hey all, I'm currently testing out Pegasus Mail, and I've noticed three issues that I would like to help with debugging. One issue I've found is a window refesh issue. By default Pegasus Mail will minimize to the system tray, not the taskbar. This doesn't work. Once you've minimized Pmail, or merely changed to another virtual desktop, the app window no longer responds. (the default ison - must turn off). With the window open, Pegasus Mail IS on the taskbar, only the option is checked for that to disappear if the app is minimized. After you turn the 'taskbar' setting back on, everything works fine. The second issue, I've noticed that double-clicking the system tray icon does notrestore Pegasus Mail. I can minimize it so it appears both on the taskbar and the system tray, but I can't restore the application from the system tray icon (though I can from the taskbar). You CAN right-click, and get a menu. The two menu options sort of work: New Mail information, opens a new window that has the number of new messages. Works fine. The third issue the the systray icon's 2nd menu item: Start a New Mail Message, does just that, but the window starts shrunk down. All you can see is the "Message(F8)" Tab of that window. Once you resize the window, it appears to work fine. I'm not sure if all these issues can be covered with one trace, let me know what steps you want me to take to try and resolve these issues. Thanks! Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

3 7

winsock.h problem
by Dimitrie O. Paun Nov. 21, 2002

Nov. 21, 2002

Guys, I've got the following problem: #include <winsock.h> #include <windows.h> fails miserably in Wine (but apparently works in Windows), whereas: #include <windows.h> #include <winsock.h> works, no problem. The errors I get are: In file included from /home/dimi/dev/wine/wine.src/include/windows.h:62, from /home/dimi/dev/wine/wine.src/include/winsock.h:33, from winnet.c:46: /home/dimi/dev/wine/wine.src/include/winsock2.h:401: warning: type defaults to `int' in declaration of `SOCKET' /home/dimi/dev/wine/wine.src/include/winsock2.h:401: warning: `__stdcall__' attribute only applies to function types /home/dimi/dev/wine/wine.src/include/winsock2.h:401: parse error before "WSAAccept" /home/dimi/dev/wine/wine.src/include/winsock2.h:402: parse error before "DWORD" /home/dimi/dev/wine/wine.src/include/winsock2.h:403: parse error before "DWORD" /home/dimi/dev/wine/wine.src/include/winsock2.h:406: parse error before "const" /home/dimi/dev/wine/wine.src/include/winsock2.h:412: parse error before "HANDLE" /home/dimi/dev/wine/wine.src/include/winsock2.h:416: parse error before "HANDLE" /home/dimi/dev/wine/wine.src/include/winsock2.h:417: parse error before "LPWSAOVERLAPPED" /home/dimi/dev/wine/wine.src/include/winsock2.h:423: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:424: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:428: parse error before "DWORD" /home/dimi/dev/wine/wine.src/include/winsock2.h:435: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:436: parse error before '*' token /home/dimi/dev/wine/wine.src/include/winsock2.h:438: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:439: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:440: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:443: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:444: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:445: parse error before "LPWSABUF" /home/dimi/dev/wine/wine.src/include/winsock2.h:449: warning: type defaults to `int' in declaration of `SOCKET' /home/dimi/dev/wine/wine.src/include/winsock2.h:449: warning: `__stdcall__' attribute only applies to function types /home/dimi/dev/wine/wine.src/include/winsock2.h:449: parse error before "WSASocketA" /home/dimi/dev/wine/wine.src/include/winsock2.h:450: warning: type defaults to `int' in declaration of `SOCKET' /home/dimi/dev/wine/wine.src/include/winsock2.h:450: warning: `__stdcall__' attribute only applies to function types /home/dimi/dev/wine/wine.src/include/winsock2.h:450: parse error before "WSASocketW" /home/dimi/dev/wine/wine.src/include/winsock2.h:451: parse error before "LPSOCKADDR" /home/dimi/dev/wine/wine.src/include/winsock2.h:452: parse error before "LPSOCKADDR" In file included from winnet.c:46: /home/dimi/dev/wine/wine.src/include/winsock.h:327: `SOCKET' redeclared as different kind of symbol /home/dimi/dev/wine/wine.src/include/winsock2.h:450: previous declaration of `SOCKET' -- Dimi.

2 2

Re: Office '97 install problems
by Dan Schwarz Nov. 21, 2002

Nov. 21, 2002

Boris <boris(a)thinovations.com> wrote: > I cant seem to get Office '97 installed. Setup starts up and when it > says "Searching for installed components", It says "Setup cannot > continue". What could be causing that? You're trying to install an upgrade-only version of Office '97. This version will scan your hard drive for an existing Office '95 or '97 installation, and it will abort if it doesn't find one. Satisfy this precondition or find a full version of Office '97 and you should be fine. -Dan

1 0

RE: About picture format.
by Patrik Stridvall Nov. 21, 2002

Nov. 21, 2002

> ÔÚ 2002-11-20 Èý µÄ 15:27£¬ Marcus Meissner Ð´µÀ£º > > On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote: > > > I'm using a application that using 0x0010 picture format. > I found that > > > wine only support Bitmap and JPEG picture format. Where > can I get some > > > info about it. I want to implement it. Pls give me some > hints about it. > > > > Where is it trying to use that picture format? In which API call? > fixme:ole:OLEPictureImpl_Load Unknown magic 0010 > > that is wine-20021031/dlls/oleaut32/olepicture.c OK. This only means that the first two bytes in the file is 0x10 0x00. I don't know what file format that is. But if you know what file it is trying to load you can run the Unix command file on it, perhaps it will tell what type of file it is. Otherwise you have add code in olepicture.c to handle the case 0x0010 and some code for dumping the file from there.

3 2

Office '97 and Office XP
by Boris Nov. 21, 2002

Nov. 21, 2002

I cant seem to get Office '97 installed. Setup starts up and when it says "Searching for installed components", It says "Setup cannot continue". What could be causing that? I can install Office 2000 properly but '97 wont install? Also after tinkering around with my wine configuration, [Best results is when I say im running Winme] but it tries installing but then has a problem. It would be great getting the Office '97 and XP installation working easily.

1 0

Re: Get rid of W->A calls: LoadImageW
by Huw D M Davies Nov. 21, 2002

Nov. 21, 2002

On Tue, Nov 19, 2002 at 09:10:31PM +0100, Stefan Leichter wrote: > Changelog > ------------ > replaced CreateDCA by CreateDCW in LoadImageW to Get rid of W->A calls > > Index: wine/windows/cursoricon.c > =================================================================== > RCS file: /home/wine/wine/windows/cursoricon.c,v > retrieving revision 1.56 > diff -u -r1.56 cursoricon.c > --- wine/windows/cursoricon.c 13 Nov 2002 19:43:53 -0000 1.56 > +++ wine/windows/cursoricon.c 18 Nov 2002 21:38:42 -0000 > @@ -72,6 +72,8 @@ > > static HDC screen_dc; > > +static WCHAR DISPLAYW[] = {'D','I','S','P','L','A','Y',0}; > + > /********************************************************************** > * ICONCACHE for cursors/icons loaded with LR_SHARED. > * > @@ -2052,7 +2054,7 @@ > return BITMAP_Load( hinst, name, loadflags ); > > case IMAGE_ICON: > - if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", NULL, NULL, NULL ); > + if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, NULL, NULL, NULL ); > if (screen_dc) > { > UINT palEnts = GetSystemPaletteEntries(screen_dc, 0, 0, NULL); > I don't see the point of this at all. Why does it matter that we're calling CreateDCA here? it's not as if we're losing information by converting a Unicode to an Ascii string. Huw.

2 1

Winelib support
by Dimitrie O. Paun Nov. 21, 2002

Nov. 21, 2002

Hi folks, I'm one of the Wine (http://www.winehq.org) developers, and I just managed to build Putty under Winelib. That is, Putty now runs as a native Linux application. The interesting part is that I've managed to do so with virtually no changes to the source code, just a few changes to the makefile.cyg file. Now, my question to you: are you interested in supporting Putty under Wine, as a Winelib app? If so, I can clean up my changes, and send you a patch for the build system to incorporate in your tree. BTW, the resulting executable is about 500K, so it's not that large, compared to the Windows one at 360K. -- Dimi.

1 0

Wine Doc
by Dustin Navea Nov. 21, 2002

Nov. 21, 2002

When I go to make wine docs with make html, I still receive the files that someone was getting before, looks like random numbers and letters for the filename in /wine/documentation/wine-doc... -Dustin

3 3

Re: wine/ include/x11drv.h include/config.h.in gra ...
by Michael Stefaniuc Nov. 20, 2002

Nov. 20, 2002

Hello, it seems that this patch introduced a nasty bug (at least for me). With "DesktopDoubleBuffered" = "N" wine get's a SIGSEGV, tries to start the debugger, next SIGSEGV looping forever. The SIGSEGV happens in DefaultScreenOfDisplay (X function) called from X11DRV_GDI_Initialize and that one is called by process_attach (x11drv_main.c) . Setting "DesktopDoubleBuffered" = "Y" 'fixes' the bug. Any idea? bye michael P.S.: i'll open a bug report but at the moment i'm too tired. On Thu, Nov 14, 2002 at 10:16:39PM -0600, Alexandre Julliard wrote: > ChangeSet ID: 6301 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/11/14 22:16:39 > > Modified files: > include : x11drv.h config.h.in > graphics/x11drv: opengl.c > dlls/x11drv : x11drv_main.c > dlls/opengl32 : Makefile.in > dlls/glu32 : Makefile.in > dlls/ddraw : Makefile.in > dlls/d3d8 : Makefile.in > . : configure.ac configure > > Log message: > Lionel Ulmer <lionel.ulmer(a)free.fr> > Load OpenGL library dynamically from x11drv. > > Patch: http://cvs.winehq.com/patch.py?id=6301 > > Old revision New revision Changes Path > 1.117 1.118 +3 -1 wine/include/x11drv.h > 1.132 1.133 +3 -0 wine/include/config.h.in > 1.12 1.13 +79 -22 wine/graphics/x11drv/opengl.c > 1.64 1.65 +8 -9 wine/dlls/x11drv/x11drv_main.c > 1.12 1.13 +1 -1 wine/dlls/opengl32/Makefile.in > 1.3 1.4 +1 -1 wine/dlls/glu32/Makefile.in > 1.26 1.27 +1 -1 wine/dlls/ddraw/Makefile.in > 1.3 1.4 +1 -1 wine/dlls/d3d8/Makefile.in > 1.95 1.96 +6 -3 wine/configure.ac > 1.361 1.362 +67 -4 wine/configure -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2

Installing office apps
by Anant Kabra Nov. 20, 2002

Nov. 20, 2002

Hi, I've got a windows free install of wine (Debian daily build package). I'm trying to install office apps (Office 2k - word, excel, ms project 2k), but for each I get the following behavior I go through the license key and customize installation sections fine, then it starts verifying install tasks, this gets about half way through then I get a dialog saying Internal error 2761: Contact product support for assistance. I click OK and the install terminates. Any ideas what's going on? Can I do anything else to provide more information? Thanks, -- Anant Kabra email: anant(a)yash.com phone: (210) 379-0338 (mobile)

1 0

_itoa
by Dimitrie O. Paun Nov. 20, 2002

Nov. 20, 2002

Folks, msvcrt has this in its spec file: dlls/msvcrt/msvcrt.spec:@ forward -noimport _itoa ntdll._itoa Yet at link time, I get an undefined reference error: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm project.o: In function `CProject::Open(char*, unsigned short)': project.o(.text+0x20e5): undefined reference to `_itoa' winui.o: In function `CStatusBar::WriteLong(long, int)': winui.o(.text+0x1d9a): undefined reference to `_itoa' winui.o: In function `CMessageBox::DisplayLong(long)': winui.o(.text+0x30a2): undefined reference to `_itoa' However, if I also link in ntdll, it works: /home/dimi/dev/wine/wine/tools/winebuild/winebuild -fPIC -DSTRICT -o visual-mingw.exe.spec.c --exe visual-mingw.exe -m gui -r rsrc.res CList.o editor.o main.o process.o project.o winui.o -L/home/dimi/dev/wine/wine/dlls -ladvapi32 -lole32 -lcomdlg32 -lcomctl32 -lshell32 -luser32 -lgdi32 -lkernel32 -lntdll -lmsvcrt gcc -D_WIN32_IE=0x0400 -c -o visual-mingw.exe.spec.o visual-mingw.exe.spec.c g++ -shared -Wl,-Bsymbolic visual-mingw.exe.spec.o CList.o editor.o main.o process.o project.o winui.o -o visual-mingw.exe.so -L/home/dimi/dev/wine/wine/library -lwine -lm [dimi(a)dimi src]$ Question is, is this correct? Do I need to link ntdll into the app as well? -- Dimi.

3 3

Imporving support for graphics tablets in wine (wintab.dll)
by Robert North Nov. 20, 2002

Nov. 20, 2002

Modern graphics tablets also provide pressure and tilt information, essential for quality graphics editors such as Painter & Photoshop. Currently graphics tablets are treated as mice in wine, and so cannot provide this information to a Win16/32 app. To access pressure & tilt info in Windows, a programmer would use the wintab.dll. Has anyone attempted to build a wintab.dll for Wine? I'm interested in attempting an extremely limited implementation for Painter & Photoshop, but don't want to reinvent the wheel. Assuming nobody has done this what's the first step? Raise a bug, and accept it? Bye -Rob.

4 4

Re: Win32s cleanups
by Dimitrie O. Paun Nov. 20, 2002

Nov. 20, 2002

On November 19, 2002 12:30 pm, Jukka Heinonen wrote: > File msdos/vxd.c and files dlls/win32s/* should now be the > only files which contain Win32s specific code. We should just nuke it altogether. As Ulrich explained, it's only useful for running the Win32s *subsystem* that came with some older apps. Again, that's useful not for the apps, but for the silly Win32 MS subsystem. And it's most likely broken anyway. Now, why anyone do that? What's to gain? It doesn't help anyone, it just adds bloat and confusion to the tree. And waists valuable developer time. Like yours for dealing with it, or Ulrich for explaining, or mine, or anyone following this thread. And thing is, in 2-3 months people will forget, and this will come back to haunt us. And more time will be wasted. And so on. Just get rid of it, everybody wins. -- Dimi.

2 2

RE: About picture format.
by Patrik Stridvall Nov. 20, 2002

Nov. 20, 2002

> ÔÚ 2002-11-20 Èý µÄ 18:13£¬ Patrik Stridvall Ð´µÀ£º > > > 0^80?3 2002-11-20 0?60<5 0...80?2 15:270"50...1 > Marcus Meissner 0^40...70...80?80"50?2 > > > > On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote: > > > > > I'm using a application that using 0x0010 picture format. > > > I found that > > > > > wine only support Bitmap and JPEG picture format. Where > > > can I get some > > > > > info about it. I want to implement it. Pls give me some > > > hints about it. > > > > > > > > Where is it trying to use that picture format? In which > API call? > > > fixme:ole:OLEPictureImpl_Load Unknown magic 0010 > > > > > > that is wine-20021031/dlls/oleaut32/olepicture.c > > > > OK. This only means that the first two bytes in the file is > 0x10 0x00. > > > > I don't know what file format that is. > > > > But if you know what file it is trying to load you can run the > > Unix command file on it, perhaps it will tell what type of file > > it is. > I used, but file tell: "data". That means it don't know yet. > Maybe it is > not a pic format, but why OLEPictureImpl_Load handle it, I wonder? I don't know. You need to send some sort of trace of your application if it is to be possible to determine that.

1 0

Problem with network functions
by Sylvain Petreolle Nov. 20, 2002

Nov. 20, 2002

Doing a cvs update made some programs unable to access the network. Cygwin installer and Yahoo Messenger 5.5 say both they can't initialize the network If usefull, I pasted a log of the cygwin installer with --debugmsg +wininet. trace:wininet:DllMain 0x41e40000,1,(nil) fixme:wininet:InternetAttemptConnect Stub trace:wininet:InternetOpenA trace:wininet:InternetCrackUrlA trace:wininet:GetInternetScheme trace:wininet:SetUrlComponentValue http://sources.redhat.com/cygwin/mirrors.lst (4) trace:wininet:SetUrlComponentValue (null) (0) trace:wininet:SetUrlComponentValue (null) (0) trace:wininet:SetUrlComponentValue sources.redhat.com/cygwin/mirrors.lst (18) trace:wininet:SetUrlComponentValue /cygwin/mirrors.lst (19) trace:wininet:InternetCrackUrlA http://sources.redhat.com/cygwin/mirrors.lst: host(sources.redhat.com) path(/cygwin/mirrors.lst) extra() trace:wininet:InternetConnectA ServerPort 80 trace:wininet:HTTP_Connect --> trace:wininet:HTTP_Connect <-- trace:wininet:HttpOpenRequestA trace:wininet:InternetCloseHandle 0x402d4db8 trace:wininet:HTTP_CloseHTTPSessionHandle trace:wininet:SendAsyncCallback Send Callback 70 trace:wininet:InternetQueryOptionA 0x00000009 trace:wininet:DllMain 0x41e40000,3,(nil) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Cygwin/Wine : status update
by Sylvain Petreolle Nov. 20, 2002

Nov. 20, 2002

Cygwin bash currently fails to execute due to OpenProcessToken. Looking in source, I see that advapi32.OpenProcessToken calls ntdll.NtOpenProcessToken. This functions is a stub that returns always false today. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

Screenshots
by Mike Hearn Nov. 20, 2002

Nov. 20, 2002

Hi, I'm happy to put together some screenshots on my RedHat 8 box at work (pretty much default install albiet with a slightly customised gnome2 layout). However it strikes me that having people just randomly send shots to Brian isn't the best way to go about it as nobody knows who has sent what. Have you actually got any yet Brian? If not, are there any apps you'd like to me make screenshots of? I currently have IE6 and WinZip installed, but can go install more if they are freely available on the net. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

About picture format.
by yf Nov. 20, 2002

Nov. 20, 2002

I'm using a application that using 0x0010 picture format. I found that wine only support Bitmap and JPEG picture format. Where can I get some info about it. I want to implement it. Pls give me some hints about it.

2 2

Re: the dreaded rpcss patch (rpc_J_PL0)
by Alexandre Julliard Nov. 20, 2002

Nov. 20, 2002

Greg Turner <gmturner007(a)ameritech.net> writes: > * configure; > configure.ac; > dlls/rpcrt4: .cvsignore, Makefile.in, rpc_binding.h, rpcrt4.spec, > rpcrt4_main.c, rpc_epmap.c (new); > include: rpcdce.h, rpcdcep.h, rpcndr.h, winbase.h; > include/wine: rpcss_shared.h (new); > programs: Makefile.in; > programs/rpcss (new dir): .cvsignore (new), Makefile.in (new), > README (new), atomicity.c (new), epmap_server.c (new), > named_pipe_kludge_client.c (new), named_pipe_kludge_server.c (new), > rpcss.h (new), rpcss_main.c (new): > Greg Turner <gmturner007(a)ameritech.net>, > Ove Kåven <ovek(a)transgaming.com> > - a preliminary implementation of endpoint-mapping via a new > on-demand server-ish process ("rpcss.exe.so") > - more header fixups > - (re)implement RpcEpRegisterA, RpcEpUnregister, and RpcEpResolveBinding > using the new rpcss functionality > - update the todo list in rpcrt4_main.c a bit A few things: - Please don't name files 'kludge_something'; this makes it impossible to implement things properly without renaming files. - Don't share C files between rpcrt4 and rpcss, just copy the stuff you need (and at least atomicity.c doesn't seem necessary at all, you could just as well make mutex calls directly). - Please get rid of the various #ifdefs. - It would be better to put the README documentation directly in rpcss_main.c, people don't notice README files in subdirectories. -- Alexandre Julliard julliard(a)winehq.com

2 4

Diablo II fails after a recent cvs update..
by Dustin Navea Nov. 20, 2002

Nov. 20, 2002

Going to start Diablo II after an update last night (after not updating for a couple of days) causes a crash. What debugmsgs would be needed to fix this I dunno, but I suppose I could do a regression test.. Anyone wanna take a look after I post the results of the regression test (probably some time thursday)? -Dustin

1 0

Wine merge required: COM/OLE header changes
by Ove Kaaven Nov. 20, 2002

Nov. 20, 2002

These patches are against ReWind and requires some merging work in order to apply to Wine. Could someone (hm... Greg?) do that for me? The fundamental idea here is to make sure that no files except unknwn.h ever include wine/obj_base.h directly, because the IUnknown interface definition will soon move to unknwn.h, and the API function prototypes will move to objbase.h (which indirectly includes unknwn.h through objidl.h). While I was at it, I also made sure that a couple of common to-be-IDL-generated files aren't included directly, as the headers in question have wrapper headers that are supposed to contain related API function prototypes - these prototypes will also be moved later, so I thought I might as well ensure that the wrapper headers are used now. The attached comhdr1.diff contains header changes and #ifdef guards that force a compilation error if any of these "forbidden" headers are included directly. It seems to apply to Wine as-is. (And I think the #ifdef guards should be applied to Wine even if #ifdefs aren't popular around here, because it protects against introduction of new bad code in Wine while the conversion is in progress; and when a particular header has been successfully converted, its respective #ifdef guard will of course be removed again.) The attached comhdr2.diff seems to fix all the resulting compilation errors in ReWind, and is what needs "merging". Apply as much of it as you can and fix the compilation errors that remain in Wine. Thanks.

2 1

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Still I think the code should verify that any assumptions > > made str really true, if possible. Like: > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && > > defined(HAVE_GETPWENT)) > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > There is absolutely no reason to do that, because we shouldn't assume > anything like that. As I said, if you use getpwnam() you check for > HAVE_GETPWNAM; whether getpwuid() also exists or not is completely > irrelevant. Well, the problem is it is possible that you in order to fail gracefully needs to do different things depending on whether some other function exists or not. OK, the functions meantioned above are not likely to have side effect or something else that effect the other functions in any relevant way. But there might be function pairs, tripples etc that does. Sure you can say that since any function might fail any code should always be able to handle a missing function as well since it in some abstract meaning it sufficiently similar to a normal failure. But regardless, I think it is good to make it clear that he or she who wrote expects certain things to be true and things might not work if they are not true. I somebody hits the "assertion" they can audit the code and if it seems that it doesn't matter they can modify the "assertion" to whatever is proper in the light of the new different enviroment. If it does matter they will modify the code accordingly... Somehow this seems much better than just hoping that the orginal programmer handled all error cases correctly...

1 0

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > > > Very true. Perhaps the practical way would be to assume > > HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with > > a really strange platform complains (but see below). > > There's no reason to do that, it's trivial to check for both. If you > use getpwnam() check for HAVE_GETPWNAM, if you use getpwuid() check > for HAVE_GETPWUID. Simple, logical, and works even on strange > platforms. Of course. It was so obvious that I missed it. :-) Still I think the code should verify that any assumptions made str really true, if possible. Like: #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && defined(HAVE_GETPWENT)) # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif

2 1

RE: Stub implementation of CABINET.DLL
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> >However, when I saw that not much happend despite > >getting code from cabextrect under LGPL I thought > >that perhaps people were having trouble on how > >to create a new DLL in Wine and how to extract > >the declarations from the Microsoft header without > >creating a derived work. I have done it many > >times before so thought why not do it... > > > >So I very happy that somebody is intrested in continuing. > > > >PS. If anybody have some other DLL that they wish to implement > >but don't now how to do it, don't hesitate to ask me to > >create a stub DLL with related headers. > > If it is not too much effort, could you elaborate on the > derived work issue. I have been thinking about trying to > stub out, then work at implementing, a particular component. > Rather than have someone else do the work, I am more > interested in learning about doing it myself, and about > any issues (legal and technical) involved. > I am not asking for a complete howto here, but even a > summary of the highlights would be quite valuable (to me > at least). First of all copyright doesn't protection facts or ideas only a specific (and unique) expression of facts and ideas. This is normally called a work. Specifically it doesn't protect any underlying functionally inherent or derivable from the work. This is normally called the implementation of the functionallity. Even more specifically it doesn't protect the way interaction with any functionallity, that is possible to derived from the work, is done. This is normally called the interface to the functionallity. Header files for the most part defines interfaces; more specifically constant declarations (read: defines), function declarations, type declarations and. So all such things are free for taking. However netherless the less, the header file is not entirely free of possible protected expression. Specifically: 1. Formatting 2. Comments 3. Inline functions and complex macros I will address each them in turn. Formatting is not normally any problem since there are not that many way to format C declarations, none of which is likely to be unique to Microsoft, let alone expressive. Still I always format the new file in a way I personally like, just in case. Comments are are probably the largest proplem. They are not strictly part of the interface so if you are unsure you can just remove them. In most cases, in fact the intresting cases, however they contains facts about the interface. Note however I said _contains_ facts not are facts. Part of them might be protected expression so we have to be careful here. Again, note that in order to be protected an expression have to unique as well as expressive. Most short sentences are neither unique, nor are they expressive, they just explain the facts in some straight forward way. Still if the not formulated in a way I as well would use the express myself I rewrite them. As for longer sentences and specificially multi sentence paragraphs. I usually delete or reformulate and often shorten it using my own words. The comments are, as I said, not strictly needed in for the header file to work. Inline function and complex macros can be a little tricky. However they are usually rare so rewriting them in a way I would have written it is not that much work and functinallity in itself is I said explain above not protected by copyright.

1 0

RE: Get rid of W->A calls: LoadImageW
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> > Index: wine/windows/cursoricon.c [snip] > > - if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", > NULL, NULL, NULL ); > > + if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, [snip] > I don't see the point of this at all. Why does it matter that we're > calling CreateDCA here? it's not as if we're losing information by > converting a Unicode to an Ascii string. Policy reason: "No Unicode function should call an ASCII function if a Unicode variant of that function exists." But sure semantically speaking it might not make any difference in this case.

1 0

Re: problem with treeview
by steve.lustbader＠philips.com Nov. 19, 2002

Nov. 19, 2002

Here's the output from +treeview: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger... "Dustin Navea" <Speeddymon(a)ev1. To: Steve Lustbader/ANR/MS/PHILIPS(a)AMEC net> <wine-devel(a)winehq.org> cc: 11/19/2002 03:35 Subject: Re: problem with treeview PM Classification: Try running wine with --debugmsg +treeview and post that somewhere to look at.. -Dustin ----- Original Message ----- From: <steve.lustbader(a)philips.com> To: <wine-devel(a)winehq.org> Sent: Tuesday, November 19, 2002 1:51 PM Subject: problem with treeview > My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. > A backtrace is available at http://www.lustbader.net/bt.txt, and I can > provide any other debug output if anyone thinks it will help. > TreeView_InsertItem is called like this: > > TVITEM tviFoo; > tviFoo.mask = TVIF_TEXT | TVIF_PARAM; > tviFoo.pszText = LPSTR_TEXTCALLBACK; > tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL > TVINSERTSTRUCT tvinsFoo; > tvinsFoo.hParent = TVI_ROOT; > tvinsFoo.hInsertAfter = TVI_LAST; > tvinsFoo.item = tviFoo; > HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); > > Any ideas? > > -Steve > > >

1 0

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> Am Die, 2002-11-19 um 15.17 schrieb Patrik Stridvall: > > > One thing that you shouldn't assume is for example that > > if a function exists its reentrant variant exists as well. > Sure, got that. > > > And yes, you really should use the > > reentrent variant if present as well as having an > > alternative implementation if not. > > Hmm - really really always? This generates messy code, > and a lot of effort for very rare cases. Bad formulation. What I meant is that the code shouldn't depend on the existance of the reentrant function since it is not that unlikely that some platforms might only have the non reentrent one only. Still, I think we might need such a strict policy regardless. > I think we need a compromise, something in the line of either > > - a) use non-reentrant functions, protecting them with a critical > section (IMO ok for rarely called functions) or That is potentially slow since it uses locks. Not that likely to be a problem with the getpw* functions though but still... > - b) use only reentrant and treat the case where these aren't > available like the case where the respective functions aren't > available at all. No, not a good solution. There are rational reasons to not have the reentrent variants. > Of course b) would only be viable if a sufficiently large portion of > systems that support the non-reentrant variant support the > reentrant one > as well. I have no idea whether that's the case for the getpwXYZ > functions. If are on a embedded platform it is not entirely unlikely that it is possible to configure and compile the C library to not handle reentrancy issues in order to optimize for space. In fact it might make sense be able compile Winelib as not supporting reentrency either. It is a post 1.0 issue IMHO, but we should have a policy planning for that possiblity nether the less. So strictly speaking, we should IMHO do #ifdef HAVE_GETPWUID_R /* Use getpwuid_r */ #elsif defined(HAVE_GETPWUID) # ifdef _REENTRANT /* Lock. Use getpwuid. Unlock */ # else /* Use getpwuid */ # endif #else /* Fail gracefully */ #endif However adding the #ifdef _REENTRANT is a post 1.0 issue IMHO. > > As to the implict existance question: I'm not sure. > > First of all, to answer the related question: > > Should you have a alternative implementation for > > defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? > > > > IMHO the answer is no. It is not worth the effort to > > support hypotetical platforms unless we can verify the > > existance of one. > > Very true. Perhaps the practical way would be to assume > HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with > a really strange platform complains (but see below). Assume yes, however I think the should also verify as below. > > I suggest that we should detect the presence or absence > > of ALL function we use that is verified not to exist on > > some platform and have for example code like > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + > > defined(HAVE_GETPWENT)) == 3 > > # define __HAVE_GETPW > > # else > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > > > in order to formalize the assumptions and generate a common > define to use in > > the code. > > Well I'd say that for a start we could simply do something like > > /* CAUTION: If there turns out to be some insane platform that has > * getpwuid() but not getpwnam() and getpwent(), this must be > * improved. > */ > #define __HAVE_GETPW HAVE_GETPWUID > > This would keep bloat out of configure in the first place, while > providing a generic __HAVE_GETPW macro for possible later use. As Alexandre said, having a special define is completely unnessary. Just test for existance of whatever function when you call it.

1 0

problem with treeview
by steve.lustbader＠philips.com Nov. 19, 2002

Nov. 19, 2002

My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. A backtrace is available at http://www.lustbader.net/bt.txt, and I can provide any other debug output if anyone thinks it will help. TreeView_InsertItem is called like this: TVITEM tviFoo; tviFoo.mask = TVIF_TEXT | TVIF_PARAM; tviFoo.pszText = LPSTR_TEXTCALLBACK; tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL TVINSERTSTRUCT tvinsFoo; tvinsFoo.hParent = TVI_ROOT; tvinsFoo.hInsertAfter = TVI_LAST; tvinsFoo.item = tviFoo; HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); Any ideas? -Steve

2 1

dlls/cabinet : CVS repository problem ?
by Sylvain Petreolle Nov. 19, 2002

Nov. 19, 2002

When I updated my cvs tree (update -APd), I had problems with dlls/cabinet. It didn't add the files created by this patch : http://www.winehq.com/hypermail/wine-cvs/2002/11/0179.html The directory itself is unknown in the repository : [syl(a)snoop dlls]$ cvs update 2>&1 |tee cvslog ? cabinet ? cvslog cvs server: Updating . M Makefile.in cvs server: Updating advapi32 cvs server: Updating advapi32/tests ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

msvcrt vs std incl
by Dimitrie O. Paun Nov. 19, 2002

Nov. 19, 2002

Hi guys, Here's a small test program: #include <windows.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> int main() { printf("sizeof(wchar_t)=%d\n", sizeof(wchar_t)); return 0; } And I want to compile this with our msvcrt headers. Look what happens: [dimi(a)dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:1257: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winbase.h:1258: parse error before "va_list" In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:4459: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winuser.h:4460: parse error before "va_list" In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:13:20: stdarg.h: No such file or directory In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:135: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:175: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:176: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:177: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:184: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:211: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:212: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:213: parse error before "va_list" test.c:4:20: assert.h: No such file or directory test.c: In function `main': test.c:8: `wchar_t' undeclared (first use in this function) test.c:8: (Each undeclared identifier is reported only once test.c:8: for each function it appears in.) [dimi(a)dimi wine]$ First off, are we supposed to die on the va_list stuff? Second, why is wchar_t undeclared? -- Dimi. P.S. Please do not ask why so many includes, I know they are not needed, but it should work, right?

5 11

Question: domain name
by Martin Wilck Nov. 19, 2002

Nov. 19, 2002

Using a default domain name in Wine would be beneficial for certain Netapi functions. While it's no big deal to add a config option for that, there is the Windows registry value DefaultDomainName in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon which could be used for exactly that purpose. Is it better to - use a Wine config key, - use the above MS key, - or use both, the Wine key overriding the MS one if set? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> I am thinking about some netapi32 improvements where I'd need to call > the functions of the getpw/getgr family: getpwnam(), getpwent(), > getgrent(), etc. > > Configure checks for the "pwd.h" header and getpwuid(). Must > I add more > checks for all the functions I use, or is it ok to assume that > getpwuid() presence implies getpwnam() presence? Good question. I'm don't think we have any policy concerning this. Perhaps we should have. One thing that you shouldn't assume is for example that if a function exists its reentrant variant exists as well. For example that fact getpwnam exists doesn't imply that getpwnam_r exists. And yes, you really should use the reentrent variant if present as well as having an alternative implementation if not. As to the implict existance question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the existance of one. To return to the original question: I suggest that we should detect the presence or absence of ALL function we use that is verified not to exist on some platform and have for example code like #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + defined(HAVE_GETPWENT)) == 3 # define __HAVE_GETPW # else # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif in order to formalize the assumptions and generate a common define to use in the code. Comments? Suggestions?

3 2

Re: CoInitialize
by steve.lustbader＠philips.com Nov. 19, 2002

Nov. 19, 2002

>> On 13 Nov 2002 at 14:39, steve.lustbader(a)philips.com wrote: >> >> > One of the threads in my app calls CoInitialize, expecting it >> > to return S_OK (in fact, it's followed by an assert statement >> > requiring that it returns S_OK). When I run it in Wine, however, >> > CoInitialize returns S_FALSE, implying that this thread has >> > already initialized the COM library. Other threads call >> > CoInitialize, but this is the first time that this thread calls it. >> > Does Wine initialize COM differently from Windows? Are the other >> > threads' calls to CoInitialize screwing up this thread's call? > >Sort of, the problem is that Wine doesn't support apartments yet, so it >doesn't try to keep track of the threads that has called CoInitialize. > Does this mean that COM isn't being initialized properly for the calling thread, or only that it appears not to be initialized properly? -Steve

2 1

RE: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/)
by Kye Lewis Nov. 19, 2002

Nov. 19, 2002

Hi, Has started working again for me - but I am still Puzzled as to what the problem was! Thanks, Kye Lewis kyethespy(a)liquid2k.com -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Gustavo Junior Alves Sent: Tuesday, November 19, 2002 9:49 PM To: Keith Matthews Cc: wine devel < Subject: Re: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/) The command LPRT is used for ipv6 over FTP, but I don't know any FTP servers that allow this command, maybe oftpd. Keith Matthews wrote: >On Tue, 19 Nov 2002 16:29:09 +1100 >"Kye Lewis" <kyethespy(a)liquid2k.com> wrote: > > > >>Hi, >> >>While trying to connect to the wineHQ ftp site, I am getting the >>following error with IE6: >> >>200 Type set to A. >>500 Illegal PORT command. >>500 LPRT not understood >> >> >> > >Don't know about the last error, but the illegal PORT is typically seen >when trying to use active FTP from behind a firewall that does not >support it. > >Command-line MS FTP clients don't support passive mode and I have heard >reports that IE does not also. If that is the problem you'll have to >switch to a Linux box or find a windows FTP client that supports >passive. > >

2 1