wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Visual-MinGW
by Dimitrie O. Paun 21 Nov '02

21 Nov '02

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@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@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 21 Nov '02

21 Nov '02

> 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 21 Nov '02

21 Nov '02

*** 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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

> ÔÚ 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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

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 21 Nov '02

21 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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@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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

> ÔÚ 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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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 20 Nov '02

20 Nov '02

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel