- Wine-Devel - list.winehq.org

Re: dlls/gdi: fix GetGlyphOutline(resend)
by Huw Davies Feb. 22, 2005

Feb. 22, 2005

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 Feb. 22, 2005

Feb. 22, 2005

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 Feb. 22, 2005

Feb. 22, 2005

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 Feb. 22, 2005

Feb. 22, 2005

"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 Feb. 22, 2005

Feb. 22, 2005

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 Feb. 22, 2005

Feb. 22, 2005

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 Feb. 22, 2005

Feb. 22, 2005

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

Re: "bachelor project" with wine ?
by Dan Kegel Feb. 22, 2005

Feb. 22, 2005

Joris Huizer wrote: > I'm supposed to choose a topic - and work it out - for a "bachelor > project"; > Now, at the moment I have no clue, and teachers are discussing what > topics to hand; in the mean time, I think maybe it might be interesting > to do some wine work in such a form that it's ok for this "bachelor > project" :) > > This project is supposed to be something like 308 hours; and of course, > it should be possible to show something interesting at the end of that. > About my background, I have a few years of (simple) programming > experience (in C and C++, mostly) and most of that was done under linux > -- just school programs most of the time; I don't have much experience > with X programming and *none at all* with winapi; > Is there a "project"/are there "projects" in wine, suitable for this? Absolutely. I'm sure others will suggest more ideas, but here's my suggestion: add some test cases to the Wine conformance test suite. I am mentoring about 14 college students doing this right now for college credit; four are doing it for a whole year, ten are doing it for a single semester. They are finding it appropriately challenging, and I think you will, too. See http://www.kegel.com/wine/sweng/ for the step-by-step instructions I wrote up for the semester class. (I'll be revising that as the semester continues to address issues found by the students.) Good luck, and feel free to write me with any questions! - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: Add new headers and changes in headers about security
by Alexandre Julliard Feb. 21, 2005

Feb. 21, 2005

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Move definitions from winerror.h to issperr.h. I don't think you want to do that, issperr.h is supposed to be an obsolete header. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Re: World Of Warcraft
by fenix＠club-internet.fr Feb. 21, 2005

Feb. 21, 2005

Hi lionel, GL_VERSION isn't pertinent as it contains (only) provider and driver version while GLX_VERSION is really the version string of GLX impl. Regards, Raphael ----Message d'origine---- >De: Lionel Ulmer <lionel.ulmer(a)free.fr> >A: Raphael <fenix(a)club-internet.fr> >Copie à: Alex Woods <wine-devel(a)giblets.org>, wine-devel(a)winehq.org >Sujet: Re: World Of Warcraft >Date: Mon, 21 Feb 2005 21:44:31 +0100 > >On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote: >> Ouppsss >> >> better patch > >Why did you do this change: > >- const char *gl_version = (const char *) glGetString(GL_VERSION); >+ const char *gl_version = glXGetClientString(display, GLX_VERSION); > >I.e. replacing the GL version with the one of GLX ? Maybe the GLX version is >needed, but we could then log both of them and not replace GL by GLX. > > Lionel > >-- > Lionel Ulmer - http://www.bbrox.org/ > >

2 1