- Wine-Devel - list.winehq.org

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