re: Poor performance when using Texas Instruments code generation tools in Wine
Anders wrote: 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. Wow, that's worth looking into! Can you write a small C program that has the same behavior? That would help us reproduce the problem and then solve it. Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: msi: detect registry keypaths
Ahh you are correct, That is unnecessary. I can rework it or you can
remove that test.
Thanks for pointing it out.
-aric
Alexandre Julliard wrote:
Aric Stewart <[EMAIL PROTECTED]> 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?
Re: status of wine dll's
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
Re: dlls/gdi: fix GetGlyphOutline(resend)
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 == 0xU || 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 [EMAIL PROTECTED]
Re: regression
--- Mike Hearn <[EMAIL PROTECTED]> wrote: > On Tue, 22 Feb 2005 01:04:33 +, Oliver Stieber > wrote: > > It doesn't look like ole at all, > > I've attached the last bit of a log with > more-or-less > > everything turned on. > > Well, I don't see the NtMapViewOfSection error in > that log. I'm not sure > what to make of it, that exception code is not in > our ntstatus.h > It turns out that NtMapViewOfSection isn't the direct problem, The NtMapViewOfSection error message is coming up with almost any app, but it was overwriting the Creatures 2 backtrace is such a way they it looked like part of the log. > thanks -mike > > > ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: Checking Wine's spec files
On Mon, 21 Feb 2005, Alexandre Julliard wrote:
[...]
Yes I think they are very useful, though I wouldn't suggest blindly
fixing things based on the reports since I suspect that at least in
some cases we have wrong ordinals and this will cause complaints about
the wrong functions.
It turns out that a lot of the functions my script complains should have
the -noname or not have the -noname property should:
* really not have a name at all
* or be marked as -private
Is this something we want to do?
This is shown by this small program which fails to link using the SDK's
shell32.lib file:
__declspec(dllimport) int __stdcall DoEnvironmentSubst(int, int);
__declspec(dllimport) int __stdcall FileMenu_AbortInitMenu();
__declspec(dllimport) int __stdcall Shell_GetImageList(int, int);
__declspec(dllimport) int __stdcall SHRegCloseKey(int);
int main()
{
DoEnvironmentSubst(0,0);
FileMenu_AbortInitMenu();
Shell_GetImageList(0,0);
SHRegCloseKey(0);
return 0;
}
Similarly in kernel32.spec we have a bunch of entry-points for Windows
9x APIs which Windows exports by ordinal only. However these APIs are
given names:
1 stdcall -register -i386 VxDCall0(long) VxDCall
24 stdcall GlobalAlloc16(long long)
That seems wrong since none of the kernel32 dlls ever exports a VxDCall0
or GlobalAlloc16 function. Shouldn't this be written as follows instead?
1 stdcall -register -i386 @(long) VxDCall
24 stdcall @(long long) GlobalAlloc16
The drawback is that this is going to make it harder to use these APIs
from other dlls (as in one would have to use GetProcAddress())...
Is this something we want to do anyway? Maybe just for the functions
which are not called from other dlls?
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
I haven't lost my mind, it's backed up on tape around here somewhere...
Re: regression
On Tue, 22 Feb 2005 01:04:33 +, Oliver Stieber wrote: > It doesn't look like ole at all, > I've attached the last bit of a log with more-or-less > everything turned on. Well, I don't see the NtMapViewOfSection error in that log. I'm not sure what to make of it, that exception code is not in our ntstatus.h thanks -mike
Re: Poor performance when using Texas Instruments code generation tools in Wine
On Tue, 22 Feb 2005 12:52:33 +0100, Anders RÃnningen wrote: > 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. That is quite possible. You can get a dump of the heap by doing a +heap trace, so there must be a function somewhere that generates it. Just trigger that when HeapFree gets too slow and see what it looks like. You might (*might*) be able to get a feel for this by hacking the code to use glibcs malloc/free instead of our own heap implementation (but only when accessing the process heap). I do not know what might break if you do that. Doug Leas malloc may or may not be higher performance than ours. thanks -mike
Re: ESD sound support in Wine 20050111
On Mon, 21 Feb 2005 13:11:46 -0800, Kumaran Santhanam wrote: > I found a patch for ESD (Enlightenment Sound Daemon) support in Wine > from July 2004. I modified this to work with Wine-20050111 and compiled > the wineesd.drv.so driver. This driver works in both Wine and CrossOver > 4.1. The patch and instructions are attached to this email. Could you submit it to wine-patches please? An esd driver would be great!
RE: [ros-dev] RE: Collection of wine tools on windows
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steven Edwards > Sent: 21. februar 2005 21:52 > To: ReactOS Development List; [EMAIL PROTECTED]; wine-devel@winehq.com > Cc: [EMAIL PROTECTED] > Subject: Re: [ros-dev] RE: Collection of wine tools on windows > > Hi, > > --- Casper Hornstrup <[EMAIL PROTECTED]> wrote: > > I might vote for using WINE headers in ReactOS if WINE > relicensed its > > headers to a w32api or BSD like license that will allow use in a > > non-free application. What I would like to see most though, > is for all > > three projects to share w32api. > > What do you mean? The headers are LGPL so you can use them in > a non-free application. > > Thanks > Steven Yes, but then you need to publish the sources for the non-free application under the LGPL. When using headers to build your application, you create a derived work of those headers. http://www.fsf.org/licensing/licenses/lgpl.html "A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".)" "4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange." Casper
ESD sound support in Wine 20050111
I found a patch for ESD (Enlightenment Sound Daemon) support in Wine from July 2004. I modified this to work with Wine-20050111 and compiled the wineesd.drv.so driver. This driver works in both Wine and CrossOver 4.1. The patch and instructions are attached to this email. I have been using it for a few weeks and it seems to be working well. It would be great if it could be incorporated into the main Wine tree. Please let me know if you have any questions. Best Regards, Kumaran Wine Enlightenment Sound Daemon support --- [Jul 2004] Original driver code by Zhangrong Huang <[EMAIL PROTECTED]> [Feb 2005] Ported to Wine 20050111 and CrossOver Office Professional 4.1 by Kumaran Santhanam <[EMAIL PROTECTED]> Instructions: 0) Make sure that esound-devel is installed. 1) Untar Wine-20050111.tar.gz 2) cd wine-20050111 3) patch -p1 configure 5) ./configure 6) make depend 7) make Binary is built as dlls/winmm/wineesd/wineesd.drv.so wineesd-20050111.patch.gz Description: Zip compressed data
Re: possibly new regression
On Mon, 21 Feb 2005 21:49:32 +0100 Rein Klazes <[EMAIL PROTECTED]> wrote: > On Sun, 20 Feb 2005 16:41:09 +0100, you wrote: > > > On Sun, 20 Feb 2005 16:04:54 +0100 > > Rein Klazes <[EMAIL PROTECTED]> wrote: > > > > > > Does this patch help? > > > > > > Rein. > > > > Unfortunately not - still the exact same error. > > Surprise :( > > OK, I can try once more, perhaps the counter is much more then the > program expects (it resets when windows is restarted, here it counts up > from 1970/1/1). Try attached patch (first reverse previous patch, them > make; make install and test again) > > Then if it does not work. As the patch fixes a real problem, reverting > is not an option. You will need to debug this to find out why the crash > happens. > > If you run this with WINEDEBUG=+relay, can you look for both > QueryPerformanceCounter or QueryPerformanceFrequency in the lines just > before the crash? > > With some luck the addresses of the call (look at ret=..) is near > where the crash happens ( it is reported by the debugger: 0x00500280) > and we can look at the disassembled code (debugger command > "disass adr1, addr2"). > > Rein. Thanks a lot! That did it. Everything is back to normal again. -- Sebastian Schlingmann
RE: Collection of wine tools on windows
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ivan Leo Puoti > Sent: 21. februar 2005 09:26 > To: wine-devel@winehq.com > Cc: [EMAIL PROTECTED] > Subject: Re: Collection of wine tools on windows > > Dimitrie O. Paun wrote: > > Heh, the MinGW folks seem to have some strange > requirements for their > > headers, I don't think they'll drop theirs. But we can > start by having > > ReactOS adopt our headers. > > > > We should also offer our headers as a separate package that > works out > > of the box as a replacement for the MinGW ones. This way people can > > just get our headers if they are better than the MinGW ones. > > Can't the win32api package headers be used to replace the > mingw headers? > > Ivan. W32api IS the MinGW headers. I might vote for using WINE headers in ReactOS if WINE relicensed its headers to a w32api or BSD like license that will allow use in a non-free application. What I would like to see most though, is for all three projects to share w32api. Casper
Re: Poor performance when using Texas Instruments code generation tools in Wine
>> 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. >> >Hi! > Maybe this can also explain the slowdown of long-running apps under wine ? >For example, DC++ runs perfectly when started, but after 12 hours of operation >the window updates, search and other program functions are so incredibly slow, >that it's better to kill it and restart. > With regards, Pavel Troller I don't know if that is specific to wine. The same happens to my edonkey on WinXP. Uses more and more memory and also handles until a restart is the better alternative. bye Fabi
Re: msi: detect registry keypaths
Aric Stewart <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
Re: SHELL32: cleanup, create unicode versions of some functions
Alexandre Julliard wrote: Actually the right way to get rid of them is to convert to Unicode. In the few cases where we actually have to work with Ansi characters they will most likely be in the Unix codepage and then switching to lstrcmpiA would be wrong. I'm on the way to converting some of the shell32 code to unicode, so the strcasecmp instances in there won't be round for too long. Mike
Re: Poor performance when using Texas Instruments code generation tools in Wine
> 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. > Hi! Maybe this can also explain the slowdown of long-running apps under wine ? For example, DC++ runs perfectly when started, but after 12 hours of operation the window updates, search and other program functions are so incredibly slow, that it's better to kill it and restart. With regards, Pavel Troller
Re: Poor performance when using Texas Instruments code generation tools in Wine
Anders Rønningen wrote: 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? ntdll is one of the DLLs which will never be able to be used in Wine. So Wine ignores any dll-override line for it. 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? Not that i know off. The Linux kernel VM is a good place to get ideas how to limit memory fragmentation. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Poor performance when using Texas Instruments code generation tools in Wine
native ntdll.dll requires kernel system call hooks that WINE doesnt support . native ntdll.dll will never work on WINE.
Poor performance when using Texas Instruments code generation tools in Wine
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:[EMAIL PROTECTED] http://www.tandberg.net
Re: Microsoft genuine downloads looking for wine
On Monday 21 February 2005 15:45, Bill Medland wrote: > > > > 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. I was thinking, there may come a day when we have our own check (say, "GenuWineCheck") to see if we're running genuine Wine, i.e. builtin dlls only. Something like the "tainted" check in the linux kernel, that enables you to discriminate binary-only modules. Because, in the end, who would want to support applications on Wine with binary only dlls mixed in? ;-) -Hans
Re: Pretty Good Solitaire shootout: Wine vs. Crossover
>> fixme:ole:SPCF_CreateInstance
>> (0x40a50d00,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x403f1ec0),
>> creating stdpic with PICTYPE_NONE.
>> fixme:ole:OLEPictureImpl_Load Could only read 67468 of 138330 bytes in
>> no-header case?
>> fixme:ole:OLEPictureImpl_Load Unknown magic 746c, 67468 read bytes: 6c
>
>Basically what is happening here is that the format VB (sometimes) stores
>images in hasn't been fully reverse engineered. There are a few gaps in
>our knowledge.
>
>IIRC (I looked at this last summer) 0x746c means "Visual Basic resource"
>and is a trivial wrapper, the reason the code pukes out is that it seems
>to be wrapped twice or something. But I'm not sure why or what this means.
This looks like the error I already tried to fix last year (without knowing what
I did :)
http://www.winehq.org/hypermail/wine-devel/2004/01/0911.html
http://www.winehq.org/hypermail/wine-devel/2004/01/0968.html
http://www.winehq.org/hypermail/wine-devel/2004/02/0036.html
http://www.winehq.org/hypermail/wine-devel/2004/02/0053.html
Maybe that's worth trying again in your case.
bye Fabi
Re: SHELL32: cleanup, create unicode versions of some functions
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > Almost all of them can be directly replaced by lstrcmpiA, the exceptions are: Actually the right way to get rid of them is to convert to Unicode. In the few cases where we actually have to work with Ansi characters they will most likely be in the Unix codepage and then switching to lstrcmpiA would be wrong. -- Alexandre Julliard [EMAIL PROTECTED]
How do I extract the symbols from a pdb file?
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/
