- wine-devel - winehq.org

Re: Implement proxies in wininet
by Steven Edwards 14 Apr '03

14 Apr '03

--- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: > The attached patch implements proxies in wininet to an extent that at > least IE6 install works behind a firewall. > > ChangeLog: > partially implement proxy support in wininet > > This is the third time I am sending this patch. Is anything wrong with it ? I think we are starting to see we need a patch tracking system =) Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Latest wine tarball not compiling with egcs and --disable-debug
by Gabriele 14 Apr '03

14 Apr '03

Hi all, I'm trying to compile wine 20030408 with a pretty old compiler which is gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) If I run the configure scipt without passing --disable-debug and --disable-trace and then make depend && make everything builds just fine. If I disable debug and trace and then run make I get some errors. The first problem is with some defines in debug.c ../../include/wine/debug.h:84: warning: invalid character in macro parameter name ../../include/wine/debug.h:84: badly punctuated parameter list in `#define' I had to add a string before the '...' to bypass the error: #ifdef NO_DEBUG_MSGS #define WINE_WARN(arg...) do { } while(0) #define WINE_WARN_(ch) WINE_WARN #define WINE_FIXME(arg...) do { } while(0) #define WINE_FIXME_(ch) WINE_FIXME #endif The other error is the following : make[2]: Entering directory `/home/gabriele/wine-20030408/dlls/oleaut32' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -gstabs+ -fPIC -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -o typelib.o typelib.c typelib.c: In function `ITypeLib2_fnGetTypeComp': typelib.c:3393: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnReleaseTLibAttr': typelib.c:3584: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnGetLibStatistics': typelib.c:3629: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetTypeComp': typelib.c:3870: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnAddressOfMember': typelib.c:4765: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnCreateInstance': typelib.c:4778: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetMops': typelib.c:4790: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseTypeAttr': typelib.c:4828: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseFuncDesc': typelib.c:4840: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseVarDesc': typelib.c:4851: warning: unused variable `This' gcc: Internal compiler error: program cc1 got fatal signal 11 make[2]: *** [typelib.o] Error 1 make[2]: Leaving directory `/home/gabriele/wine-20030408/dlls/oleaut32' make[1]: *** [oleaut32] Error 2 make[1]: Leaving directory `/home/gabriele/wine-20030408/dlls' make: *** [dlls] Error 2

1 0

keyboard mapping with XFree86 4.3.0
by Tim Ruehsen 14 Apr '03

14 Apr '03

With XFree86 4.3.0 I experience the message fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. This is very annoying, I can't use the right alt key any more to reach characters like {,} or [. Very bad for C programming... (I use EditPlus together with wine). The Problem can be found with older versions (20020812) as with newer version (20030317). Here is my keyboard layout from XF86Config: Section "InputDevice" Driver "Keyboard" Identifier "Keyboard[0]" Option "MapName" "Standard Keyboard [ pc105 ]" Option "Protocol" "Standard" Option "XkbLayout" "de" Option "XkbModel" "pc105" Option "XkbRules" "xfree86" Option "XkbVariant" "nodeadkeys" EndSection wine -debugmsh +key,+keyboard application outputs: trace:key:X11DRV_InitKeyboard NumLockMask is 10 trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against "United States keyboard layout" trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 11, character 2 ... Any idea? Regards, Tim

4 11

Re: Fall Back to ttydrv when DISPLAY is not set
by Andreas Mohr 14 Apr '03

14 Apr '03

On Sun, Apr 13, 2003 at 08:41:04PM +0200, Uwe Bonnes wrote: > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set What about falling back to including a patch? ;-) BTW, do you print a SUFFICIENTLY LARGE warning message when doing so? Users should be aware that something "isn't ok" when this happens... (otherwise they'll keep running Wine with ttydrv and not be aware of the real reason for this behaviour, namely the missing DISPLAY variable) Anyway, since this is going towards error handling, you should make sure that people *know* what's going on instead of them confusedly deleting Wine again ;-) Andreas Mohr -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com

4 3

Re: Fall back to ttydrv when DISPLA variable not set(with patch)
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On April 13, 2003 04:35 pm, Uwe Bonnes wrote: > + { > + MESSAGE( "Falling back to ttydrv\n"); > + strcpy( buffer, "ttydrv" ); /* default value */ > + } I'm not sure this message is a good idea. What about if you don't run X, are we gonna spam people into running it? -- Dimi.

1 0

Re: UPDATED: video mode changes
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On April 12, 2003 09:34 pm, Alex Pasadyn wrote: > +#define _X_FIELD(prefix, bits) if ((fields) & prefix##_##bits) TRACE(""#bits ","); +static void _dump_CDS_flags(DWORD fields) { > + _X_FIELD(CDS,UPDATEREGISTRY);_X_FIELD(CDS,TEST);_X_FIELD(CDS,FULLSCREEN); > + _X_FIELD(CDS,GLOBAL);_X_FIELD(CDS,SET_PRIMARY);_X_FIELD(CDS,RESET); > + _X_FIELD(CDS,SETRECT);_X_FIELD(CDS,NORESET); > +} > +static void _dump_DM_fields(DWORD fields) { > + _X_FIELD(DM,BITSPERPEL);_X_FIELD(DM,PELSWIDTH);_X_FIELD(DM,PELSHEIGHT); > + _X_FIELD(DM,DISPLAYFLAGS);_X_FIELD(DM,DISPLAYFREQUENCY);_X_FIELD(DM,POSITION); > +} > +#undef _X_FIELD I still think these should return a string as I described in my previous email... Also, there is no need for such tests: > + if (TRACE_ON(x11drv)) The TRACE will take care of things nicely. -- Dimi.

1 0

Re: ALTGR Problem
by Dmitry Timoshkov 13 Apr '03

13 Apr '03

<duncan(a)semanticedge.de> wrote: > When ever I press the AltGr Key, I get the ^ sign and nothin happend > concerning the email "at" sign, the special brackets and so on. I have > a Toshiba notebook, 2430-101 with a qwertz keyboard, german layout. > Under RH everything works fine concerning the keyboard! > I'm not really familiar with keyboard settings, so editing the > keyboard.c will fail ;-) If I gonna try it with no idea what to do. Let's wait for a merge of keyboard patches from CX Office and see whether it works any better. -- Dmitry.

1 0

Re: Fall Back to ttydrv when DISPLAY is not set
by Vincent Béron 13 Apr '03

13 Apr '03

Le dim 13/04/2003 à 14:41, Uwe Bonnes a écrit : > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set You forgot the patch this time. Vincent

1 0

Re: OLE storage SetFilePointer fix
by Mike Hearn 13 Apr '03

13 Apr '03

> P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... The main problem as far as I'm concerned isn't so much the lack of a patch "tracker", I'm usually capable of keeping track of whether my patches have been applied or not by watching wine-cvs (though i've found once or twice i've missed the commit), it's more an issue of if a patch is rejected, you have to ask why. That means I'm often left thinking, is my patch simply in the queue, or is something wrong with it? Or, like my last pkgconfig patch, is there another reason it didn't go in? The way gnome/mozilla do it is to have patches put in bugzilla, but for the sheer volume of patches Wine gets with only Alexandre committing (which is fine by me), that wouldn't work. I'd be perfectly happy with the current arrangement if when a patch was dropped, a reason would normally appear on wine-devel - but then I'm not the one doing the work, Alexandre is, so it's easy for me to ask for him to do more work :/ thanks -mike

2 2

Fwd: ALTGR Problem
by Sylvain Petreolle 13 Apr '03

13 Apr '03

Welcome to the club ;-) ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: dos games, vesa and wine
by Jukka Heinonen 13 Apr '03

13 Apr '03

Enrico Horn wrote: > I tried my dos4gw games with dos32a and they "work"(except some warning dos32a > prints) but you have to run these games like this to get an result: > wine -- dos32a game.exe > thats is because the stub which loads the dos extender doesnt work and i have > no idea why. Neither dos4gw stub loader nor dos4gw itself work. Making these work would be nice, but since there are free, compatible DOS extenders available that work rather well with Wine, I'm not particularly interested to figure out what is wrong with them. I have toyed with an idea of trying to contact dos4gw authors (if I can find them) and ask them if they could help, but I'm just too lazy for this kind of stuff. > the games i use all make use of vesa > they want 640x480x256 > ddraw traces show a primary surface that is 8bit paletted. > is there any problem drawing this thing? > where is this done? > is there a routine that regularly updates the screen with content of this > surface? > i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and > havent found anything but i am not expert at this and just poke around > randomly where i see an interest. That mode should work with DOS VESA emulation. It could be that those programs use VESA features that are not supported or that VESA emulation is faulty. It is also possible that those programs are waiting for timer interrupt which is not delivered in protected mode (I have a good idea how to do this, but we shall see when I have time to implement it). See dlls/winedos/int10.c and dlls/winedos/vga.c. It is unlikely that DOS display problems are due to x11drv bugs. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

LdrGetDllHandle with FlashMX demo
by Darren Cook 13 Apr '03

13 Apr '03

Hi, When trying to run the FlashMX Demo version I got about 120 lines of: fixme:module:LdrGetDllHandle Unknown behavior, please report It then dies with "Failed to initialize Vbox! (0010-0069-0090)". I wasn't sure whether to report it in bugzilla or here as I'm not sure if you consider this a bug. So I thought I'd try here first. I'm using this version of wine: wine-20030408-1rh8winehq.i686.rpm (plus stdole32.tlb, copied from winXP machine). FlashMX demo was copied over from a winXP installation (I couldn't get the installer to run under wine). I also have a full version of FlashMX which works (well, some rough edges :-), also by copying over from winXP. If you need more information, or want me to try in debug mode, etc. let me know (I'm not subscribed to the list). Darren

2 1

Re: OLE storage SetFilePointer fix
by Marcus Meissner 13 Apr '03

13 Apr '03

On Sat, Apr 12, 2003 at 11:07:11PM +0200, Andreas Mohr wrote: > Hi all, > > the OLE storage code basically disabled itself, by doing a > READ_HEADER; > in STORAGE_get_pps_entry(). > This READ_HEADER uses -1 as block number for STORAGE_get_big_block() > (in order to retrieve the storage header block). > And if you look at the SetFilePointer() in STORAGE_get_big_block(), > you might notice that (n+1)*BIGSIZE for some strange reason evaluates > to 0, for n == -1. > Thus, SetFilePointer() seeks to position 0 to read the storage header. > > And now I'm terribly sorry to tell you that STORAGE_get_big_block() > did a > if (!SetFilePointer( hf, (n+1)*BIGSIZE, NULL, SEEK_SET )) > { > WARN(" seek failed (%ld)\n",GetLastError()); > return FALSE; > } > > Sounds like SetFilePointer() is *supposed* to return 0 if it seeks to > position 0, eh? > > In other words: > - fix blatantly wrong SetFilePointer() calls The 16bit storage code is probably not safe to work with, for instance saving is probably not working. It should call forward to the 32bit storage code, which I think is more correct. Ciao, Marcus

1 0

Re: OLE storage SetFilePointer fix
by Alexandre Julliard 12 Apr '03

12 Apr '03

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... You know, nobody prevents you from implementing a better patch tracking system, and if it makes my life easier I'll be more than happy to use it. Or if you don't want to write code, you could volunteer to manually keep track of all submitted patches and resubmit the lost ones. But of course that's a lot more work than simply complaining about it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: video mode changes
by Lionel Ulmer 12 Apr '03

12 Apr '03

Hi, I have some comments on this patch : > + if (devmode->dmFields & DM_BITSPERPEL) > + { > + if (devmode->dmBitsPerPel != GetSystemMetrics(SM_WINE_BPP)) > + continue; > + } This may cause problems... It's not per-se a problem in your patch, but from what I know Windows applications expect to have '32' on a 24/32 display and Wine stores here '24'. So you may 'refuse' some modes that should be valid. (again, if ever you have a graphic card still supporting 24/24 mode, please tell me so that I can torture your XFree libraries to find a valid way of checking the difference between 24/24 and 24/32) > + SYSMETRICS_Set( SM_CXSCREEN, devmode->dmPelsWidth ); > + SYSMETRICS_Set( SM_CYSCREEN, devmode->dmPelsHeight ); This are actually 'User' internal functions ? In that case, why not just do the resolution change in the X11 driver and let User itself handle the sysmetric change ? I.e. call these in the 'ChangeDisplaySettingsExW' function and not in the low-level graphic driver. Now my most important grief : did you think about all the people who 1) use Desktop mode and 2) disable XVidMode in their config file ? For those, applications may now abort saying 'Vidmode not supported' (whereas it was working just fine before because we accepted all modes that are smaller than the actual screen size). So I would say that if no VidMode is present or if the User driver function does not exist in the driver, the old 'stub' API should remain as it is. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 3

Re: winedos / Improve tracing
by BiGgUn 12 Apr '03

12 Apr '03

Why didn't you use TRACE instead of DPRINTF ? Stephan

1 0

Toolbar debug message
by BiGgUn 12 Apr '03

12 Apr '03

Hi How can i see debug messages from toolbar.c ? Neither '--debug-msg trace+toolbar' nor '--debug-msg +toolbar' works. The '+loaddll' option claims that i use the _builtin_ version of comctl32. I do not have no more ideas :( Stephan

2 1

Wine 0.9 TODO v0.8
by Dimitrie O. Paun 12 Apr '03

12 Apr '03

Hi folks, The next version of the 0.9 TODO is way past due (again!), and today is as good as any other day for a brand new release: http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html ChangeLog * Jer finished the WineHQ redesign (A1) * Brian completed the screenshot galery (A4) * Adam is our new Slackware maintainer (A6) * Andreas updated the User & Development Guide (B1,B3) * I took on the Packaging Guide and Winelib docu (B2,B4,B8) * New task: more modular doc building (B12) * I've updated and integrated Jaco's winecfg into the tree (C2) * John did more work on the DLL registration (C5) * Shachar got a working version of wineboot into the tree (C7) * I finished messing with wrc (D5) * I got winegcc to a working state (D6) * Marcus made the printing system detection dynamic (E3) * Eric improved WinHelp some more (E6) Please note that this version has been in the making for almost 4 month! Lot's of stuff changed, feedback is much appreciated. -- Dimi.

3 2

Re: PATCH: video mode changes
by Dimitrie O. Paun 12 Apr '03

12 Apr '03

On April 12, 2003 12:16 am, Alex Pasadyn wrote: > + if (TRACE_ON(x11drv)) > + { > + MESSAGE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);MESSAGE("\n"); > + MESSAGE(" bpp=%ld\n",devmode->dmBitsPerPel); > + MESSAGE(" width=%ld\n",devmode->dmPelsWidth); > + MESSAGE(" height=%ld\n",devmode->dmPelsHeight); > + MESSAGE(" freq=%ld\n",devmode->dmDisplayFrequency); > + } Please don't use MESSAGE. Use TRACE instead, it will do the right thing. This piece can be rewritten as: TRACE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);TRACE("\n"); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); Also, it will be a lot nicer if you rewrite _dump_DM_dields to return a string, so you can write: TRACE("\tDM_fields=%s\n", debug_DM_fields(devmode->dmFields)); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); The debug_DM_fields() function would than look like so: static const char* debug_DM_fields(DWORD fields) { BOOL first = TRUE; char buf[128] = "", *p = buf; #define DEBUG_FIELD(x) if ((fields) & DM_##x) { p += sprintf(p, "%s%s", first ? "" : " ,", #x); first = FALSE; } DEBUG_FIELD(BITSPERPEL); DEBUG_FIELD(PELSWIDTH); DEBUG_FIELD(PELSHEIGHT); DEBUG_FIELD(DISPLAYFLAGS); DEBUG_FIELD(DISPLAYFREQUENCY); DEBUG_FIELD(POSITION); #undef DEBUG_FIELD return wine_dbg_sprintf("%s", buf); } -- Dimi.

2 1

Re: Wine Packaging Guide update
by Mike Hearn 12 Apr '03

12 Apr '03

> NOTE: I am (was?) a strong believer in markup. I started this > work because I thought the document doesn't belong in the > Docu section, and needed updating, without being aware of > the potential problems with SGML. By the time I was done, > I was completely horrified by this SGML business. It has > it's advantages, but they come at a hefty price, so we > have to be very careful when we employ it. It works OK > for documents that don't require a lot of markup, like the > FAQ. In fact, in that case it _saves_ on formating markup. > It works nicely for documents that are essentially books > (such as the User Guide, etc.) where you can expect someone > to print out the nicely formatted .pdf/.ps. However, for > technical documents that need to be maintained often, and > are useful as a online resource that people are likely to > open in an editor, it blows chunks. Now I start to understand > Alexandre's preference for troff for man pages... Hehe, I'm glad I'm not the only one who thinks DocBook is overrated - I've been wrestling with it for the past few weeks as part of writing a shared packaging metadata spec, and an automatic documentation framework for bash libraries, and I have NEVER got it to work correctly. I've found that clean HTML with some small CSS can make a document that looks more professional (imo) and is far easier to read in a text editor, not least because emacs (and i assume vim) can apply the formatting in the tags to the text itself. I've never looked at troff, but free software seems to need a better documentation/markup system - DocBook SGML just seems far, far too complex for doing something that is essentially quite simple.

1 0

Re: PATCH: Winemaker's --wrap option
by Jeremy Newman 12 Apr '03

12 Apr '03

Please stop resending this message to the list. I have gotten more than 20 copies of this message now. On Tue, 2003-04-08 at 14:59, Javier López wrote: > ----- Original Message ----- > From: "Juraj Hercek" <juraj(a)syncad.com> > To: <wine-patches(a)winehq.com> > Sent: Tuesday, April 08, 2003 4:35 AM > Subject: PATCH: Winemaker's --wrap option > > > > Changelog: > > > > Juraj Hercek <juraj(a)syncad.com> > > * tools/winemaker : > > Fixed generation of makefiles and wrapper files when "--wrap" option > > is used. > > > > <snip> -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

4 3

Re: wine/dlls make_dlls Makefile.in Makedll.rules.in
by Vincent Béron 12 Apr '03

12 Apr '03

Alexandre Julliard a écrit: > ChangeSet ID: 7854 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/04/11 19:05:28 > > Modified files: > dlls : make_dlls Makefile.in Makedll.rules.in > > Log message: > Fixed rules for auto documentation (reported by Vincent Béron). > > Patch: http://cvs.winehq.com/patch.py?id=7854 > > Old revision New revision Changes Path > 1.23 1.24 +19 -0 wine/dlls/make_dlls > 1.172 1.173 +19 -0 wine/dlls/Makefile.in > 1.52 1.53 +4 -13 wine/dlls/Makedll.rules.in Not good. Won't work correctly for dlls containing subdirs with a Makefile (msacm, etc.). In those cases, only the first level directory will be processed, not the subdirs. Vincent

2 1

Provide USB support in wine ?
by Sylvain Petreolle 11 Apr '03

11 Apr '03

"Accidentally", when updating my RH system, I discovered that libusb is a library that provides user access to the USB devices, regardless of the OS. It appears we could use it in wine, since : - its license compatible (LGPL) - it supports some OSes on which wine is built. Like : Linux FreeBSD NetBSD, OpenBSD (dont know if this works now, referring to http://www.winehq.com/?page=faq#Under_what_hardware_platforms_and_Wine) Darwin (never heard of it for Wine ??) MacOS X (recent Qemu work makes this possible) Could such a support be possible/doable ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

5 4

ttydrv on a remote console
by Uwe Bonnes 11 Apr '03

11 Apr '03

Hallo, I am trying to run a complex command line (XST from Xilinx) program with X disabled, like on a remote terminal. With "GraphicsDriver" = "ttydrv" and called like "~/tmp/wine/compile/wine/wine -- /tmp/webpack-5.2/bin/nt/xst -quiet -ifn __projnav/dacswitch.xst -ofn dacswitch.syr" it soon crashes. I tracked it down to a failing WM_NCCREATE mesage in TTYDRV_CreateWindow. Returning unconditional TRUE in TTYDRV_CreateWindow makes the program run. With x11drv, called on the command line like above, wndPtr->parent is not set and the clause { create_desktop( display, wndPtr, cs ); WIN_ReleasePtr( wndPtr ); return TRUE; } is taken. Any ideas? Running with wineconsole and wcmd resulted in a scrambled screen and a crash too. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Contrib page update
by Dimitrie O. Paun 11 Apr '03

11 Apr '03

They'll be added to the Fun Projects on the next update to that page. ChangeLog Move some of the tasks to the Fun Projects where they belong. Index: templates/en/contributing.template =================================================================== RCS file: /home/wine/lostwages/templates/en/contributing.template,v retrieving revision 1.5 diff -u -r1.5 contributing.template --- templates/en/contributing.template 30 Mar 2003 15:59:45 -0000 1.5 +++ templates/en/contributing.template 11 Apr 2003 15:40:07 -0000 @@ -33,9 +33,7 @@ <ol> <li><a href="#devel_task">Some development task</a> </li><li><a href="#conf_tests">Conformance tests</a> - </li><li><a href="#cross">Cross referencing the windows executables and libraries</a> </li><li><a href="#doc_win_api">Documentation of the windows API functions</a> - </li><li><a href="#check_which">Check which APIs are missing for a given program</a> </li><li><a href="#port_app">Port your windows application to wine</a> </li><li><a href="#code_review">Perform a focused code review</a> @@ -284,24 +282,6 @@ </li></ul> - <a name="cross"></a> - <h3>Cross referencing the Windows executables and libraries</h3> - - <p>The idea is to write a Perl script that analyzes the Windows dlls and executables of a - regular Windows installation and cross references them. This would generate Web pages - telling you which API is used by which program/library and reciprocally. - Analyzing the import/export section of PE executables is quite simple: it's just a matter - of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing - the resulting text file. This already being done with the wpbtk toolkit. - To view winapi_check output see <a href="http://fgouget.free.fr/wine/winapi_stats-en.shtml">Quick API statistics</a>. - To help with this please contact <a href="mailto:fgouget@free.fr">Francois Gouget</a> - </p> - Required skills: - <ul> - <li>Perl - </li><li>General HTML - </li></ul> - <a name="doc_win_api"></a> <h3>Documentation of the Windows API functions</h3> @@ -320,28 +300,6 @@ <ul> <li>Knowledge of some documentation generation system for the person trying to enhance the documentation generation. </li><li>A bit of C to document the APIs themselves. - </li></ul> - - <a name="check_which"></a> - <h3>Check which APIs are missing for a given program</h3> - - <p>The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies - of a given executable/set of executables. Then these results can be cross-referenced with the results - of the above script to tell you which APIs this program is missing, what percentage they represent, etc. - Reciprocally one can weight each API according to how often they are referenced in a given environment to - produce an approximation of the likely hood that such an API will actually be called. Note that this would - just be an approximation because we would miss all the dynamically loaded APIs and libraries - (since we only scan the statically linked dynamic libraries). This would be an even more approximate - measure of the likely hood that the program will work: even though a program references an API it may never call it, - work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. - Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent. - </p> - Required skills: - <ul> - <li>Perl - - </li><li>General HTML to present the results - </li><li>Maybe querying a database will be necessary too </li></ul> <a name="port_app"></a> -- Dimi.

2 1

Re: Contributing: Check which APIs are missing for a given program
by Pouech Eric DMI AEI CAEN 11 Apr '03

11 Apr '03

> Would it be helpful if pedump were supported so you don't need dumpbin from Visual C++ to be able to use the scripts? winedump (in the tools directory) has some of the features of pedump A+

2 1

WineHQ: updated Fun Projects
by Dimitrie O. Paun 11 Apr '03

11 Apr '03

ChangeLog Remove the links from the title sections (visited links were invisible due to the color scheme). Small cleanups. Move the cross referencing tasks from the Contributing page. Index: templates/en/fun_projects.template =================================================================== RCS file: /home/wine/lostwages/templates/en/fun_projects.template,v retrieving revision 1.3 diff -u -r1.3 fun_projects.template --- templates/en/fun_projects.template 30 Mar 2003 16:23:41 -0000 1.3 +++ templates/en/fun_projects.template 11 Apr 2003 17:27:03 -0000 @@ -57,7 +57,6 @@ which would be <em>uber</em>cool. <h4 class=inprogress>Cygwin under Wine in Linux</h4> - This provides an a good test case for Wine. It is tough, but we do have the Cygwin source code, and we have a good chance to understand why it does not work. @@ -67,7 +66,6 @@ <li>status: runs <tt>bash -l -i</tt> and logs out <li>updated: Dec 4, 2002 </ul> - <h4 class=inprogress>Wine under Cygwin in Windows</h4> This will provide a good test case for Cygwin, but will help Wine's @@ -88,20 +86,18 @@ need to have a MinGW port on Windows (that is, they need to support building under MinGW). - <h4 class=todo><a name="jvm" href="http://java.sun.com">Java Virtual Machine</a></h4> + <a name="jvm"></a><h4 class=todo>Java Virtual Machine</h4> There are three noteworthy Java implementations: <dl> <dt><a href="http://java.sun.com/j2se/">Sun's JVM</a></dt> <dd>Unfortunately, the Windows port requires MSVC to build. How ironic.</dd> - <dt><a href="http://www.ibm.com/developerworks/java">IBM's JVM</a></dt> <dd>I can't seem to be able to find the sources for this one. Help!</dd> <dt><a href="http://www.kaffe.org">Kaffe</a></dt> <dd>This one seems to have ports to Cygwin and MinGW. Good candidate for a port.</dd> </dl> - <h4 class=todo><a name="perl" href="http://www.perl.com">Perl</a></h4> - + <a name="perl"></a><h4 class=todo>Perl</h4> Any Perl monger up for this? <ul> <li>worker: wanted @@ -112,10 +108,9 @@ <strong>Update:</strong> The ActivePerl branch support building under both Cygwin and MinGW. This is a very good test for <tt>winegcc</tt>. Unfortunately, the MinGW makefile uses backslashes as fileseparator, so it will take a bit of work to get working under Linux. - Why do people use backslash, when the forward slash works on both Windows and Linux? Eh... - - <h4 class=todo><a name="python" href="http://www.python.org">Python</a></h4> + Why do people use backslash, when the forward slash works on both Windows and Linux? + <a name="python"></a><h4 class=todo>Python</h4> Not very exciting, but still interesting port. It's a good test for the non graphic APIs, such as threading, files, etc. <ul> @@ -126,7 +121,6 @@ </ul> <strong>Update:</strong> Configure the packages like so: <pre> - CC=winegcc CXX=wineg++ configure --with-suffix --without-threads </pre> Unfortunately, configure gets confused about the executable extension, @@ -141,8 +135,7 @@ to create portable UI toolkits. Due to the large UI component of the Win32 API, these are a perfect test for Wine. - <h4 class=todo><a name="qt" href="http://www.trolltech.com/products/qt/windows.html">QT</a></h4> - + <a name="qt"></a><h4 class=todo>QT</h4> Imagine we compile QT under Wine, and then we get the entire <a href="http://www.kde.org">KDE</a> compiled and running under Wine! How cool would that be? <ul> @@ -150,7 +143,6 @@ <li>status: initial investigation <li>updated: Jan 6, 2003 <li>homepage: <a href="http://www.trolltech.com/products/qt/windows.html">www.trolltech.com/products/qt/windows.html</a> - </ul> <strong>Update:</strong> Unfortunately, QT/Windows is not free software. Moreover, it requires MSVC or the Borland toolchain to build. Before we can start thinking about @@ -159,7 +151,7 @@ <a href="http://www.troll.no">Troll's</a> part to support such an effort. If you think you can make a case for it, please let us now. - <h4 class=todo><a name="gtk" href="http://www.gtk.org">Gtk+</a></h4> + <a name="gtk"></a><h4 class=todo>Gtk+</h4> This is maybe a little less interesting than the others, as Gtk+ does not use the native widgets when ported to Windows. Instead, it uses it's very thin abstraction layer (gdk) to do the drawing, all else is build 'in house'. @@ -168,17 +160,15 @@ <li>status: todo <li>updated: Jan 6, 2003 <li>homepage: <a href="http://wingtk.sourceforge.net/">wingtk.sourceforge.net</a> - </ul> - <h4 class=done><a name="wxwindows" href="http://www.wxwindows.org">wxWindows</a></h4> + <a name="wxwindows"></a><h4 class=done>wxWindows</h4> A perfect test case for Wine's headers, and MinGW emulation! Wouldn't it be cool to have the Windows controls available on Linux too? <duck/> :-) <ul> <li>worker: <a href="mailto:dpaun@rogers.com">Dimitrie O. Paun</a> - <li>status: compiles, links, and runs! + <li class=modified>status: compiles, links, and runs! The <a href="http://www.winehq.com/hypermail/wine-devel/2003/01/0153.html">patch</a> - has been accepted in the official wxWindows tree! <li>updated: Jan 7, 2003 <li>homepage: <a href="http://www.wxwindows.org">www.wxwindows.org</a> @@ -215,7 +205,6 @@ free version available, but apparently you can buy one for around $100US. <ul> <li>worker: <a href="mailto:ps@leissner.se">Patrik Stridvall</a> - <li>status: most tests work, DLLs are pretty bad though <li>updated: Nov 29, 2002 </ul> @@ -228,7 +217,6 @@ <li>status: todo <li>updated: Jan 6, 2003 <li>homepage: <a href="http://www.borland.com/bcppbuilder/freecompiler/">www.borland.com/bcppbuilder/freecompiler</a> - </ul> <h3 class=todo>Watcom's cc</h3> @@ -252,12 +240,49 @@ <h2>Miscellaneous Projects</h2> This is a catch-all category for all sort of strange (and sometimes cute) ideas. + <a name="cross"></a><h3 class=inprogress>Cross referencing the Windows executables and libraries</h3> + <p>The idea is to write a Perl script that analyzes the Windows dlls and executables of a + regular Windows installation and cross references them. This would generate Web pages + telling you which API is used by which program/library and reciprocally. + Analyzing the import/export section of PE executables is quite simple: it's just a matter + of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing + the resulting text file. This already being done with the wpbtk toolkit. + <ul> + <li>worker: <a href="mailto:compsol@ptd.net">Dave Miller</a> + <li>status: Prototype ready + <li>updated: Apr 11, 2003 + </ul> + <strong>Update:</strong> + Currently the script can make HTML maps of the dll imports. I've been too + lazy to integrate the program that processed that into a table so + far. :) Right now it requires dumpbin (Visual C++) I plan to add pedump + or winedump support so more people are able to use it. It is also + analyzing the wine .spec files to determine if each API has an entry and + reports whether it's a stub, unimplemented (not in spec files), etc. + + + <a name="check_which"></a><h3 class=inprogress>Check which APIs are missing for a given program</h3> + <p>The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies + of a given executable/set of executables. Then these results can be cross-referenced with the results + of the above script to tell you which APIs this program is missing, what percentage they represent, etc. + Reciprocally one can weight each API according to how often they are referenced in a given environment to + produce an approximation of the likely hood that such an API will actually be called. Note that this would + just be an approximation because we would miss all the dynamically loaded APIs and libraries + (since we only scan the statically linked dynamic libraries). This would be an even more approximate + measure of the likely hood that the program will work: even though a program references an API it may never call it, + work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. + Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent. + <ul> + <li>worker: <a href="mailto:compsol@ptd.net">Dave Miller</a> + <li>status: Starting work <a href="http://www.winehq.com/hypermail/wine-devel/2003/04/0324.html">soon</a>. + <li>updated: Apr 11, 2003 + </ul> + <h3 class=inprogress>GDI Engine</h3> Integrate the GDI engine contributed by the <a href="http://www.transgaming.com">Transgaming</a> folks. <ul> <li>worker: <a href="mailto:johane@lysator.liu.se">Johan Gill</a> - <li>status: <i>It should be ready for submission in a few months from now.</i> <li>updated: Feb 22, 2003 </ul> @@ -270,7 +295,6 @@ <a href="http://bugs.winehq.com/show_bug.cgi?id=1304">Bug #1304</a>. <h3 class=todo>Wine Explorer</h3> - <p>A Windows Explorer replacement. People migrating from Windows would love it, and it would provide a great testbed for our <tt>shell32</tt> DLL, as well as some key controls such as the List-View Common Control. @@ -287,7 +311,6 @@ <li> A "Cancel" button (that changes to "Close" when tests are done) <li> A "Report..." button that brings up a "Save As..." dialog </ul> - Not hard to write, and quite cool to play with. Anyone familiar with the Win32 API can do it. -- Dimi.

1 0

winebuild incompatibility with binutils-2.13.90.0.20
by Piotr Pawłow 11 Apr '03

11 Apr '03

Hi, There is a change in "nm -u" output format in the new binutils, now it outputs "U " before every symbol name. It looks like this: $ nm -u d3d8.dll.tmp.o U cos U CreateDCA U DeleteDC U ExtEscape U GetClientRect U GetDC U GetDesktopWindow U GetDeviceCaps U GetModuleHandleA U GetProcAddress U GetPropA (...) Winebuild parser is not prepared for that. It does not find proper symbol names, creates spec.c files with no imports, and the result is that linking fails on unresolved symbols, as reported in "--with-nptl and glibc-2.3.2" thread. A quick fix: Index: tools/winebuild/import.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/import.c,v retrieving revision 1.48 diff -r1.48 import.c 664a665,667 > if (*p == 'U') { > if (p[1] == ' ') p+=2; > } Shouldn't winebuild, however, use libbfd where available, instead of relying on nm output? -- Piotr Pawłow mailto:pp@siedziba.pl

3 5

Re: CxxFrameHandler problem
by John K. Hohm 11 Apr '03

11 Apr '03

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

Re: Re: wcmd, external commands, and options
by Pouech Eric DMI AEI CAEN 11 Apr '03

11 Apr '03

> I don't think we need to change CreateProcess at all. In > my tests, Wine matched Win9x's CreateProcess behavior nicely. > All the changes we need are in wcmd, I think. > - Dan that's correct (I later checked also CreateProcess) wcmd is to blame. I may have a look afterwards at wcmd (I'm currently on a two week trip, without any Linux box at hand) A+

1 0

Wine's test process
by Eduardo Augusto Bezerra 10 Apr '03

10 Apr '03

Hi I've been working on the definition of testing processes for open source projects and, so far, Open Office is one of the most organized projects I've found. The bug tracking system of Wine is quite good, but I haven't found much about the definition of Wine's test process. I was wondering whether somebody in this discussio list could send me some pointers or documents where I could learn more about Wine's test process. Basically, I've been looking for a place where I could find answers for questions such as: How has the test process been defined in the beginning of the Wine project? How was the test process performed at that time? How was the test process performed when there were no web versions for the bug reports? Are there test plans available? My research is not based only on Wine. I've been trying to find other open source projects that have an organized and documented test process, but it's quite hard. Many thanks for any help Eduardo. -- Eduardo Augusto Bezerra, PhD Space Science Centre, School of Engineering and IT The University of Sussex, Brighton, England, UK http://www.sussex.ac.uk/engg/research_groups/space/ Researcher, Software Testing Research Centre (CPTS) PUCRS/Hewlett-Packard Brazil, Porto Alegre, RS, Brazil Lecturer in Computer Science, Informatics Faculty Catholic University (PUCRS), Porto Alegre, RS, Brazil http://www.inf.pucrs.br/~gaph Phone/Fax UK: +44 (0)1273 877086 / +44 (0)1273 678399 Phone/Fax Brazil: +55 51 3320 3695 / +55 51 3320 3758 http://www.eduardo.bezerra.name PGP signature: Key ID B852E578 Public Key: http://www.keyserver.net/en/ or http://eduardo.bezerra.name

1 0

Problem actually with binutils, oops!
by Scott Carmichael 10 Apr '03

10 Apr '03

Okay, so in any event, does anyone know when this will be fixed? Downgrading from 2.13.90.0.20 to 2.13.90.0.18 seems to fix the problem... But does anyone know why? And is this a wine problem? Or binutils? Thanks, Scott

2 1

Contributing: Check which APIs are missing for a given program
by Dave Miller 10 Apr '03

10 Apr '03

I plan to be working on this soon. It should be able to share pieces of the script which cross references dlls and will create an API database (plain text file for now). Before I get started I have a couple of questions. Do we intend to gather all this information together and keep it? In a database, in the application database, in bug reports, etc. Or is it more for a developer trying to get a specific application working? What information should exist in the API database? Currently it outputs the spec file, API name, and whether it is a stub, forward, stdcall, etc. Does anyone think more information is needed? Would it be helpful if pedump were supported so you don't need dumpbin from Visual C++ to be able to use the scripts?

1 0

dos games, vesa and wine
by Enrico Horn 10 Apr '03

10 Apr '03

Hi, Another day, another round of questions concerning this topic. I tried my dos4gw games with dos32a and they "work"(except some warning dos32a prints) but you have to run these games like this to get an result: wine -- dos32a game.exe thats is because the stub which loads the dos extender doesnt work and i have no idea why. the behaviour is the following(trace of +int21): allocate 1 block of memory resize block to 65536(this fails returnnig number of available blocks) resize block to whats available allocate 1 block of memory(this fails as all is already allocated) close all files, print error message and exit the games i use all make use of vesa they want 640x480x256 ddraw traces show a primary surface that is 8bit paletted. is there any problem drawing this thing? where is this done? is there a routine that regularly updates the screen with content of this surface? i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and havent found anything but i am not expert at this and just poke around randomly where i see an interest. Thanks for putting up with me Enrico

1 0

About new RH glinc issue
by Sylvain Petreolle 10 Apr '03

10 Apr '03

This is what I received today from Red Hat Network, maybe it could our issue. ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

0408 w/ glibc 2.3.2 still broken
by Scott Carmichael 10 Apr '03

10 Apr '03

> WHAT'S NEW with Wine-20030408: (see ChangeLog for details) > - Support for all variants of glibc 2.3. I'm still getting errors with glibc 2.3.2. The same ones I was getting with -20030318. Anyone know why this is? :) Unfortunately, the LD_ASSUME_KERNEL fix doesn't seem to work, as it seems to break everything else on my system needed to run the actual build. =\ Thanks, and the log of the fail follows... make[2]: Entering directory `/home/jobe/wine-20030408/dlls/d3d8' gcc -shared -Wl,-Bsymbolic,-z,defs d3d8.spec.o basetexture.o cubetexture.o d3d8_main.o device.o directx.o indexbuffer.o resource.o shader.o stateblock.o surface.o swapchain.o texture.o vertexbuffer.o volume.o volumetexture.o vshaderdeclaration.o d3d8.dll.dbg.o -o d3d8.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/uuid -lwine_uuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port -lm -lc basetexture.o(.text+0x281): In function `IDirect3DBaseTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' cubetexture.o(.text+0x2d2): In function `IDirect3DCubeTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' d3d8_main.o(.text+0xf4): In function `Direct3DCreate8': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' d3d8_main.o(.text+0x1ba): In function `DllMain': /home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:64: undefined reference to `GetModuleHandleA' d3d8_main.o(.text+0x1d5):/home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:67: undefined reference to `GetProcAddress' d3d8_main.o(.text+0x1f2):/home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:68: undefined reference to `GetProcAddress' device.o(.text+0x35c1): In function `IDirect3DDevice8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x385c): In function `IDirect3DDevice8Impl_GetDisplayMode': /home/jobe/wine-20030408/dlls/d3d8/device.c:1081: undefined reference to `GetSystemMetrics' device.o(.text+0x3870):/home/jobe/wine-20030408/dlls/d3d8/device.c:1082: undefined reference to `GetSystemMetrics' device.o(.text+0x38a6):/home/jobe/wine-20030408/dlls/d3d8/device.c:1085: undefined reference to `CreateDCA' device.o(.text+0x38bb):/home/jobe/wine-20030408/dlls/d3d8/device.c:1086: undefined reference to `GetDeviceCaps' device.o(.text+0x38c8):/home/jobe/wine-20030408/dlls/d3d8/device.c:1087: undefined reference to `DeleteDC' device.o(.text+0x3f77): In function `IDirect3DDevice8Impl_CreateTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x41d7): In function `IDirect3DDevice8Impl_CreateVolumeTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x42ed):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x4385):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x453a): In function `IDirect3DDevice8Impl_CreateCubeTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x47c4):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: more undefined references to `HeapAlloc' follow device.o(.text+0x110ac): In function `IDirect3DDevice8Impl_DeleteVertexShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x110cc):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x11117):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x11139):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x111a9):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x116e2): In function `IDirect3DDevice8Impl_CreatePixelShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x1195b): In function `IDirect3DDevice8Impl_DeletePixelShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' directx.o(.text+0x231): In function `IDirect3D8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' directx.o(.text+0x549): In function `IDirect3D8Impl_GetAdapterModeCount': /home/jobe/wine-20030408/dlls/d3d8/directx.c:150: undefined reference to `GetSystemMetrics' directx.o(.text+0x55b):/home/jobe/wine-20030408/dlls/d3d8/directx.c:151: undefined reference to `GetSystemMetrics' directx.o(.text+0x687): In function `IDirect3D8Impl_EnumAdapterModes': /home/jobe/wine-20030408/dlls/d3d8/directx.c:194: undefined reference to `CreateDCA' directx.o(.text+0x69c):/home/jobe/wine-20030408/dlls/d3d8/directx.c:195: undefined reference to `GetDeviceCaps' directx.o(.text+0x6a9):/home/jobe/wine-20030408/dlls/d3d8/directx.c:196: undefined reference to `DeleteDC' directx.o(.text+0x7bd):/home/jobe/wine-20030408/dlls/d3d8/directx.c:182: undefined reference to `GetSystemMetrics' directx.o(.text+0x7d1):/home/jobe/wine-20030408/dlls/d3d8/directx.c:183: undefined reference to `GetSystemMetrics' directx.o(.text+0x958): In function `IDirect3D8Impl_GetAdapterDisplayMode': /home/jobe/wine-20030408/dlls/d3d8/directx.c:228: undefined reference to `GetSystemMetrics' directx.o(.text+0x96c):/home/jobe/wine-20030408/dlls/d3d8/directx.c:229: undefined reference to `GetSystemMetrics' directx.o(.text+0x9a2):/home/jobe/wine-20030408/dlls/d3d8/directx.c:232: undefined reference to `CreateDCA' directx.o(.text+0x9b7):/home/jobe/wine-20030408/dlls/d3d8/directx.c:233: undefined reference to `GetDeviceCaps' directx.o(.text+0x9c4):/home/jobe/wine-20030408/dlls/d3d8/directx.c:234: undefined reference to `DeleteDC' directx.o(.text+0x109d): In function `IDirect3D8Impl_CreateDevice': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' directx.o(.text+0x11a7): In function `IDirect3D8Impl_CreateDevice': /home/jobe/wine-20030408/dlls/d3d8/directx.c:459: undefined reference to `GetPropA' directx.o(.text+0x11be):/home/jobe/wine-20030408/dlls/d3d8/directx.c:468: undefined reference to `GetDC' directx.o(.text+0x11ff):/home/jobe/wine-20030408/dlls/d3d8/directx.c:56: undefined reference to `ExtEscape' directx.o(.text+0x127f):/home/jobe/wine-20030408/dlls/d3d8/directx.c:480: undefined reference to `GetDesktopWindow' directx.o(.text+0x1291):/home/jobe/wine-20030408/dlls/d3d8/directx.c:480: undefined reference to `GetPropA' directx.o(.text+0x13a0):/home/jobe/wine-20030408/dlls/d3d8/directx.c:496: undefined reference to `ReleaseDC' directx.o(.text+0x143e):/home/jobe/wine-20030408/dlls/d3d8/directx.c:515: undefined reference to `GetClientRect' indexbuffer.o(.text+0x244): In function `IDirect3DIndexBuffer8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' indexbuffer.o(.text+0x264):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' resource.o(.text+0x231): In function `IDirect3DResource8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' shader.o(.text+0xc0a): In function `IDirect3DDeviceImpl_CreateVertexShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' shader.o(.text+0xc46):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function `IDirect3DDeviceImpl_CreateStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1402): In function `IDirect3DDeviceImpl_DeleteStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' stateblock.o(.text+0x14ed): In function `IDirect3DDeviceImpl_BeginStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' surface.o(.text+0x234): In function `IDirect3DSurface8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' surface.o(.text+0x254):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' swapchain.o(.text+0x231): In function `IDirect3DSwapChain8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' texture.o(.text+0x2c3): In function `IDirect3DTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' vertexbuffer.o(.text+0x237): In function `IDirect3DVertexBuffer8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' vertexbuffer.o(.text+0x269):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: more undefined references to `HeapFree' follow vshaderdeclaration.o(.text+0x6d): In function `IDirect3DDeviceImpl_CreateVertexShaderDeclaration8': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' vshaderdeclaration.o(.text+0x114):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' collect2: ld returned 1 exit status make[2]: *** [d3d8.dll.so] Error 1 make[2]: Leaving directory `/home/jobe/wine-20030408/dlls/d3d8' make[1]: *** [d3d8] Error 2 make[1]: Leaving directory `/home/jobe/wine-20030408/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install.

1 0

Re: Opening AVI files in Wine
by Tom Hibbert 10 Apr '03

10 Apr '03

On Wed, Apr 09, 2003 at 11:45:07AM -0500, wine-devel-request(a)winehq.com wrote: > From: Pouech Eric DMI AEI CAEN <pouech-eric(a)wanadoo.fr> > Reply-To: pouech-eric(a)wanadoo.fr > To: Tom Hibbert <cartel(a)cryptocracy.hn.org>, wine-devel(a)winehq.com > Subject: Re: Opening AVIs with wine > Date: Wed, 9 Apr 2003 18:31:03 +0200 (CEST) > > Please can someone tell me if it is possible for a wine application > > to open an avi file (or better yet use video for windows codecs). > in generic terms yes. > however, avi is an enveloppe to store video files, but the compression used can vary from file to file > so, you need the specific decompressor to handle a given type of file > normally, wine is ready (under the MCI and the msvfw32 interfaces at least) to play AVI files > however, to get further with your issue, we need to know : > 1/ which interface your program actually uses (MCI, msvfw, directx...) > 2/ which codecs are installed and configured under wine > 3/ the type of compressor used for your file > (btw, does changing the avi file to play changes also what is output - or not output in your case) Hi Pouche, thanks for your quick reply! Combustion uses the Video for Windows interface to open AVIs. The VFW interface is abstracted through a plugin in combustion's plugin system. When i use a native msvfw32.dll the overlays inside the app dissapear and some of the buttons fail to render which is a Bad Thing.. perhaps i need to use some other native supporting libraries in order to use native msvfw32, any suggestions? As for which codecs are installed and configured, I'm not sure how to tell. I've looked in the registry but cant find much. I have installed the DivX codec but thats about all I have done purposefully. The format of the files I want to open is Type 2 DVAVI. Selecting other types doesnt change my output. This is all getting confusing.. I am reading at http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp that Microsoft provide interfaces for Type 2 DVAVI only, and only for direct show. This is consistent with Combustion's inability to read Type 1 files (under windows of course). Does DirectShow = vfw32? Sorry for the insanely confusing response, Tom

2 1

Re: [RFC] direct sound notify patch
by Alexandre Julliard 10 Apr '03

10 Apr '03

Robert Reif <reif(a)earthlink.net> writes: > Adding a hardware notify introduces the use a new GUID from > dsdriver.h. I had to add initguid.h to get it to compile but is this > the proper thing to do? Should this file be added to libs/uuid? Yes it should be in libuuid, initguid.h should not be used. Also your patch doesn't compile because of references to the removed notifies fields, you probably forgot some files. -- Alexandre Julliard julliard(a)winehq.com

1 0

make htmlpages does not work - regression?
by thomas.mertes＠gmx.at 10 Apr '03

10 Apr '03

Hello I noticed that "make htmlpages" does not work in Wine-20030408 but in Wine-20030318. The problem seems to be in some makefile or configure change since /dlls/Makedll.rules.in still contains the "Rules for auto documentation". but the actual Makefile does not. I have in the moment no time to fix it myself (or search the patch that made this change). Btw. the documentation system is great, but I think that only a few people know that it exists. To start it (according to Jon Griffiths): Run ./configure, make htmlpages, point your browser at documentation/html/index.html, then immediately start sending patches for documentation glitches :-) The interesting dlls (with many docomented functions) are shlwapi.dll and ntdll.dll. Greetings Thomas -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

2 1

Re: Re: wcmd, external commands, and options
by Pouech Eric DMI AEI CAEN 10 Apr '03

10 Apr '03

> On WinMe, it looks like > start/wait notepad.exe > invokes start with the /wait option, but in Wine, > it invokes start\wait.exe. you mean from command.com, keying start/wait does what you do I think we should test if CreateProcess on WinXX does the same or not I suspect CreateProcess to implement an algorithm like: n = 1 a/ take the n first chars of the command line if we can match this with an exec, then run it, and chars from command line from n+1 to end of line are arguments (which get parsed with spaces and rtabs as delimiters) otherwise, increment n and go to a/ wine current implementation is a bit more rustic in a sense that our loop is only made of using spaces as separator for implementing the a/ loop the first thing to do IMO is to add this test case to our create process list A+

2 1

Re: Re: Opening AVI files in Wine
by Pouech Eric DMI AEI CAEN 10 Apr '03

10 Apr '03

> Combustion uses the Video for Windows interface to open AVIs. The VFW > interface is abstracted through a plugin in combustion's plugin > system. When i use a native msvfw32.dll the overlays inside the app dissapear > and some of the buttons fail to render which is a Bad Thing.. perhaps > i need to use some other native supporting libraries in order to use native > msvfw32, any suggestions? > > As for which codecs are installed and configured, I'm not sure how to tell. I've looked in the registry but cant find much. I have installed the DivX codec but thats about all I have done purposefully. > > The format of the files I want to open is Type 2 DVAVI. Selecting other types > doesnt change my output. > > This is all getting confusing.. I am reading at > > http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp > > that Microsoft provide interfaces for Type 2 DVAVI only, and only for direct show. This is consistent > with Combustion's inability to read Type 1 files (under windows of course). Does DirectShow = vfw32? there are several and different interfaces in windows to play AVI files : - msvfw32 - MCI - direct show the first are not so badly implemented right now, whereas the latest is close to non existent running with-debugsmg +msvfw,mciavi might help sheding some light on the matter A+

1 0

Starcraft Patch
by John Spiegel 10 Apr '03

10 Apr '03

I've done some work getting the patches from http://starcraft-wine.sourceforge.net/ working with CVS wine. Using the patch I'm including, starcraft works perfectly on my machine, run as root using DGA on a 640x480 XF86 layout. In particular the changes to event.c enable the mouse and keyboard with DGA. The changes to input.c make the mouse acceleration work the same in all directions. The changes to mouse.c enable mouse scrolling around the map. I'm using redhat 9, so the patch also has a change to wineinstall so that the configure is set up for rh9. You'll probably need to drop that if you aren't running rh9. Now, it would be great to get these changes merged into mainline wine. However, I imagine they break other stuff somewhere. I don't really know exactly what the changes mean, as I've mostly been converting an old patch over. I believe that the patch to input.c is simple and straightforward enough to be merged in, even if the others aren't. Any comments as to what needs to happen to get these into wine are greatly appreciated. John

1 0

Starcraft Patch
by John Spiegel 10 Apr '03

10 Apr '03

I've done some work getting the patches from http://starcraft-wine.sourceforge.net/ working with CVS wine. Using the patch I'm including, starcraft works perfectly on my machine, run as root using DGA on a 640x480 XF86 layout. In particular the changes to event.c enable the mouse and keyboard with DGA. The changes to input.c make the mouse acceleration work the same in all directions. The changes to mouse.c enable mouse scrolling around the map. I'm using redhat 9, so the patch also has a change to wineinstall so that the configure is set up for rh9. You'll probably need to drop that if you aren't running rh9. Now, it would be great to get these changes merged into mainline wine. However, I imagine they break other stuff somewhere. I don't really know exactly what the changes mean, as I've mostly been converting an old patch over. I believe that the patch to input.c is simple and straightforward enough to be merged in, even if the others aren't. Any comments as to what needs to happen to get these into wine are greatly appreciated. John

1 0

wcmd, external commands, and options
by Dan Kegel 10 Apr '03

10 Apr '03

I noticed tonight while looking for a different problem that wcmd doesn't handle batch file lines consisting of an external command with options but no space between the commandline and the option, e.g. start/wait foo.exe In this case it does not find start.exe. Win98 does find start.exe in this case, and wcmd clearly should, too. I had a quick look at wcmdmain.c, and did the obvious hack --- wcmdmain.c 5 Mar 2003 02:49:04 -0000 1.26 +++ wcmdmain.c 9 Apr 2003 06:05:40 -0000 @@ -558,7 +560,7 @@ int p = 0; case '\0': return; default: - while ((*s != '\0') && (*s != ' ')) { + while ((*s != '\0') && (*s != ' ') && (*s != '/')) { if (p == 0) *p1++ = *s++; else if (p == 1) *p2++ = *s++; else s++; It then realized that /wait was a qualifier, and passed the right thing to CreateProcess: F:\>start/wait xx.exe trace:exec:FindExecutableA File start, Dir - trace:exec:SHELL_FindExecutable start trace:exec:SHELL_FindExecutable SearchPathA returned non-zero trace:exec:SHELL_FindExecutable xlpFile=F:\start.exe,extension=.exe trace:exec:SHELL_FindExecutable .exe file trace:exec:SHELL_FindExecutable found F:\start.exe trace:exec:FindExecutableA returning F:\start.exe trace:process:CreateProcessA app (null) cmdline "start/wait xx.exe" but CreateProcess seems to have screwed up handling the /wait parameter: trace:process:CreateProcessA starting "F:\\start.exe" as Windows binary trace:process:PROCESS_InitWine starting process name="F:\\start.exe" file=0x4 argv[0]="start/wait" and that's the last we hear of /wait. This all works fine if we put a space before the /, in which case the log looks like: trace:process:CreateProcessA app (null) cmdline "start /wait xx.exe" trace:process:CreateProcessA starting "F:\\start.exe" as Windows binary trace:process:PROCESS_InitWine starting process name="F:\\start.exe" file=0x4 argv[0]="start" Hrmph. Guess I should add a print for argv[1] in PROCESS_InitWine. Or leave this to somebody who understands wcmd better than me :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

4 5

Problems with redhat 8 updated to glibc 2.3.2
by Mike Hearn 10 Apr '03

10 Apr '03

Hi, I've just had 3 consecutive reports of practically the same failure on redhat 8 with the latest security updates. Basically, nothing works, the wineinstall script messes up and fails to import the initial registry (it seems to get the fstab parsing wrong as well?) and when run wine reports exceptions like this: 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4037c166 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException info[0]=00000000 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException info[1]=409ffc68 17:36 <ChipX86> trace:seh:EXC_CallHandler calling handler at 0x400c4a00 code=c0000005 flags=0 17:36 <ChipX86> wine: Unhandled exception, starting debugger... 17:36 <ChipX86> trace:seh:start_debugger Starting debugger "winedbg --debugmsg -all --auto 8 0x18" 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x402af648 17:37 <ChipX86> trace:seh:EXC_RtlRaiseException info[0]=00000000 17:37 <ChipX86> trace:seh:EXC_RtlRaiseException info[1]=00000000 17:37 <ChipX86> trace:seh:EXC_CallHandler calling handler at 0x400c42c8 code=c0000005 flags=0 17:37 <ChipX86> trace:seh:EXC_CallHandler handler returned 2 17:37 <ChipX86> trace:seh:EXC_CallHandler calling handler at 0x400c4a00 code=c0000005 flags=10 17:37 <ChipX86> trace:seh:EXC_CallHandler handler returned 1 17:37 <ChipX86> err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x402af648 (pasted from irc) Can somebody with an up to date redhat box who doesn't mind being a sacrificial lamb look into this? I thought compiling with --with-nptl would fix these problems. BTW all these people were using CVS as of about 10 minutes ago. thanks -mike

3 3

Update
by Dustin Navea 10 Apr '03

10 Apr '03

Hey guys just got finished reading all of your emails from my sbc email, this is my email again, and Im doing better than I was.. I have changed jobs again but this time at my choice. Im now a direct marketing person, making 25-35% commission off the stuff I sell, so I'm making a lot better money than I was as a telemarketer... Got a roommate that's actually paying his rent on time and helping out with the bills... have a cell phone now prepaid, but better than nothing, my number is 1+ 281-610-1680 if anyone wants to give me a call after 9pm CST weekdays or anytime on Sundays (work all day saturdays) hopefully once I get my car I can start saving up for a new computer... Peace out guys -Dustin __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Wine on Slashdot
by Dimitrie O. Paun 09 Apr '03

09 Apr '03

Hi folks, Wine's on Slashdot: http://developers.slashdot.org/developers/03/04/08/2125228.shtml?tid=125 Jer, it looks some people are having problem with the new site (read the comments). Anything we can do about that? -- Dimi.

3 2

Stacking of in place OLE objects
by Mike Hearn 09 Apr '03

09 Apr '03

Hi, I'm trying to embed IE into a java app, and although it mostly works fine, there is an annoying painting problem that means sometimes the containing JPanel (a swing component) overdraws what IE drew - ie the clipping doesn't seem to be working correctly. I have a few questions on this: 1) I was under the impression that OLE in place objects are contained within their own child window, and that therefore anything drawn underneath that window should be clipped - is this right? 2) The windows are definately being sent WM_PAINT in the right order, but somewhere along the line the first window is incorrectly allowed to draw on top of the second. Is painting asynchronous when using OLE embedding? If so, is there any way to disable this? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

Re: Opening AVIs with wine
by Pouech Eric DMI AEI CAEN 09 Apr '03

09 Apr '03

> However when I try and open or play back an AVI file, I get no output. > I have searched the Web and found on winehq that video for windows is at a 30% > complete state. Is this true? > > Changing msvfw32 to native in the config did not help. > > Please can someone tell me if it is possible for a wine application > to open an avi file (or better yet use video for windows codecs). in generic terms yes. however, avi is an enveloppe to store video files, but the compression used can vary from file to file so, you need the specific decompressor to handle a given type of file normally, wine is ready (under the MCI and the msvfw32 interfaces at least) to play AVI files however, to get further with your issue, we need to know : 1/ which interface your program actually uses (MCI, msvfw, directx...) 2/ which codecs are installed and configured under wine 3/ the type of compressor used for your file (btw, does changing the avi file to play changes also what is output - or not output in your case) A+

1 0

Opening AVIs with wine
by Tom Hibbert 09 Apr '03

09 Apr '03

Hello All, I have successfully gotten Discreet Combustion to start under Wine/Winex CVS. However when I try and open or play back an AVI file, I get no output. I have searched the Web and found on winehq that video for windows is at a 30% complete state. Is this true? Changing msvfw32 to native in the config did not help. Please can someone tell me if it is possible for a wine application to open an avi file (or better yet use video for windows codecs). Thanks, Tom Hibbert Work: someday Home: +649 815 1838 Obtain my GPG Key from: http://cryptocracy.hn.org/pubkey.txt

1 0

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