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

Re: [user32] Allocate buffer on heap (Bug 17076)
by Jeff Latimer Jan. 23, 2009

Jan. 23, 2009

Paul Vriens wrote: > > > Some called functions assume that buffer is always on heap. That isn't > the case > anymore. If you do + local_buffer = HeapAlloc(GetProcessHeap(), 0, buffer_size); shouldn't there be a HeapFree() added to match? Jeff

2 1

AppDB: Rating / Patching
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 23, 2009

Jan. 23, 2009

Hi, here are, from an obvious user perspective, my 0.02$ on the issue. - Platinum: app works "out of the box" -- without changing any settings -- *and* as well as on MS-Windows. That means no feature is missing: music plays, graphics look similar on both plattforms, the perceived speed or responsiveness is similar, ... (Question: does the need to install thrid party SW like codecs or Quicktime preclude "platinum" because it's not "out of the box"?) For anything below platinum, I don't want AppDB to ask users to compare with MS-Windows. Users either don't care about MS-Windows or don't have the time to perform a dual installation or don't even have a MS-Windows machine! Yet to gain platinum rating, I concede that the additional effort to test the application's behaviour on MS-Windows is valuable to detect discrepancies between the two ("hey, I didn't know before that the application would play background music!"). - Garbage: nobody knows how to make this app work with that version of wine. Don't buy it, you are likely wasting your time & money. Anything else gets a rating above garbage, no matter how ugly the fix or patch is. What counts is that there's a known way to make it work. - Bronze: the application shows a "promise" that some additional fixes and patches may make it work well. I'm opposed to the idea that a given AppDB version should only denote an unpatched wine in test results. Consider how Dan Kegel recently recommended distributors not to distribute 1.1.12. E.g. a hypothetical future Ubuntu package "1.1.12" may contain the official 1.1.12 plus the three patches that Dan Kegel recommends. Users would likely not know nor notice. Typically, distributors add whatever patches they feel right to the upstream releases. So it does not seem practical to have the need for a patch prevent ratings above garbage (or bronze), as some people suggested here. To me, 1.1.12 plus N patches (N "small") is still 1.1.12 as far as the AppDB is concerned. However N>0 might preclude platinum, as defined above (except for Ubuntu users). Similarly, AppDB might prevent Gold or Silver ratings depending on qualitative aspects of the steps needed to make an app work: - need for known distributable third party libraries (e.g. codecs, Quicktime) (not provided with the application's installer) - complexity of settings (winecfg vs. *.reg vs. environment variable vs. ...) - nocd or not copy-protected executables - patch to source, requiring compilation of wine E.g. Recompilation would prevent Gold? Would you agree that any application in need of a nocd would necessarily rate one level below another one not "equipped" with copy protection? Or does only the result count, and e.g. "Gold" is perfectly describing an application that works flawlessly "out of the box", except you need to replace the .exe with the nocd one between install and run? (So far I have handled it like this, a patch is not enough reason to drop a rating to garbage, this does not effectively describe the user experience.) Regards, Jörg Höhle

6 11

Running a simple .Net 3.0 application.
by Louis Lenders Jan. 23, 2009

Jan. 23, 2009

I saw some good progress is being made on getting the .net 3.0 installer fixed in wine. Nice. As it will take yet quite some time until the installer is fixed, i wondered if wine is in good shape to run .net 3.0 apps, once the installer is finished. Today I saw someone mentioning a program called InstallRite on the users-list, and using this program, I was able to get a a simple .Net 3.0 app running in wine. I thought just share my experience here, in case anyone finds it useful. The application i got running is very simple: AnimatedApplication from http://www.longhorncorner.com/UploadFile/rahul4_saxena/AnAnimatedApplicatio… (You just need register, then you can download the file) This way I got it running: 1. Fire up Windows Xp (a snapshot from a clean install) in my VirtualBox 2. Install Installrite from http://www.epsilonsquared.com/ in VirtualBox. 3. Start InstallRite, and from within InstallRite you can fire up the dotnetfx3.exe (after downloaded it) 4. After the dotnetfx3.exe finshed the install, there's an option, that you can make a "Build Install Kit". I did that, it creates an executable (foo.exe). Save it in a place where you can access it from linux 5. In wine, first do 'winetricks dotnet20' (needed for l_int.nls i guess, otherwise I got crash very early in the app) 6. Run foo.exe in wine, it will extract all files, and write all registry-keys, as if it were a successfull dotnetfx3 installation in wine. 7. Now Run the app, it crashes into a bunch of unimplemented functions. Fortunately just simple stubs were enough to make the app happy. I added stubs for gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty Well, that was enough to get the app running. I was not able to work around a problem in d3d9 ( the app just hang, displaying nothing, probably due to some unimplemented stuff in d3d9) but fortunaly disabling d3d9, was enough to get it running (WINEDLLOVERRIDES="d3d9=""" wine AnimatedApplication.exe) I'm not sure if it would be useful to open bugs already for the unimplemented functions. If so, just shout, and i'll open some bugs. Conclusion: once the installer is fixed, there's good chance simple .net 3.0 at least apps will run quickly

3 2

Re: Problems with configure on Mac
by James McKenzie Jan. 23, 2009

Jan. 23, 2009

James Mckenzie wrote: > Cesar Izurieta <cesar(a)ecuarock.net> wrote: > >> Sent: Jan 21, 2009 7:49 AM >> To: James Mckenzie <jjmckenzie51(a)earthlink.net> >> Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >> Subject: Re: Problems with configure on Mac >> >> Try something like: >> >> LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include/" ./configure >> >> You need to specify both the library dirs and the include dirs. This is >> using macports. For fink I guess the libraries are located somewhere under >> /sw IIRC. >> > > I'll find them and use them this evening after reviewing the log file. > > Used the proper directories for Fink and built it after addressing a few more 'missing dependencies'. However when I run wine notepad, I get a lengthy error. The thread on gdi32.dll errors addresses some of this. However, the .wine directory gets created but it is partially empty which leads me to believe there is a problem with my build as yours works. One question: What version of gcc are you using to build Wine? Thank you. James McKenzie

1 0

LWN Timeline for 2008: Wine 1.0 made it!
by Zachary Goldberg Jan. 23, 2009

Jan. 23, 2009

All, It seems Wine 1.0 was deemed a significant event for Linux and Free Software in 2008. http://lwn.net/Articles/Timeline2008/ Cool beans. -Zach

9 10

cmd.exe.manifest
by Luke Kenneth Casson Leighton Jan. 22, 2009

Jan. 22, 2009

0010:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\cmd.exe.manifest" 520 0xff9aaaf4 (nil)) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 100" ????? !!!! ahh fer xxxx's sake :) this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80. 0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec10000 L"C:\\windows\\system32\\cmd.exe" 0010:trace:heap:RtlFreeHeap (0x110000,00000002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec10000 type #0018 name #0001 lang 0000 level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x110000,00000002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\system32\\cmd.exe.manifest",0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (L"C:\\windows\\system32\\cmd.exe.manifest" 520 0xffdc5f14 (nil)) ... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be "themed". ... wossgoinon?! :) l.

2 5

Re: msxml3/tests:domdoc.c Test doc pointer before using it (coverity)
by Austin English Jan. 22, 2009

Jan. 22, 2009

On Thu, Jan 22, 2009 at 6:50 AM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > >From: Joris Huizer <jorishuizer(a)debian.(none)> Your e-mail is messed up in the patches. Alexandre's scripts take the patch info over the e-mail headers, so you should fix that. -- -Austin

2 1

Re: warning in wldap32/parse.c:447
by Michael Stefaniuc Jan. 22, 2009

Jan. 22, 2009

Hi! Nikolay Sivov wrote: > Hi, your patch for wldap32 added a warning: I know and I sent a patch to revert that change: http://www.winehq.org/pipermail/wine-patches/2009-January/067780.html and Alexandre rejected it: http://www.winehq.org/pipermail/wine-devel/2009-January/072151.html He is right and wrong in that email: - Right: wldap32 is broken for Win64 Wine builds - Wrong: I didn't do the long to LONG wldap32 changes but Francois. > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits > -Wpointer-arith -g -O2 -o parse.o parse.c > parse.c: In function ‘ldap_parse_vlv_controlW’: > parse.c:447: warning: passing argument 5 of ‘ldap_parse_vlv_control’ > from incompatible pointer type The warning is a minor nuisance but not an error. And that code isn't used with never openldap versions so not many people see it. That's why I didn't catch it first hand as there is no warning on F9 and F10. bye michael

1 0

Re: WMF Support
by Rolf Kalbermatter Jan. 22, 2009

Jan. 22, 2009

Erich Hoover wrote: >I ran into an issue with WMF files in helping someone get an application to >work (Athena Visual Studio) and I worked around it by pre-rendering the >application's vector WMF files. I don't currently have the time to resolve >the issue, but for when I do I'm curious whether there is a reason that >OleLoadPicture* has been implemented manually. It seems that the LGPL >"libwmf" has excellent support for both bitmap and vector WMF files (it at >least worked for converting the files I had trouble with!), so it seems to >me like it would make sense to use this library rather than spinning a >separate implementation. Any comments are appreciated. Do you have somewhere the specific WMF file in question? The license is a "bit" to expensive to buy it just to test this ;-) Rolf Kalbermatter

2 1

Re: [5/6] ddraw: Rename the main vtables to just "vtbl".
by Alexandre Julliard Jan. 22, 2009

Jan. 22, 2009

Henri Verbeet <hverbeet(a)codeweavers.com> writes: >>From ba79c111cb9a6de4d65d9e2cb9d77ef836802bc4 Mon Sep 17 00:00:00 2001 > From: Henri Verbeet <hverbeet(a)codeweavers.com> > Date: Thu, 22 Jan 2009 10:33:37 +0100 > Subject: ddraw: Rename the main vtables to just "vtbl". I hate to suggest adding Hungarian notation noise, but "lpVtbl" may be a better choice since that's the standard name in all COM macros and generated code. It would make it more obvious that this is the regular main vtable. -- Alexandre Julliard julliard(a)winehq.org

1 0