February 2005 - Wine-devel - list.winehq.org

Re: advapi32: Don't free csp dll when a container is deleted
by Michael Jung 23 Feb '05

23 Feb '05

On Wednesday 23 February 2005 00:04, Michael Jung wrote: > Changelog: > Don't unload Cryptographic Service Provider DLL when a key container is > deleted. There might still be open handles. Don't apply this patch, please. It fixes the crash in the "Uru Demo" installer only by coincidence. We really have to implement a reference counting scheme to solve this problem properly. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: msi: detect registry keypaths
by Alexandre Julliard 22 Feb '05

22 Feb '05

Aric Stewart <aric(a)codeweavers.com> writes: > - FIXME("Only working for installed files, not registry keys\n"); > - if ( GetFileAttributesW(path) != INVALID_FILE_ATTRIBUTES ) > - rrc = INSTALLSTATE_LOCAL; > + if (path[0]=='0') > + { > + FIXME("Registry entry.. check entry\n"); > + if (path[0]) > + rrc = INSTALLSTATE_LOCAL; > + else > + rrc = INSTALLSTATE_ABSENT; > + } Since path[0] is first checked against '0' this test doesn't seem to make much sense. What are you trying to do here? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: status of wine dll's
by Juan Lang 22 Feb '05

22 Feb '05

Alexandre wrote: > I'm not convinced we want to remove it completely, there just might be > an app somewhere that looks for it explicitly, and it doesn't cost > anything to keep it. If so, that app won't work on windows; most versions of windows only ship with rsaenh.dll. The only ones that have rsabase are really old versions, and those that are sold in the crypto-export-restricted countries. I think removal makes more sense, keeping rsabase costs a little confusion. --Juan __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

Re: dlls/gdi: fix GetGlyphOutline(resend)
by Huw Davies 22 Feb '05

22 Feb '05

On Tue, Feb 22, 2005 at 11:31:30PM +0900, TANABE Hiroshi wrote: > @@ -2903,7 +2901,8 @@ > TM.tmStruckOut = font->strikeout; > > /* Yes TPMF_FIXED_PITCH is correct; braindead api */ > - if(!FT_IS_FIXED_WIDTH(ft_face)) > + if(!FT_IS_FIXED_WIDTH(ft_face) && > + (pOS2->version == 0xFFFFU || pOS2->panose[3]!=9)) > TM.tmPitchAndFamily = TMPF_FIXED_PITCH; > else > TM.tmPitchAndFamily = 0; Isn't this a bug in FreeType? If we have to have this in Wine, could you use the defines in wingdi.h instead of the '3' and the '9'? Huw. -- Huw Davies huw(a)codeweavers.com

1 0

regression
by Oliver Stieber 22 Feb '05

22 Feb '05

Hi, I've had a regression with Creatures 2 between and 2005-02-03 and 2005-02-19.. Creatures 2 makes heavy use of out-of-process COM for it's components, the main screen used to work ok (but the components didn't). Now it starts up and I get the error. "err:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported" I'll try to find out what patch caused the regression. 1 0x405168ec RaiseException 2 0x5f45394berr:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported ?? in mfc42 (0x406ffcd8) 3 0x5f40d992 ?? in mfc42 (0x0047ceb8) ...stack missing. other threads are waiting for ConnectNamedPipe,sync.c:1311 RPCRT4_Receive,rpc_message.c:312 RPCRT4_process_packet,rpc_server.c:316 ... RPCRT4_server_thread, rpc_server.c:506 User_update_thread, dsurface/user.c:515 RPCRT4_worker_thread, rpc_server.c:353 ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 4

Poor performance when using Texas Instruments code generation tools in Wine
by Anders Rønningen 22 Feb '05

22 Feb '05

Hi ! We have some performance problems with Wine that we could use some help on.. Here's the story: We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...). We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms. We do not have the same problem when building the code under Windows, so we tried to use the native ntdll.dll from Windows instead of ntdll.dll.so, hoping that this would solve the performance issue. We are aware that this is not recommended, but wanted to give it a try anyway. We added the dll file to the global dll-override section in the config file under ~/.wine/config, but it seems like Wine just looks for the builtin dll. We see from strace that we access the correct config file at startup. Is override of ntdll not supported, or have we missed something? If it is supported, is it likely that it is going to work? We have read some posts in the newsgroup about the heap issues. It seems that people agree that the heap should be improved, either by tweaking the existing code, or by using another heap implementation. Is any work planned on this? -- Regards / Mvh - Anders Rønningen Engineer R&D TANDBERG Phone: +47 67 125 125 Direct: +47 67 838 584 Mobile: +47 97 791 217 Fax: +47 67 125 234 mailto:anders.ronningen(a)tandberg.net http://www.tandberg.net

6 5

Re: SHELL32: cleanup, create unicode versions of some functions
by Dmitry Timoshkov 22 Feb '05

22 Feb '05

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * cleanup, create unicode versions of _ILCreateFromPath, > _ILCreateGuidFromStr, and _ILCreateFromFindData > @@ -524,7 +516,7 @@ BOOL WINAPI ILIsEqual(LPCITEMIDLIST pidl > _ILSimpleGetText(pidltemp1, szData1, MAX_PATH); > _ILSimpleGetText(pidltemp2, szData2, MAX_PATH); > > - if (strcasecmp ( szData1, szData2 )!=0 ) > + if (strcasecmp( szData1, szData2 )) > return FALSE; > > pidltemp1 = ILGetNext(pidltemp1); > @@ -574,7 +566,7 @@ BOOL WINAPI ILIsParent(LPCITEMIDLIST pid > _ILSimpleGetText(pParent, szData1, MAX_PATH); > _ILSimpleGetText(pChild, szData2, MAX_PATH); > > - if (strcasecmp ( szData1, szData2 )!=0 ) > + if (strcasecmp( szData1, szData2 )) > return FALSE; As a common rule strcasecmp should never be used in Wine code, since it introduces problem with portability and unexpected side effects when locale of the underlying system differs from a Wine one. You could make it a part of your clean up as well :-) -- Dmitry.

3 4

Microsoft genuine downloads looking for wine
by Ivan Leo Puoti 22 Feb '05

22 Feb '05

As some of you may know, Microsoft is planning to totally restrict access to the Microsoft download center to all non-genuine windows users. So you would expect some check for pirated copies of windows to be involved. If you visit the download center with IE you get an activex control, but if you try with Firefox, you'll have to download a little program, that returns a code you have to copy into the download page, to get access to the download you selected. By quickly looking at the program, I noticed it looks for a registry key, this key is... SOFTWARE\Wine\Wine\Config the wine configuration key. the Windows Genuine Advantage program press release http://www.microsoft.com/presspass/press/2005/jan05/01-26GenuineAdvantagePR… says that in the second half of 2005, all users connecting to the Microsoft download center or to windows update will have to validate their copy of windows. Interestingly if you run the validation program on wine, and the version of windows you're emulating is prior to 2000 or is windows server 20003, you get a message saying a validation code couldn't be found, because of technical difficulties or because you're running an unsupported operating system. If you set winver to win2000, you'll get a validation code that doesn't work, this may be a bug in wine, or in the validation program. A valid and working code is returned if the version is set to xp. Still, even if this is only an initial attempt, they appear to want to discriminate wine users, while this may be acceptable for operating system components/updates, this is probably a violation of anti-trust law for all other downloads. It's also the first time Microsoft acknowledges the existence of Wine. Ivan Leo.

15 19

How do I extract the symbols from a pdb file?
by Fredrik �hrstr�m 22 Feb '05

22 Feb '05

Hi all! I am trying to to write a tool that uses the code in dbghelp to do this but I am unclear on which interface I should use to do this. Can I link to dbghlp.dll.so or do I have to write a tool inside Wine for this? I am going to use the symbol info to load a full minidump and extract information from it.... Thanks! Fredrik Öhrström _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

Collection of wine tools on windows
by Boaz Harrosh 21 Feb '05

21 Feb '05

There is a question at the end. Background: I'm putting up a Web-corner with ATL & MFC for other (gcc for now) Compilers. It will include tools, links, documentation, example makefiles, and so on to let people take an MSVC project and compile it under GCC. (+Winelib on other than windows platforms) My first release target is Windows/ReactOS MinGW-PE. What I did is take the work I've done on Linux and port it back to MinGW. At first, as I expected, it did not work at all. So what I did without hesitation is fetch the Wine headers set, + (yes) wine-msvcrt. Completely removed MinGW originally supplied headers put Wine on the Include path, and voila It was compiling Just like on Linux. (Well it didn't link, than it didn't run, because of the weak symbols thing but I fixed all that). I find 3 things bad about MinGW headers. (Please don't take this as flame. I have all the admiration for all involved and no offense is intended) 1) MinGW header-set are Evil - Because they are ugly, with this, no variables names, and all this style for machines guide. This I already carry for 10 years so here it is off my chest. 2) Win32 is not complete - I would say that MFC and ATL/WTL are a very good exercise for the completeness of the Win32 API. Well the wine stuff have every thing we need, MinGW does not 3) msvcrt - msvcrt compatibility is far from satisfactory on MinGW. Wine, since they had to re-implement msvcrt.dll had to have all these funny MS permutations of the c run time. Compiling on MinGW is almost like using wine without MBCS defined. MinGW headers are mainly derived from GCC c-runtime, with a few adjustments for the -mno-cygwin mode. But they are greatly missing all the esoteric stuff that is needed by MFC and ATL. Wine is perfect, thanks to CodeWeavers, need to run all these MFC apps out there. 4) (I know I said 3) It is time, that all projects collaborate on ONE set of headers and ReactOS is the bridge to that - It is a long time do, that Wine's Set of headers are adopted by all projects. MinGW concentrates on PE gcc compilers, and pass the Win32 project to wine. Wine will release a headers only package for every body to use. (This is what I'll do on first release of my project) [Question to the ReactOS team] The windres utility is insufficient for Most of the projects out there. For example one reason my project is not already on the air. (And hence my post) is that it refuses to compile my Toolbar resource tag. (And what is an MFC app with out a toolbar). I have seen some work done on porting wrc to PE is that work done and will you have a pre-compiled binary package for use to use on windows/ReactOS. Same applies to widl. ReactOS should adopt all these Wine tools as part of their regular tools portfolio. MinGW should adopt Wine's / ReactOS's leadership on all these technologies and supply-link to them by default. Go duplicate all these goodies the wine guys are preparing for us with widl. Again guys please let the passed be gone. And put our differences behind us. There are grate things happening, clearly Wine is the Leader here, lets do this sooner than later. Dimi I need your help here Free Life Boaz

5 8