December 2008 - Wine-Devel - list.winehq.org

Re: [02/10] wintrust: Convert crypt tests to Unicode.

by Hans Leidekker

On Monday 22 December 2008 14:54:28 Alexandre Julliard wrote: > > -static char selfname[MAX_PATH]; > > -static CHAR CURR_DIR[MAX_PATH]; > > +static WCHAR selfname[MAX_PATH]; > > +static WCHAR current_dir[MAX_PATH]; > > Is that really useful? It seems to me it will break the tests on Win9x > for no good reason. Well, wintrust is a Unicode only API and we already skip the tests if wintrust is not fully supported. -Hans

Dec. 22, 2008

Re: [07/10] wintrust: Implement CryptCATEnumerateMember.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > @@ -496,12 +496,208 @@ BOOL WINAPI CryptCATClose(HANDLE hCatalog) > return TRUE; > } > > +static BOOL guid_from_string(const WCHAR *str, GUID *guid) > +{ > + unsigned int i = 0; > + unsigned char *b = (unsigned char *)guid; > + const WCHAR *p = str; Please call one of the existing functions for this instead of reinventing the wheel. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

Re: [02/10] wintrust: Convert crypt tests to Unicode.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > diff --git a/dlls/wintrust/tests/crypt.c b/dlls/wintrust/tests/crypt.c > index 6811fd4..41cb39a 100644 > --- a/dlls/wintrust/tests/crypt.c > +++ b/dlls/wintrust/tests/crypt.c > @@ -27,8 +27,8 @@ > > #include "wine/test.h" > > -static char selfname[MAX_PATH]; > -static CHAR CURR_DIR[MAX_PATH]; > +static WCHAR selfname[MAX_PATH]; > +static WCHAR current_dir[MAX_PATH]; Is that really useful? It seems to me it will break the tests on Win9x for no good reason. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

Re: wine.inf: Create fake pidgen.dll.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > The ie7 installer makes this call: > > LoadLibraryExA("C:\\windows\\system32\\pidgen.dll", 0, LOAD_LIBRARY_AS_DATAFILE) > > which fails if the file doesn't exist. No, it should work just fine. You shouldn't need a fake library for that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

Re: bugfix: resend: fix serial_flush

by Alexandre Julliard

Wolfgang Walter <wine(a)stwm.de> writes: > @@ -201,7 +202,17 @@ static void serial_flush( struct fd *fd, struct event **event ) > /* MSDN says: If hFile is a handle to a communications device, > * the function only flushes the transmit buffer. > */ > - if (tcflush( get_unix_fd(fd), TCOFLUSH ) == -1) file_set_error(); > + /* FlushFileBuffers does NOT have the semantics of tcflush. > + * Whereas tcflush discards any data not yet transmitted > + * FlushFileBuffers ensures they are written out. > + * The POSIX equivalent is tcdrain > + */ > + while (tcdrain( get_unix_fd(fd)) == -1) { > + if (errno != EINTR) { > + file_set_error(); > + return; > + } This will block, you can't do that in the server. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

Re: Windows version autodetection

by Alexandre Julliard

Markus Hitter <mah(a)jump-ing.de> writes: > Am 22.12.2008 um 11:51 schrieb Reece Dunn: > >> The same goes for applications released after Vista was released, but >> only work well on XP. The date heuristic will say "Vista", > > ... just like the current-heuristic-less assumption. Undoubtly, there > are many cases where a date heuristic doesn't help, but it won't > worsen matters either. It definitely will. There are many cases where reporting Win9x even for an old app will actually break things, because we don't (and can't) implement the Win9x architecture. -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2008

Re: Windows version autodetection

by Chris Howe

2008/12/22 Roderick Colenbrander <thunderbird2k(a)gmx.net> > Basically microsoft ships its own 'appdb' which contains the windows > version an app wants to see and in general much, much more things. For > instance their appdb allows windows to override the return values of > functions, it can fake the presence of certain files/directories/registry > keys, it can perform memory hacks and so on. > Something like that, not necessarily as a core part of wine but a side project in the manner of winetricks, might actually be a good idea from a user's point of view. A wine app launcher that maintains a list of known applications and the compatibility tweaks that are required in order to get them to run, or at least offer sensible advice (eg, where an app requires a native dll that is missing in order to work correctly). Its database would, I guess, be against app name and wine version, and then as wine improved it would need to do less and less. -- Chris

Dec. 22, 2008

RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux)

by Stefan Dösinger

Hmm... Wouldn't this bug also affect surfaces without a PBO? > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Nick Burns > Sent: Sunday, December 21, 2008 12:36 PM > To: wine-patches(a)winehq.org > Subject: [PATCH] Fix glReadPixels call from read_from_framebuffer > (redux) > > > This is a resubmission of my previous patch I fixed the issues Jeff > found > 1 - email address in the patch file/git > 2 - move declartions to block beginning (no warnings now) > 3 - hotmail spacing (well i think this is as good as I can make it...) > > > This is my last gfx fix for SHOGO (now its quite legible and playable) > The readpixels call was putting data into the wrong place in the pbo > (fixed with pixelstore) And the y-flip code was flipping the wrong data > as well (set the bottom row to the bottom row and not the height'th > row) > > The code handled fullscreen 2d blits (or blts without any colorkey > masking) correctly However sub-blits had issues (in the pbo path) > 1 - readpixels read into the wrong part of the pbo (as a line and > not a rect) > 2 - the y-flip code would move around the uninited data (from the > readpixels) and it read from the wrong place > 3 - After 1 and 2 the pbo is corrupt and the blt code had no > chance... > > This patch fixes 1 and 2 -- letting the blt code shine This can be seen > in the SHOGO menu (now not corrupt!) > > Changelog > Fix glReadPixels call from read_from_framebuffer > Fix the call to readpixels so that 2d blts going thru the pbo path > end up in the right place and get flipped correctly > > - Nick

Dec. 22, 2008

Re: Windows version autodetection

by Roderick Colenbrander

> > On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote: > >> The heuristic isn't "app works on this Windows version", it's "app is > >> designed for this Windows version". > > > > Should that matter? Plenty of Win95 apps will work in WinXP. > > ... because WinXP has such a version heuristic already in place? > > I think it's perfectly possible to do an heuristic which is sometimes > useful, but never harms. As already mentioned, the age of the > installer/installed files is such a data point: Apps written in 1996 > are never ever designed to run on WinXP. It's a matter of being > conservative enough. > The way Windows solves application compatibility is way, way, way more involved then a date check or checking the build id an app. Basically microsoft ships its own 'appdb' which contains the windows version an app wants to see and in general much, much more things. For instance their appdb allows windows to override the return values of functions, it can fake the presence of certain files/directories/registry keys, it can perform memory hacks and so on. Adding an automatic mechanism to Wine creates much more issues thant it solves. If someone wants to create something like this the best thing would be to have a proper appdb which can somehow be exported to lets say a xml file. Just look for a page on windows application compatibility / shim engine and you see how huge it is. (http://technet.microsoft.com/en-us/library/bb457032.aspx for instance see the application management console shot there) Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 22, 2008

Re: Windows version autodetection

by Markus Hitter

Am 22.12.2008 um 11:51 schrieb Reece Dunn: > The same goes for applications released after Vista was released, but > only work well on XP. The date heuristic will say "Vista", ... just like the current-heuristic-less assumption. Undoubtly, there are many cases where a date heuristic doesn't help, but it won't worsen matters either. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

Dec. 22, 2008

Re: Windows version autodetection

by Reece Dunn

2008/12/22 Markus Hitter <mah(a)jump-ing.de>: > Am 22.12.2008 um 05:16 schrieb Chris Robinson: > >> Should that matter? Plenty of Win95 apps will work in WinXP. > > ... because WinXP has such a version heuristic already in place? > > I think it's perfectly possible to do an heuristic which is sometimes > useful, but never harms. As already mentioned, the age of the > installer/installed files is such a data point: Apps written in 1996 > are never ever designed to run on WinXP. It's a matter of being > conservative enough. You could possibly do that for Windows 95 applications (unless the application was written for Windows 3.1 and released in 96), and put an upper version limit on the application, but that doesn't mean that it will work best using the latest version of Windows as reported by Wine. The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say "Vista", but the application will fall over if it is not designed for some of Vista's behaviour. For Wine, this may not be too big an issue as Wine tries to work as any version of Windows, so shouldn't differ in behaviour. Also, it does not matter how well the application works on a Windows box, but how well it currently runs on Wine. If an application supports Vista, but is making some calls that Wine does not support yet, the application is going to break if the Windows version is reported as Vista. Similarly if the application supports XP and GDI+ or themes, but has a fallback path for 2000 and happens to call an API that is missing or broken on Wine. Older applications designed for earlier versions of Windows are more likely to work on Wine, as it is designed to be version independent and doesn't completely change it's implementation with every other release. The only case where this will not work is if the application writers have got the version detection logic wrong and bail out. The main issue is for applications written for newer versions of Windows, or Windows components that are not yet supported, or not completely supported in Wine. These applications may work when set to earlier versions of Windows because they have a fallback to support older versions. - Reece

Dec. 22, 2008

winehq.org language selection suggestion

by Maik Schulz

Hi, instead of having the "change language" link at the bottom of the main page, why not display the country flags directly and shade the ones that are inactive (or find some other way of indicating the active one)? Then non-english users had a better clue that language options are available at all and wouldn't have to figure out what "change language" means ;-) Cheers, -Maik

Dec. 22, 2008

Re: Windows version autodetection

by Markus Hitter

Am 22.12.2008 um 05:16 schrieb Chris Robinson: > On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote: >> The heuristic isn't "app works on this Windows version", it's "app is >> designed for this Windows version". > > Should that matter? Plenty of Win95 apps will work in WinXP. ... because WinXP has such a version heuristic already in place? I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

Dec. 22, 2008

Re: [2/2] mshtml: Add VT_INT support in IHTMLElementCollection_item

by Konstantin Kondratyuk

Hi, Jacek! On Friday 19 December 2008 18:04:45 Jacek Caban wrote: > You're duplicating the code that handles VT_I4 case. Please avoid it. Do you think, this code will be better? And can I truncate "VT_I4" from trace? if(V_VT(&name) == VT_I4 || V_VT(&name) == VT_INT) { int i; if (V_VT(&name) == VT_I4) { i = V_I4(&name); TRACE("name is VT_I4: %d\n", i); } else { i = V_INT(&name); TRACE("name is VT_INT: %d\n", i); } if(i < 0) return E_INVALIDARG; if(i >= This->len) return S_OK; *pdisp = (IDispatch*)This->elems[i]; IDispatch_AddRef(*pdisp); TRACE("Returning pdisp=%p\n", pdisp); return S_OK; } And about my test for this problem - it's OK? -- Best regards, Konstantin Kondratyuk.

Dec. 22, 2008

Re: Patchwatcher offline?

by Austin English

On Sat, Dec 20, 2008 at 7:03 PM, Francois Gouget <fgouget(a)free.fr> wrote: > On Sat, 20 Dec 2008, Paul Vriens wrote: > >> IneedAname wrote: >> > Looks like Patchwatcher has being offline from 09-Dec-2008. >> > Did I miss something or did someone trip over the mains cable? >> > >> > >> http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html > > Well, obviously that's more than a day (I'm not complaining, just saying > the above post may not explain everything). > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > There are 10 types of people in the world... > those who understand binary and those who don't. > > > I had asked Dan a couple days ago, he's been busy with work, sick kid, holidays, etc. Probably needs a few days for things to calm down, and a nice cold beer :-). -- -Austin

Dec. 22, 2008

Re: Windows version autodetection

by Austin English

On Sun, Dec 21, 2008 at 4:14 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > The bulk download would only work if you install applications to their > default location, but it seems like a good idea. > Not necesarily. This is where sha1sums/file name/file size are useful.

Dec. 22, 2008

Re: Get font file (full) path from HFONT

by Massimo Del Fedele

Dmitry Timoshkov ha scritto: > "Massimo Del Fedele" <max(a)veneto.com> wrote: > >> In order to use Freetype library I need to get font file full path from >> an HFONT handle. >> Is there a simple way to do it or should I scan the registry/font dirs >> to pair font faces/font paths ? > > Do you need this under Wine? In the app code, or Wine code? For which > purpose? > It was in wine code, for my dib driver. But it's (to some extent) solved by examining gdiFont list passed by SetFont() function, it already contains an FT_Font handle for every used font (I think....). Weird way to do it, but I couldn't find any simpler one.... BTW, I still don't understand the purpose of gdiFont parameter, and in which cases it can be null. Ciao Max

Dec. 22, 2008

Re: Get font file (full) path from HFONT

by Dmitry Timoshkov

"Massimo Del Fedele" <max(a)veneto.com> wrote: > In order to use Freetype library I need to get font file full path from > an HFONT handle. > Is there a simple way to do it or should I scan the registry/font dirs > to pair font faces/font paths ? Do you need this under Wine? In the app code, or Wine code? For which purpose? -- Dmitry.

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Dan Kegel

On Sun, Dec 21, 2008 at 9:45 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: >>>> http://www.kronenberg.org/darwine/ >> Can we convince Mike and Zach to switch names to just plain Wine? > > And change the licencing conditions to LGPL, currently that page states > "Darwine and wine are released under the gpl". Mike, that's just a typo, I think. Can you add the missing L? > They also have to remove > any differences between WineHQ sources and their ones, otherwise it can't > be supported via WineHQ. Mike, how many patches are left? - Dan

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander > <thunderbird2k(a)gmx.net> wrote: >>> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >>> of nearly up to date wine builds for the mac. How about we link to it >>> from http://winehq.org/download/ ? >>> >>> Furthermore, are his packages good enough to support? >>> If so, how 'bout we ask him to add links to bugzilla and >>> the appdb from his page? >> >> Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. > > Yes, I would like to keep Darwine as the name of the old powerpc project > that combined an x86 emulator and wine. > > Can we convince Mike and Zach to switch names to just plain Wine? And change the licencing conditions to LGPL, currently that page states "Darwine and wine are released under the gpl". They also have to remove any differences between WineHQ sources and their ones, otherwise it can't be supported via WineHQ. -- Dmitry.

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Zach Drayer

>>> >>> Yes, I would like to keep Darwine as the name of the old powerpc >>> project >>> that combined an x86 emulator and wine. >>> >>> Can we convince Mike and Zach to switch names to just plain Wine? >>> I'd have no problems switching over to just using Wine instead of Darwine. Also, maybe Jim White or someone else that actually developed Darwine could comment? All I do is package it.. and even the, I haven't really had time to do so recently. FWIW, I'm building 1.1.11 right now though. -Zach

Dec. 21, 2008

Re: Windows version autodetection

by Chris Robinson

On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote: > The heuristic isn't "app works on this Windows version", it's "app is > designed for this Windows version". Should that matter? Plenty of Win95 apps will work in WinXP. Sometimes better, due to the improved functionality/bugfixes XP implicitly provides (I can't say I know which of these features are handled by Wine, but theoretically..). Why force it to Win95 mode when it'll work in WinXP? The apps that don't work in a newer version than they were designed for are a problem, but not one so easilly discovered or solved. I'd imagine most don't have a problem with newer versions, so forcing them to use those older versions for no reason will just end up hiding Wine bugs more than helping buggy apps.

Dec. 21, 2008

Re: Windows version autodetection

by Damjan Jovanovic

On Mon, Dec 22, 2008 at 1:27 AM, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On Sunday 21 December 2008 02:46:37 pm Scott Ritchie wrote: >> Right, but none of that would be necessary if the heuristic worked in >> the first place. By having a good heuristic we could at least >> dramatically cut down on the apps needing this logic. > > But how do you tell when an app needs the Windows version changed because it > won't work in the default mode, and it's not just hiding a Wine bug? For > example, Wine is buggy with some device drivers, which some games will load > in XP mode. Set the Windows version to 98 (or Vista, or sometimes even 2k), > and they may not, allowing the game to work. In such a case, you don't want > to change the Windows version, you want to fix the bug. > > > The heuristic isn't "app works on this Windows version", it's "app is designed for this Windows version". If a heuristic tells you a game needs 98 when it needs XP, the heuristic is broken, even if the game works better in 98 because it doesn't load a driver. Also, the existence of driver loading APIs in DLL imports is probably a good heuristic to tell that an app needs XP. Damjan

Dec. 21, 2008

RE: Adding Mac joystick support -- build problem (resend)

by Nick Burns

> Resending this due to the terrible hotmail "formatting" > Any tips for how to get legible emails out of hotmail without doubling up the newlines would be greatly appreciated > Note: I cannot even read the emails I send from hotmail... > ------- > > I have a few tips for running built wine on OS X > > > I have made some Apple specific mods to get wine (ogl) working > Most of these are hacks to workaround some issues in xquartz X11 (and they got radars) > > > 1 - Get/install an updated x11 (2.3.1+ has worked well for me) > http://xquartz.macosforge.org/trac/wiki > 2 - Apply my attached patch (I have others for specific games -- but this is the base) > 3 - Open X11 and goto your 'patched' wine tree > 4 - (under xterm) Run 'autoconf' to regen yer configure script (my patch mods configure.ac) > 5 - (under xterm) Run 'make depend && make && sudo make install' > > > Now you should be able to run d3d and ogl windows apps under wine > > > - Nick I forget a important step -- for actually running apps... 6 - run terminal -- run the following (change PATH to match yer wine install path) open -a X11 export DYLD_FALLBACK_LIBRARY_PATH=$HOME/lib:/usr/local/lib:/lib:/usr/lib:/usr/X11R6/lib/ export PATH=$PATH:/Library/Wine/bin winecfg wine my_app ------- Also note that I generally run in the emulated virtual desktop mode (so keep that in mind if you have problems) - Nick

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Dan Kegel

On Sun, Dec 21, 2008 at 6:21 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > I would like to see something like the following (and it follows the > OpenOffice.org strategy for releases): > > Wine-<version>-<platform>-<CPU>-<installer>.<compression-type> > > So Wine for the Mac Intel would appear like this: > > Wine-1.1.9-MacOSX-Intel-DragnDrop.dmg > > Where Wine for a X86 for Ubuntu 8.1 would appear like this for an x86: > > Wine-1.1.9-Ubuntu8.10-x86-apt.tar.gz (assuming that the release was in > tar.gz.) It might make sense for .tar.gz files, but it doesn't make too much sense for .deb and .rpm files, which already have names which are dictated to some extent by the repository they're in. Also, ideally, I'd rather see somewhat less distro-specific builds of Wine anyway. Not sure how practical that is, though, until we can build against LSB.

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by James McKenzie

Nathaniel Gray wrote: > On Sun, Dec 21, 2008 at 8:38 AM, Dan Kegel <dank(a)kegel.com> wrote: > >> On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander >> <thunderbird2k(a)gmx.net> wrote: >> >>>> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >>>> of nearly up to date wine builds for the mac. How about we link to it >>>> from http://winehq.org/download/ ? >>>> >>>> Furthermore, are his packages good enough to support? >>>> If so, how 'bout we ask him to add links to bugzilla and >>>> the appdb from his page? >>>> >>> Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. >>> >> Yes, I would like to keep Darwine as the name of the old powerpc project >> that combined an x86 emulator and wine. >> >> Can we convince Mike and Zach to switch names to just plain Wine? >> > > As one who just spent several days trying to figure this stuff out and > still isn't quite sure he got it right, I'd like to add "pretty > please?" > I would like to see something like the following (and it follows the OpenOffice.org strategy for releases): Wine-<version>-<platform>-<CPU>-<installer>.<compression-type> So Wine for the Mac Intel would appear like this: Wine-1.1.9-MacOSX-Intel-DragnDrop.dmg Where Wine for a X86 for Ubuntu 8.1 would appear like this for an x86: Wine-1.1.9-Ubuntu8.10-x86-apt.tar.gz (assuming that the release was in tar.gz.) What do the rest of you think? James McKenzie

Dec. 21, 2008

New Gecko package - call for tests

by Jacek Caban

Hi, I've released first (and hopefully last) RC build of new Gecko package and attached a patch against current Wine Git to bug 16198 http://bugs.winehq.org/show_bug.cgi?id=16198 It's critical to make sure, that there will be no regressions due to the new Gecko, it'd much more work to fix such regression than a usual regressions. I'd appreciate any help with testing it. Instructions how to do it are in the bug report. Any application that uses MSHTML is worth testing, esp ones that extensively use it. I will write more about the new release and future plans later in an other subject. Thanks, Jacek

Dec. 21, 2008

Re: RFC: Proposed new web site design

by Tom Wickline

On Mon, Nov 24, 2008 at 4:39 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > At Wineconf, we made the decision to change the entry page to the Wine > web site. The hope was to simplify and stream line it, and to put in > place the infrastructure to start moving more content to the Wiki. > > Jeremy Newman and Jon Parshall have put a lot of time and energy into a > proposed new design, following what we took away from the meetings at > Wineconf. > > A mock up of that design is up now here: > http://wine.codeweavers.com/winehq_new/ > That was slick, the mock up listed Bordeaux under third party apps and when the site went live it was somehow removed :D Cheers, Tom -- http://www.wine-reviews.net/

Dec. 21, 2008

Re: Windows version autodetection

by Chris Robinson

On Sunday 21 December 2008 02:46:37 pm Scott Ritchie wrote: > Right, but none of that would be necessary if the heuristic worked in > the first place. By having a good heuristic we could at least > dramatically cut down on the apps needing this logic. But how do you tell when an app needs the Windows version changed because it won't work in the default mode, and it's not just hiding a Wine bug? For example, Wine is buggy with some device drivers, which some games will load in XP mode. Set the Windows version to 98 (or Vista, or sometimes even 2k), and they may not, allowing the game to work. In such a case, you don't want to change the Windows version, you want to fix the bug.

Dec. 21, 2008

Re: Windows version autodetection

by Scott Ritchie

Reece Dunn wrote: > 2008/12/21 Scott Ritchie <scott(a)open-vote.org>: >> Reece Dunn wrote: >>> Sure. But what if an application was shipped after Vista or Windows >>> Server 2008, but only worked on XP and earlier. Your detection would >>> not work here. >> In that case the user is no worse off - they'd still need to look up >> AppDB and change their settings with winecfg. > > I was intending to have some programming logic to download the data > from AppDB and apply this to winecfg/the registry. That way the user > does not have to look it up, it becomes something that is updated as > part of the install process. > > For the case where there isn't any AppDB data, the default version of > Windows is reported as is done at the moment. > Right, but none of that would be necessary if the heuristic worked in the first place. By having a good heuristic we could at least dramatically cut down on the apps needing this logic. Thanks, Scott Ritchie

Dec. 21, 2008

Re: Windows version autodetection

by Reece Dunn

2008/12/21 Scott Ritchie <scott(a)open-vote.org>: > Reece Dunn wrote: >> Sure. But what if an application was shipped after Vista or Windows >> Server 2008, but only worked on XP and earlier. Your detection would >> not work here. > > In that case the user is no worse off - they'd still need to look up > AppDB and change their settings with winecfg. I was intending to have some programming logic to download the data from AppDB and apply this to winecfg/the registry. That way the user does not have to look it up, it becomes something that is updated as part of the install process. For the case where there isn't any AppDB data, the default version of Windows is reported as is done at the moment. - Reece

Dec. 21, 2008

Re: Windows version autodetection

by Scott Ritchie

Reece Dunn wrote: > 2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: >> On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: >>> 2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: >>> You can change the version of Windows reported for different >>> applications, and the default version using winecfg -> Applications. >> I know, but bugs coming up from the wrong default version aren't >> always obvious (in my case they were registry keys that don't get >> created during installation). > > This is where having people contributing to AppDB would be useful. > They would know what version of Windows being reported by Wine would > work best - even when that changes in the future. This will take some > experimentation, but after some investigation it can be figured out. > >>> I'm not sure that adding heuristics would be the correct approach, as >>> those can lead to incorrect results. The winecfg option supports the >>> user being able to change the version of Windows reported for the >>> specified application. The workflow could be better, though (e.g. >>> supporting an option on an exe's right-click menu). >> Heuristics aren't necessarily wrong: >> >> File Header >> Machine: 014C (i386) >> Number of Sections: 6 >> TimeDateStamp: 31104C75 (Thu Feb 1 07:15:33 1996) offset 136 >> >> Feb 1 1996 can't be later than Windows 95. > > Sure. But what if an application was shipped after Vista or Windows > Server 2008, but only worked on XP and earlier. Your detection would > not work here. > In that case the user is no worse off - they'd still need to look up AppDB and change their settings with winecfg. I don't see how these two ideas are in contest - we can have both good heuristics and good means for coping with failure (AppDB lookup, right click preferences setting for windows version, etc.) Right now the current heuristic is "always try wine's default", which could easily be improved upon. Thanks, Scott Ritchie

Dec. 21, 2008

Get font file (full) path from HFONT

by Massimo Del Fedele

In order to use Freetype library I need to get font file full path from an HFONT handle. Is there a simple way to do it or should I scan the registry/font dirs to pair font faces/font paths ? Ciao Max

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Nathaniel Gray

On Sun, Dec 21, 2008 at 8:38 AM, Dan Kegel <dank(a)kegel.com> wrote: > On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander > <thunderbird2k(a)gmx.net> wrote: >>> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >>> of nearly up to date wine builds for the mac. How about we link to it >>> from http://winehq.org/download/ ? >>> >>> Furthermore, are his packages good enough to support? >>> If so, how 'bout we ask him to add links to bugzilla and >>> the appdb from his page? >> >> Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. > > Yes, I would like to keep Darwine as the name of the old powerpc project > that combined an x86 emulator and wine. > > Can we convince Mike and Zach to switch names to just plain Wine? As one who just spent several days trying to figure this stuff out and still isn't quite sure he got it right, I'd like to add "pretty please?" Cheers, -n8 -- Nathan Gray http://www.n8gray.org/

Dec. 21, 2008

Help me to find function name from kernel32.dll

by AlannY

Hi there. I'm debugging some windows app in OllyDbg under Wine ;-) (funny?) Now, I found this call in assembler: call ebx EBX is 7EE6BC23. So, instruction invokes some function in address 7EE6BC23. This address, as Olly shows belongs to kernel32.dll. I can follow this address, and there are some code ;-) Everything right ;-) But now, I want to get name of this function (kernel32.7EE6BC23) and analyze it's C source code (as you know Wine is open source :P) ;) How to? Or maybe it's impossible? Maybe some symbols must be loaded (and how?). Tnx

Dec. 21, 2008

Re: Adding Mac joystick support -- build problem

by Nathaniel Gray

On Sat, Dec 20, 2008 at 9:21 PM, Nick Burns <adger44(a)hotmail.com> wrote: > > I have a few tips for running built wine on OS XI have been working on getting SHOGO to run (I have one more patch to send up) Hey, thanks for the patch, I'll give it a shot! I also realized that Mike K. provides his build environment and some nice scripts so I've been trying them out as well, but still without success. One thing I've found is that I can replace the dinput.dll from Mike K's build with one of mine without problems, so that may be a way for me to work on the joystick support even if I can't manage to get the whole build working properly. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/

Dec. 21, 2008

d3d9 patch include a test needs testing in windows

by Pauli Nieminen

Hi! I have tried to get Civ4 running in my machine and successed with some minor wine modifications but this patch needs testing in windows how d3d9 handles this case in there. Preferable test system should be include graphic card that supports some but not all shader versions. (That means readeon 8500+ and Geforce 3/4+). I think it should be ok to run in any windows version if there is just dx9 installed. Patch set includes 3 patches but you realy only need to apply the test portion of 2nd patch. The latest patch version is available at http://repe.ath.cx/wine/ and bug report is http://bugs.winehq.org/show_bug.cgi?id=16444 . Thanks for help. Pauli

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Maik Schulz

On 21 Dec 2008, at 16:50, Dan Kegel wrote: > Say, http://www.kronenberg.org/darwine/ seems to be a popular source > of nearly up to date wine builds for the mac. How about we link to it > from http://winehq.org/download/ ? > > Furthermore, are his packages good enough to support? > If so, how 'bout we ask him to add links to bugzilla and > the appdb from his page? > > There is another source of OS X Wine builds at http://thisismyinter.net/Files/Darwine/Leopard/Installers/ . This is where I got my installers in the past, the owner is rebuilding the site at the moment though. My feeling was that they worked better but I don't have any hard evidence to support this. Cheers, -Maik

Dec. 21, 2008

Marshalling of remotable handles

by Michael Karcher

Hello Wine developers, while trying to add proxy/stub code for shell32, I stumbled across the definition of remotable handles in IDL. We have - a RemotableHandle union. - the IDL typedefs for the wire representation of handles: | typedef [unique] RemotableHandle *wireHXXX; - the IDL declaration for the handle types itself: | typedef [wire_marshal(wireHXXX)] void*HXXX; This makes widl generate null pointer checks for HWND parameters, as HXXX is a void pointer without the unique attribute. My question is: Should widl really add this check? As the type is marshalled as wireHXXX, the null value is no problem for marshalling, so it could be safely left out. What I did in my repository was adding the [unique] attribute to the IDL typedef of the handle type: | typedef [unique, wire_marshal(wireHXXX)] void*HXXX; Is this the right approach to generally get rid of the NULL pointer checks for handles, or is widl to be fixed instead? Best regards and thanks for advice, Michael Karcher

Dec. 21, 2008

Re: wine-1.2 release criteria?

by Massimo Del Fedele

Rolf Kalbermatter ha scritto: > > It may be ugly in some ways but incorporating it in wineX11.drv has the big > disadvantage > that it would not be easy to leverage it off to other possible display > drivers such as the > quartz driver. Windows 2K/XP does appear to do it mostly in the Eng... GDI > functions > which would have been another possibility. > Vista changed the entire GDI/display driver business seriously again and I > have no idea > how it does work there. > > Rolf Kalbermatter > > > > Well, imho the right way would be to replace winex11.drv with a driver with pluggable backends, which could do all DIB stuffs as dib engine and forward to the backend(s) all device drawings. Or, even better, change gdi32 to hook to different drivers for DIB and DDB bitmaps. I mean, every gdi function should test if bitmap is a DDB or a DIB and use the appropriate driver. What I'm doing now (and what's done in Jesse's and Huw's engines) is an hack that swaps driver's hooks depending on bitmap type just on SelectBitmap() function, which has many disadvantages : 1) BitBlt functions (and maybe any call that operates on 2 BMPs) must check whether both BMPs are of the same kind, OR change one of them, in order the correct driver to operate (which is indeed done in Jesse's and in my engine). 2) CreateDc() and similars are called twice, once for every driver, and the DIB one must be done on SelectBitmap(), which is ugly. BTW, all that would require some major cleanup of gdi code, which I guess nobody would like.... Max

Dec. 21, 2008

re: Help me to find function name from kernel32.dll

by Dan Kegel

m(a)alanny.ru asked: > [How can I get a log of the Wine functions called by an app?] WINEDEBUG=+relay should help...

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Dan Kegel

On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: >> Say, http://www.kronenberg.org/darwine/ seems to be a popular source >> of nearly up to date wine builds for the mac. How about we link to it >> from http://winehq.org/download/ ? >> >> Furthermore, are his packages good enough to support? >> If so, how 'bout we ask him to add links to bugzilla and >> the appdb from his page? > > Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. Yes, I would like to keep Darwine as the name of the old powerpc project that combined an x86 emulator and wine. Can we convince Mike and Zach to switch names to just plain Wine? - Dan

Dec. 21, 2008

Re: Linking to a Mac OS X build of Wine from winehq.org/download ?

by Roderick Colenbrander

> Say, http://www.kronenberg.org/darwine/ seems to be a popular source > of nearly up to date wine builds for the mac. How about we link to it > from http://winehq.org/download/ ? > > Furthermore, are his packages good enough to support? > If so, how 'bout we ask him to add links to bugzilla and > the appdb from his page? > Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 21, 2008

Re: Functions that should be static

by Andrew Talbot

Francois Gouget wrote: > > I have attached a script that identifies functions that should be made > static (among other things). There are approximately 450 of them, there > should be pretty efw false positives, and I will look into them > eventually. But if someone beats me to it I sure won't complain <g>. > Hi Francois, The dlls/advapi32/svcctl_c.c: svcctl_*() functions are peculiar, too. They look like they need to be exported in some manner. -- Andy.

Dec. 21, 2008

Linking to a Mac OS X build of Wine from winehq.org/download ?

by Dan Kegel

Say, http://www.kronenberg.org/darwine/ seems to be a popular source of nearly up to date wine builds for the mac. How about we link to it from http://winehq.org/download/ ? Furthermore, are his packages good enough to support? If so, how 'bout we ask him to add links to bugzilla and the appdb from his page?

Dec. 21, 2008

RE: wine-1.2 release criteria?

by Rolf Kalbermatter

Massimo Del Fedele wrote: > A note : my DIB engine now includes both Jesse Allen's and > Huw Davies ones, merged to take the best of both. > BTW, i'll finish it following this way, but I still think the > best way would be to include it in wineX11.drv. Using the > mixed driver approach, with different function pointers and > physical devices depending on bitmap content is, imho, an > ugly way to solve the problem..... It may be ugly in some ways but incorporating it in wineX11.drv has the big disadvantage that it would not be easy to leverage it off to other possible display drivers such as the quartz driver. Windows 2K/XP does appear to do it mostly in the Eng... GDI functions which would have been another possibility. Vista changed the entire GDI/display driver business seriously again and I have no idea how it does work there. Rolf Kalbermatter

Dec. 21, 2008

Re: Compiling dbghelp with MinGW

by Eric Pouech

Francois Gouget a écrit : > On Sat, 13 Dec 2008, Eric Pouech wrote: > [...] > >>> 1) #ifdef-out regexp support if regex.h is missing? Maybe with an >>> autoconf check for regcomp()? >>> 2) Add some reg*() stubs that do nothing if regex.h & co are missing? >>> > [...] > >> 1,2) most of the dbghelp code will be of no use if no regex support is present >> > > It still feels wrong for Wine to fail compiling just because a regular > expression library is missing. If we can compile Wine without X we > should be able to compile it without a regular expression library. > I'd rather say a system without regex support is broken. even macos seems to have it ;-) but I agree the configure output should be clearer about this dependancy A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Dec. 21, 2008

Re: Adding Mac joystick support -- build problem (resend)

by Pauli Nieminen

On Sun, Dec 21, 2008 at 9:07 AM, Nick Burns <adger44(a)hotmail.com> wrote: > > Resending this due to the terrible hotmail "formatting" > Any tips for how to get legible emails out of hotmail without doubling up > the newlines would be greatly appreciated > Note: I cannot even read the emails I send from hotmail... > ------- > > - Nick > > > You can use these steps: 1. Add your email and name to git config ($HOME/.gitconfig probably) 2. git-format-patch --keep-subject HEAD^ 3. Now check that patch file looks correct in text editor. (You can also add some extra text to message still) 4. git-send-email --smtp-server <your isp's smtp server> --to wine-patches(a)winehq.org 0001* (You can first check that send-email will produce correct headers with --dry-run) Pauli

Dec. 21, 2008

Re: wow, there are more win64 apps than I thought...

by Francois Gouget

On Sun, 21 Dec 2008, David Laight wrote: > On Sun, Dec 21, 2008 at 02:00:14AM +0100, Francois Gouget wrote: > > > > But Microsoft decided that since Windows application programmers have > > never encountered the word 'portability' even once in their life, they > > could not be expected to have understood the difference between 'int' > > and 'long', and thus would likely be so upset if 'long' where ever to > > change size that they might commit suicide in droves. So they decided > > that 'long' would remain 32bits. > > Not only Windows application programmers.... > > What type to you think PDWORD_PTR is ? 'unsigned __int64' why? Essentially, it's only the XXX_PTR types that are 64bits in Win64. I.e. it's only in those integer types that you can put a pointer. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Dec. 21, 2008

Re: wow, there are more win64 apps than I thought...

by David Laight

On Sun, Dec 21, 2008 at 02:00:14AM +0100, Francois Gouget wrote: > > But Microsoft decided that since Windows application programmers have > never encountered the word 'portability' even once in their life, they > could not be expected to have understood the difference between 'int' > and 'long', and thus would likely be so upset if 'long' where ever to > change size that they might commit suicide in droves. So they decided > that 'long' would remain 32bits. Not only Windows application programmers.... What type to you think PDWORD_PTR is ? David -- David Laight: david(a)l8s.co.uk

Dec. 21, 2008