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

Re: Error at end of app install: can't open builtin library for regsvr32.exe...

by Dan Kegel

On 12/16/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > $ rm -rf .wine > > $ wine/wine notepad.exe > > /home/dank/.wine updated successfully. > > $ find .wine -name regsvr32.exe -ls > > 4669487 0 lrwxrwxrwx 1 dank dank 40 Dec 17 03:35 > > .wine/drive_c/windows/system32/regsvr32.exe -> > > /home/dank/wine/programs/regsvr32.exe.so > > Yup, exactly what I said. ? You were talking about something being overwritten with a native copy by an installer, but you can see from the log that no installer was run. > Run > 'file /home/dank/wine/programs/regsvr32.exe.so' to see what I'm talking > about. OK: $ file /home/dank/wine/programs/regsvr32.exe.so /home/dank/wine/programs/regsvr32.exe.so: symbolic link to `regsvr32/regsvr32.exe.so' $ file /home/dank/wine/programs/regsvr32/regsvr32.exe.so /home/dank/wine/programs/regsvr32/regsvr32.exe.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped What does that tell you? The file looks like a perfectly good ELF file, as one would expect. How do you explain the next line from the log, $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe wine: cannot open builtin library for L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe": /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header ? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 17, 2005

Re: Error at end of app install: can't open builtin library for regsvr32.exe...

by Vitaliy Margolen

Friday, December 16, 2005, 9:08:19 PM, Dan Kegel wrote: > On 12/15/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> > wine: cannot open builtin library for >> > L"C:\\windows\\system32\\regsvr32.exe": >> > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header >> > >> > This is with 0.9.3 built on fc3. >> >> Looks like a case of overwritten regsvr32.exe with native copy (like what >> IE6 installation will do... > Nice theory, but check this out: I can reproduce it without installing anything: Well it's not a theory, it's a fact <g> > $ rm -rf .wine > $ wine/wine notepad.exe > /home/dank/.wine updated successfully. > $ find .wine -name regsvr32.exe -ls > 4669487 0 lrwxrwxrwx 1 dank dank 40 Dec 17 03:35 > .wine/drive_c/windows/system32/regsvr32.exe -> > /home/dank/wine/programs/regsvr32.exe.so Yup, exactly what I said. Run 'file /home/dank/wine/programs/regsvr32.exe.so' to see what I'm talking about. Vitaliy

Dec. 17, 2005

Partial success report: Ability Office 4.14

by Dan Kegel

Ability Office has a Linux version done with winelib, but I wanted to go whole hog and run the Windows version using wine 0.9.3. There were a few issues along the way. I started by downloading their normal Windows setup program: wget http://www.ability.com/download4/ability4_14/setup.exe wine setup.exe This failed with fixme:urlmon:URLDownloadToCacheFileW ((nil) L"http://www.abilitydownload.com/download4/ability4_14/Ability.MSI" 0x7bc80a88 520 0 0x7b91fb00) Evidently setup.exe is just a little thing that downloads the real thing from their web site, but that doesn't work in Wine yet. So I followed their alternate download procedure: wget http://www.abilitydownload.com/download4/zip/ability4_14.zip unzip ability4_14.zip wine Ability.MSI This failed because Wine doesn't know enough to run msiexec when you do this :-( But running msiexec by hand works: msiexec Ability.MSI I could then run ability write and create documents. Visually, things looked pretty good. Performance-wise, though, it really couldn't keep up with my typing, and took waaaay too long to start up. This is on a 2GHz system with lots of RAM, so it's kind of inexcusable. Gotta go be a dad now, but thought this little bit of data would be interesting to somebody. -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 17, 2005

Re: Error at end of app install: can't open builtin library for regsvr32.exe...

by Dan Kegel

On 12/15/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > wine: cannot open builtin library for > > L"C:\\windows\\system32\\regsvr32.exe": > > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header > > > > This is with 0.9.3 built on fc3. > > Looks like a case of overwritten regsvr32.exe with native copy (like what > IE6 installation will do... Nice theory, but check this out: I can reproduce it without installing anything: $ rm -rf .wine $ wine/wine notepad.exe /home/dank/.wine updated successfully. $ find .wine -name regsvr32.exe -ls 4669487 0 lrwxrwxrwx 1 dank dank 40 Dec 17 03:35 .wine/drive_c/windows/system32/regsvr32.exe -> /home/dank/wine/programs/regsvr32.exe.so $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe wine: cannot open builtin library for L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe": /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header And better yet, I *can* run regsvr32.exe.so if I avoid the symlink: $ wine/wine wine/programs/regsvr32.exe.so (works ok) Or if I actually install wine: $ wine .wine/drive_c/windows/system32/regsvr32.exe Aha. It looks like it might have been a clash between the wine in the build directory and the old wine I had installed. So I guess it's not safe to run from the build directory if you have a copy of Wine installed on your system. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 17, 2005

Re: ScrollDC should not clip output if a clipping rect is not specified

by Rein Klazes

On Fri, 16 Dec 2005 19:06:13 +0100, you wrote: >Also visually I do not see the failure that you are supposedly fixing. Nah, I did not look straight. The flaw is visible but does not cause the test to fail. Rein.

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Alexandre Julliard

Tony Lambregts <tony.lambregts(a)gmail.com> writes: > Perhaps it's partly a matter of perception then. > > If I understand you 0.9 was a major release then, and 0.9.1 and > company are minor releases, with the next major release being 1.0. So > I anticipate that we will have a major freeze before 1.0 just like we > had before 0.9? Definitely. The 0.9.x releases should be viewed as snapshots of the current tree. They should be more stable than the alpha snapshots but that's really because I'm being more reluctant to commit big changes as we move forward. And this will be more and more the case until we get to 1.0; it's a gradual freezing process, the temperature is going down a few degrees with every snapshot... > If we could count on a release every two weeks that would be ideal. I'm planning to stick to the two weeks schedule, yes. Maybe weekly releases would be even better, but IMO that would require more automation of the release process so that the packages are available faster. > That way people like me who use CVS ( or GIT) could help prevent > regressions even getting into the minor releases, which in turn would > encourage more people to use the minor releases. I would prefer to see > that releases were done on a Tuesday, myself, since I have more free > time to track down regressions on a weekend and with some luck get > them fixed on Monday. IMO doing this would be very beneficial to > application maintainers without really changing very much what you are > currently doing. Well, there are usually a bunch of changes on Monday since they accumulate during the weekend, so I prefer to make releases on Wednesday or Thursday to leave some time for things to settle down. > One more thing. At the rate we are using up minor numbers we will be > looking at at 1.0 being released sometime in March. This seems not to > bad to me since having a major release twice a year seems pretty > reasonable. Are we planning on doing release candidates for 1.0? Or > are we just freezing the main branch. It seems to me that with GIT > having release candidates is a lot easier then it would be with CVS. There's no rule that says minor numbers have to be one digit ;-) I think it's likely to be 12 rather than 6 months between major releases, but we'll see... And yes, the 1.0 release will be off the main branch, that's where everybody is working so that's where 1.0 will be. After 1.0 there could of course be a 1.0.x stable branch in parallel with the development branch. -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Willie Sippel

Am Freitag, 16. Dezember 2005 19:48 schrieb Alexandre Julliard: > The idea is that people should test the releases. The point of the > beta phase is to encourage end users to test, and for this to happen > they need to be able to get binary packages, which is what the > releases are about. This is why I'm making releases more frequently > too, so that end users are able to test effectively without having to > build from CVS. > > The goal is not to prevent regressions between every minor point > release, it's to make releases frequently enough that regressions can > be found and fixed quickly, so that they don't creep into the next > major release. Now, if you think that doesn't work I'm certainly open > to doing things differently. What do you suggest? Yet, Wine had at least one huge regression that was well known for months (the windowed OpenGL issue, bug 2398). I think it didn't even come as a surprise, it was obviously known to happen due to the WM rewrite. Still, months later, there doesn't even seem to be an experimental fix. Lots of highly specialized apps are affected, applications that used to work just fine with Wine, and I know several guys that switched back to Windows because of that regression and the fact that there was next to no visible motivation to fix that issue. I think this regression should have been a blocker for 0.9. Right now, we have yet another known OpenGL regression (bug 4016) with no info when a fix can be expected. I reported another regression (bug 3734) that happened during the last months a while ago, that bug isn't even confirmed, yet. Granted, sounds like whining - I'm by no means a developer, but I check Wine for regressions almost daily, report bugs and maintain a few apps on appdb.winehq.org, and it seems previously working applications get broken faster than new applications start to work. The applications I test are not office apps or other 'generic' stuff, because those aren't that important IMHO (there are alternatives for Linux), but specialized niche applications (graphics, mostly) individuals and companies need working to be able to switch to Linux (or stay on Linux, as mentioned in the first paragraph). Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Tony Lambregts

On 12/16/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > Tony Lambregts <tony.lambregts(a)gmail.com> writes: > > > Well that is a real sore spot with me. You know that I am a strong > > supporter of wine but it really concerns me that we have gone beta and > > not addressed preventing regessions from getting into our releases in > > any way. We currently have no freeze or notification of exactly when > > the next release is going to go out. Sure we had the one big code > > freeze just before 0.9 but then we went back to releasing without any > > notification. At his point even if our application maintainers test > > their app every day there is no way for them to prevent that > > regression going into the next release. > > The idea is that people should test the releases. The point of the > beta phase is to encourage end users to test, and for this to happen > they need to be able to get binary packages, which is what the > releases are about. This is why I'm making releases more frequently > too, so that end users are able to test effectively without having to > build from CVS. > > The goal is not to prevent regressions between every minor point > release, it's to make releases frequently enough that regressions can > be found and fixed quickly, so that they don't creep into the next > major release. Now, if you think that doesn't work I'm certainly open > to doing things differently. What do you suggest? > Perhaps it's partly a matter of perception then. If I understand you 0.9 was a major release then, and 0.9.1 and company are minor releases, with the next major release being 1.0. So I anticipate that we will have a major freeze before 1.0 just like we had before 0.9? Since I'm pretty sure we do not have the resources to do nightly's like they did for Mozilla, then once certainly every two weeks is better than once a month. If we could count on a release every two weeks that would be ideal. That way people like me who use CVS ( or GIT) could help prevent regressions even getting into the minor releases, which in turn would encourage more people to use the minor releases. I would prefer to see that releases were done on a Tuesday, myself, since I have more free time to track down regressions on a weekend and with some luck get them fixed on Monday. IMO doing this would be very beneficial to application maintainers without really changing very much what you are currently doing. The next step up from this of course is to create a branch for bug fixes only but at this point I cannot say how beneficial that would really be. One more thing. At the rate we are using up minor numbers we will be looking at at 1.0 being released sometime in March. This seems not to bad to me since having a major release twice a year seems pretty reasonable. Are we planning on doing release candidates for 1.0? Or are we just freezing the main branch. It seems to me that with GIT having release candidates is a lot easier then it would be with CVS. -- Tony Lambregts

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Uwe Bonnes

>>>>> "Peter" == Peter Beutner <p.beutner(a)gmx.net> writes: Peter> Michael Jung schrieb: >> On Friday 16 December 2005 15:41, Peter Beutner wrote: >>> Don't get me wrong I still think it is perfectly valid that wine is >>> doing that sort of hack to get existing windows applications working >>> but you really shouldn't advertise it as a solution to platform >>> independence and encourage developers to go this way. >> If someone plans to do a new multi-platform project, I'm pretty sure >> no one in their right mind would suggest wine to do it. But there is >> a whole lot of legacy applications for which the only economically >> feasible way to port them to linux might be via wine. Peter> Agreed. This sums up quite well what I wanted to say ;) Any new project with multi platform target in mind would probably be created on a more "library like" library than Wine(lib). However I guess few projects are created that way. Projects have often a long history, and for the last year Windows was the only target was windows... So getting winelib in a more mature fashion will help all those legacy projects... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 16, 2005

msi failure

by Bill Medland

Seeing as how I know nothing much about msi I thought I'd just point out the error and ask someone more knowledgeable to do something about it. Basically on msiexec a VBA6.msi: dialog.c - msi_dialog_oncreate includes dialog->default_font = msi_dup_property (.., "DefaultUIFont"); Later on that default font can be referenced without testing if it is non-null In my particular case it is null (because the property is not found). Presumably if msi_dup_property returns null then some other default should be used, e.g. MS Shell Dlg. Any comments? Anyone volunteering to fix it? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 16, 2005