Re: Get font file (full) path from HFONT
"Massimo Del Fedele" 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.
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 9:45 PM, Dmitry Timoshkov 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
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
"Dan Kegel" wrote: > On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander > 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.
Re: Windows version autodetection
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.
Re: Windows version autodetection
On Mon, Dec 22, 2008 at 1:27 AM, Chris Robinson 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
RE: Adding Mac joystick support -- build problem (resend)
> 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
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 6:21 PM, James McKenzie wrote: > I would like to see something like the following (and it follows the > OpenOffice.org strategy for releases): > > Wine. > > 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.
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
Nathaniel Gray wrote: > On Sun, Dec 21, 2008 at 8:38 AM, Dan Kegel wrote: > >> On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander >> 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. 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
New Gecko package - call for tests
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
Re: RFC: Proposed new web site design
On Mon, Nov 24, 2008 at 4:39 PM, Jeremy White 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/
Re: Windows version autodetection
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.
Re: Windows version autodetection
Reece Dunn wrote: > 2008/12/21 Scott Ritchie : >> 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
Re: Windows version autodetection
2008/12/21 Scott Ritchie : > 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
Re: Windows version autodetection
Reece Dunn wrote: > 2008/12/21 Damjan Jovanovic : >> On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn wrote: >>> 2008/12/21 Damjan Jovanovic : >>> 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
Get font file (full) path from HFONT
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
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 8:38 AM, Dan Kegel wrote: > On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander > 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/
Re: Adding Mac joystick support -- build problem
On Sat, Dec 20, 2008 at 9:21 PM, Nick Burns 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/
d3d9 patch include a test needs testing in windows
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
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
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
Marshalling of remotable handles
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
Re: wine-1.2 release criteria?
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
re: Help me to find function name from kernel32.dll
m...@alanny.ru asked: > [How can I get a log of the Wine functions called by an app?] WINEDEBUG=+relay should help...
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander 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
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
> 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 -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Re: Functions that should be static
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 . > 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.
Linking to a Mac OS X build of Wine from winehq.org/download ?
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?
Help me to find function name from kernel32.dll
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
RE: wine-1.2 release criteria?
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
Re: Compiling dbghelp with MinGW
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)
Re: Adding Mac joystick support -- build problem (resend)
On Sun, Dec 21, 2008 at 9:07 AM, Nick Burns 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 --to wine-patc...@winehq.org 0001* (You can first check that send-email will produce correct headers with --dry-run) Pauli
Re: wow, there are more win64 apps than I thought...
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 http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: wow, there are more win64 apps than I thought...
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: da...@l8s.co.uk
Re: Windows version autodetection
2008/12/21 Damjan Jovanovic : > On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn wrote: >> 2008/12/21 Damjan Jovanovic : >> 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. Also, what if an application supported XP, but crashed on Wine as it was using some unimplemented call in GDI+. Setting it to Windows 2000, the application works fine. These two cases are where your simple heuristic will break (TimeDateStamp ==> Windows version). >> What would be better is to have AppDB keep track of what version of >> Windows works best with a particular application. This could then be >> queried on install of the application, or downloaded in bulk. It would >> be easy to take the data and create a registry file like what winecfg >> will be saving to. That way, AppDB becomes the place where this is >> maintained (so it is up to the individual maintainers to set the >> Windows version if it doesn't work with the default version) and there >> are no ugly heuristics involved. > > The bulk download would only work if you install applications to their > default location, but it seems like a good idea. IIUC, Wine goes by the executable name (e.g. notepad.exe) and not where the application is installed to. The only problems I can see with this is in different versions of applications requiring different reported versions of Windows and any name clashes (if any). - Reece
Re: Windows version autodetection
On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn wrote: > 2008/12/21 Damjan Jovanovic : >> There are some older applications out there, which don't install or >> run correctly unless Wine is emulating the correct Windows version >> (eg. Windows 9x). >> >> At least Windows XP has the ability to use certain heuristics to make >> an educated guess as to which version of Windows the application >> expects, and then lie in GetVersion() and behave like that version in >> relevant APIs. >> >> Should we do something like that for Wine? It would allow many >> applications to work out of the box. > > 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). > 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. > What would be better is to have AppDB keep track of what version of > Windows works best with a particular application. This could then be > queried on install of the application, or downloaded in bulk. It would > be easy to take the data and create a registry file like what winecfg > will be saving to. That way, AppDB becomes the place where this is > maintained (so it is up to the individual maintainers to set the > Windows version if it doesn't work with the default version) and there > are no ugly heuristics involved. The bulk download would only work if you install applications to their default location, but it seems like a good idea. > - Reece > Damjan
Re: Windows version autodetection
On Sun, Dec 21, 2008 at 11:19:35AM +0200, Damjan Jovanovic wrote: > Hi > > There are some older applications out there, which don't install or > run correctly unless Wine is emulating the correct Windows version > (eg. Windows 9x). > > At least Windows XP has the ability to use certain heuristics to make > an educated guess as to which version of Windows the application > expects, and then lie in GetVersion() and behave like that version in > relevant APIs. > > Should we do something like that for Wine? It would allow many > applications to work out of the box. We had this ;) It was removed for being mostly unnecessary and that one Wine session should report one Windows version (even when different Windows programs run). Ciao, Marcus
Re: Windows version autodetection
2008/12/21 Damjan Jovanovic : > There are some older applications out there, which don't install or > run correctly unless Wine is emulating the correct Windows version > (eg. Windows 9x). > > At least Windows XP has the ability to use certain heuristics to make > an educated guess as to which version of Windows the application > expects, and then lie in GetVersion() and behave like that version in > relevant APIs. > > Should we do something like that for Wine? It would allow many > applications to work out of the box. You can change the version of Windows reported for different applications, and the default version using winecfg -> Applications. 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). What would be better is to have AppDB keep track of what version of Windows works best with a particular application. This could then be queried on install of the application, or downloaded in bulk. It would be easy to take the data and create a registry file like what winecfg will be saving to. That way, AppDB becomes the place where this is maintained (so it is up to the individual maintainers to set the Windows version if it doesn't work with the default version) and there are no ugly heuristics involved. - Reece
Re: Functions that should be static
On Thursday 18 December 2008 10:09:02 Francois Gouget wrote: > dlls/secur32/secur32.dll.so: SECUR32_initNegotiateSP This function would (and at some point did) register the Negotiate security provider. It's not called right now because the provider is not implemented and registering it broke some applications. The better solution here would be to completely remove negotiate.c and readd it once it's implemented. > dlls/secur32/secur32.dll.so: SECUR32_strdupW This should be used by functions like e.g. QueryContextAttributesW. It's just that we cheat and not implement the parts of that function that need to allocate strings yet. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: ntdll: fix a compiler warning on PC-BSD
I'm a bit surprised that PC-BSD/FreeBSD's mkdir() does not take a mode argument. Are you sure this is really the case? Maybe we are just mising a #include directive on BSD? (Unfortunately I don't really have access to a FreeBSD box right now) -- Francois Gouget http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
Windows version autodetection
Hi There are some older applications out there, which don't install or run correctly unless Wine is emulating the correct Windows version (eg. Windows 9x). At least Windows XP has the ability to use certain heuristics to make an educated guess as to which version of Windows the application expects, and then lie in GetVersion() and behave like that version in relevant APIs. Should we do something like that for Wine? It would allow many applications to work out of the box. Damjan Jovanovic
Re: Patchwatcher offline?
Francois Gouget 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). > You know, I didn't even notice 'a day' :) -- Cheers, Paul.
