wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

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

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