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