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

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