February 2009 - Wine-Devel - list.winehq.org

Wine64 : Trying to load PE image for unsupported architecture (I386)

by Erik de Castro Lopo

Hi all, I build Wine64 using the instructions here: http://wiki.winehq.org/Wine64 While I expected it to not work with my Win64 program I was a little surprised that when running a WIn32 program I got: Trying to load PE image for unsupported architecture (I386) I realise that the Win64 stuff is experimental but I'm curions, in the longer term is it expected that one executable will be able to run both Win32 and Win64 executables? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- J. Headley: "God, root, what is difference ?" G. Haverland: "God can change the byte order on the CPU, root can't."

Feb. 11, 2009

How to get more info on timed out/crashed tests?

by Juan Lang

Hi all, there are a number of tests at test.winehq.org that indicate that they're timed out or crashed. The difficulty is, I have no access to machines running the version of Windows on which the test is timing out or failing, and the data about the crash are not helpful in pinpointing the failing test. How can we get more information about these timeouts/crashes? --Juan

Feb. 11, 2009

Re: winedos: Replace [c]alloc() with HeapAlloc()

by Andrew Talbot

Andrew Talbot wrote: Sorry, title should be: winedos: Replace [m|c]alloc() with HeapAlloc() -- Andy.

Feb. 11, 2009

Re: An idea for the appdb

by Matt 'Murph' Finnicum

On Wed, Feb 11, 2009 at 2:33 PM, <alex(a)centroidcafe.com> wrote: > > > On Wed, 11 Feb 2009 13:03:21 -0700 (GMT-07:00), James Mckenzie > <jjmckenzie51(a)earthlink.net> wrote: >>> >>>Automatic submission of test data could be a very handy tool. >>> >> This would be great, but as previously discussed, who would maintain this >> information >> and verify it is correct and proper? Although some features would be >> 'neet to have' >> it is best to leave them on the drawing board for now and work on the >> various bugs >> that require workarounds. This is because of two limited resources: >> People and Time. >> If you have the skills to implement this feature, go ahead and try on a >> limited database >> on your home system. You would quickly see that we have about 10,000 >> applications >> in the AppDB and there are many versions of Wine. > > Ten thousand records in a database is not very significant. My day job is > DBA, so I might have the skills to tackle something like this (at least in > part). > >> This gives you some >> starting point >> of the size of this task. Supporting a few applications would lead to > the >> 'why isn't >> my wiz-bang application there' and a great deal of discussion, wasting >> more resources. >> >> Of course, if you could produce something that would emulate the "Report >> to ...." >> functionality that is in popular use, that would help keep the AppDB and >> Bugzilla >> up to date as long as a search capability were added to sweep these >> systems for >> pre-existing entries related to the current problem. >> > > This was what I was thinking. Microsoft does this in Windows, and they are > the reference implementation of the Wine API. If collecting this data helps > M$ debug Windows, then I would think it would certainly help Wine too. > >> Just my opinion, but this project is not worth attempting at this point. >> > > If that is the consensus, then I won't bother looking into this further. > However, it seems like there is currently a movement to rework AppDB > anyway, so why not consider this idea now, so it could be factored into > those plans? > > -Alex > > > > Why not just write a external utility (perhaps with a bit of support from AppDB for mapping exe's to applications) so that a GUI user could just right click->AppDB and have their browser fire up? That'd be neat, much less complex, and completely non-invasive. --Murph

Feb. 11, 2009

Re: An idea for the appdb

by alex＠centroidcafe.com

On Wed, 11 Feb 2009 13:03:21 -0700 (GMT-07:00), James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: >> >>Automatic submission of test data could be a very handy tool. >> > This would be great, but as previously discussed, who would maintain this > information > and verify it is correct and proper? Although some features would be > 'neet to have' > it is best to leave them on the drawing board for now and work on the > various bugs > that require workarounds. This is because of two limited resources: > People and Time. > If you have the skills to implement this feature, go ahead and try on a > limited database > on your home system. You would quickly see that we have about 10,000 > applications > in the AppDB and there are many versions of Wine. Ten thousand records in a database is not very significant. My day job is DBA, so I might have the skills to tackle something like this (at least in part). > This gives you some > starting point > of the size of this task. Supporting a few applications would lead to the > 'why isn't > my wiz-bang application there' and a great deal of discussion, wasting > more resources. > > Of course, if you could produce something that would emulate the "Report > to ...." > functionality that is in popular use, that would help keep the AppDB and > Bugzilla > up to date as long as a search capability were added to sweep these > systems for > pre-existing entries related to the current problem. > This was what I was thinking. Microsoft does this in Windows, and they are the reference implementation of the Wine API. If collecting this data helps M$ debug Windows, then I would think it would certainly help Wine too. > Just my opinion, but this project is not worth attempting at this point. > If that is the consensus, then I won't bother looking into this further. However, it seems like there is currently a movement to rework AppDB anyway, so why not consider this idea now, so it could be factored into those plans? -Alex

Feb. 11, 2009

Re: An idea for the appdb

by James Mckenzie

-----Original Message----- >From: alex(a)centroidcafe.com >Sent: Feb 11, 2009 10:59 AM >To: wine-devel(a)winehq.org >Subject: Re: An idea for the appdb > >Sorry .. forgot to reply all. > >Automatic submission of test data could be a very handy tool. Scenario: >User A tries to run an application, it crashes due to bugs in Wine. User A >elects to submit data. Sometime in the future, User B tries to run the same >application under a similar configuration. It crashes also, but User B >being a sly user figures out what DLL overrides, patches, etc. allow this >app to progress past the original crash point. Wine detects this and >collects the information. Now when User C tries to run this app, Wine >displays a message like: "This application has been known to fail under the >current configuration. However, workarounds have been discovered that may >yield greater success. <link to AppDB>" > This would be great, but as previously discussed, who would maintain this information and verify it is correct and proper? Although some features would be 'neet to have' it is best to leave them on the drawing board for now and work on the various bugs that require workarounds. This is because of two limited resources: People and Time. If you have the skills to implement this feature, go ahead and try on a limited database on your home system. You would quickly see that we have about 10,000 applications in the AppDB and there are many versions of Wine. This gives you some starting point of the size of this task. Supporting a few applications would lead to the 'why isn't my wiz-bang application there' and a great deal of discussion, wasting more resources. Of course, if you could produce something that would emulate the "Report to ...." functionality that is in popular use, that would help keep the AppDB and Bugzilla up to date as long as a search capability were added to sweep these systems for pre-existing entries related to the current problem. Just my opinion, but this project is not worth attempting at this point. James McKenzie

Feb. 11, 2009

Re: An idea for the appdb

by Austin English

This was discussed a couple months ago, nearly to death. It's a cool idea, sure, but a ton of work to do, and not really worth the effort. The data is quickly outdated with new wine versions. Some users may consider it spyware, developers would find it annoying, and overall, it would be a big mess. Read the old thread for more information. On 2/11/09, alex(a)centroidcafe.com <alex(a)centroidcafe.com> wrote: > Sorry .. forgot to reply all. > On Wed, 11 Feb 2009 18:08:47 +0200, Gert van den Berg > <wine-devel(a)mohag.net> wrote: >> On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade(a)gmail.com> wrote: >>> I can also see what you mean about >>> spyware, but other apps retrieve stuff from the web if there is a >>> connection (CDDB, and album covers are two examples). >>> >> Wine transmitting every application I run to someone else would be >> rather worrying... >> >> It should rather be opt-in. Such as "Wine has detected that it is the >> first time you run this application, do you want to check AppDb for >> more information (Yes/No/Ask again/Never ask for any application)" It >> must be easy to disable globally as well... It might have some other >> uses as well such as "A newer version of the application works >> better", etc. >> >> I might be handy to allow automatic submission of test data to AppDb >> (which IMHO might be more useful than just retrieving...), which >> should automatically include the Wine executables' checksums + >> version, distro info (if accessible from lsb-release, parts of the >> uname output & kernel checksum, which might be used to detect the >> distro), kernel version, cpu architecture, X server name and version, >> graphics driver name and version, DLL overrides, etc. This might help >> modified wine versions and the level of tweaks to be detected by AppDb >> automatically. (There should be a very specific opt-in process for >> this data's submission though, such as letting the user manually >> upload a file with this data and fully disclosing the file's contents) >> This kind of data can be handy for bug reports as well. >> > Automatic submission of test data could be a very handy tool. Scenario: > User A tries to run an application, it crashes due to bugs in Wine. User A > elects to submit data. Sometime in the future, User B tries to run the same > application under a similar configuration. It crashes also, but User B > being a sly user figures out what DLL overrides, patches, etc. allow this > app to progress past the original crash point. Wine detects this and > collects the information. Now when User C tries to run this app, Wine > displays a message like: "This application has been known to fail under the > current configuration. However, workarounds have been discovered that may > yield greater success. <link to AppDB>" > > That would be pretty sweet, no? > > -Alex Corrado > > > > -- -Austin

Feb. 11, 2009

Re: An idea for the appdb

by alex＠centroidcafe.com

Sorry .. forgot to reply all. On Wed, 11 Feb 2009 18:08:47 +0200, Gert van den Berg <wine-devel(a)mohag.net> wrote: > On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade(a)gmail.com> wrote: >> I can also see what you mean about >> spyware, but other apps retrieve stuff from the web if there is a >> connection (CDDB, and album covers are two examples). >> > Wine transmitting every application I run to someone else would be > rather worrying... > > It should rather be opt-in. Such as "Wine has detected that it is the > first time you run this application, do you want to check AppDb for > more information (Yes/No/Ask again/Never ask for any application)" It > must be easy to disable globally as well... It might have some other > uses as well such as "A newer version of the application works > better", etc. > > I might be handy to allow automatic submission of test data to AppDb > (which IMHO might be more useful than just retrieving...), which > should automatically include the Wine executables' checksums + > version, distro info (if accessible from lsb-release, parts of the > uname output & kernel checksum, which might be used to detect the > distro), kernel version, cpu architecture, X server name and version, > graphics driver name and version, DLL overrides, etc. This might help > modified wine versions and the level of tweaks to be detected by AppDb > automatically. (There should be a very specific opt-in process for > this data's submission though, such as letting the user manually > upload a file with this data and fully disclosing the file's contents) > This kind of data can be handy for bug reports as well. > Automatic submission of test data could be a very handy tool. Scenario: User A tries to run an application, it crashes due to bugs in Wine. User A elects to submit data. Sometime in the future, User B tries to run the same application under a similar configuration. It crashes also, but User B being a sly user figures out what DLL overrides, patches, etc. allow this app to progress past the original crash point. Wine detects this and collects the information. Now when User C tries to run this app, Wine displays a message like: "This application has been known to fail under the current configuration. However, workarounds have been discovered that may yield greater success. <link to AppDB>" That would be pretty sweet, no? -Alex Corrado

Feb. 11, 2009

Download page requires too much scrolling...

by Dan Kegel

While I was generating screenshots for my presentation, I noticed that http://www.winehq.org/download/ has too much clutter at the top. I don't mind the Codeweavers ad, but it's not good that users have to scroll down to see the useful part of the page...

Feb. 11, 2009

Re: ntdll: add a warning about running wine as root (resend)

by Austin English

On Wed, Feb 11, 2009 at 11:40 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: >> $ wine setup.exe # program doesn't work/error about admin rights/etc. >> $ sudo wine setup.exe >> wine: '/home/user/.wine' is not owned by you, refusing to create a >> configuration directory there >> $ sudo su >> # wine setup.exe > > Ok, if I understand you, one of the following things happens after that: > * The program succeeds because root's .wine directory is pristine. > That's bad. The user should just be running a new WINEPREFIX instead > of root. Yes. That, or some users try root from the beginning. > Simply putting up an obstacle without suggesting an alternative won't > help anyone. The permissions check cut down on people using sudo quite a bit. Removing drive c from winecfg prevented a lot of people mapping it to windows drives. Users are creative. Watch the forums and you'll notice these things. > So we should be looking for a way to encourage users to try a new > WINEPREFIX before trying things as root? Of course. We already encourage not running as root, but that doesn't mean it sinks in. Enforcing it in the code actually does some good. -- -Austin

Feb. 11, 2009