April 2007 - Wine-Devel - list.winehq.org

Re: dbghelp: Directly use Heap functions.

by Eric Pouech

Markus Amsler a écrit : >> > I cant try it at the moment, but I tried also the same approach. It > went down from 100s to around 27s compared to 18s with Heap functions. > The other problem here is, not all allocated memory is used, the gaps > in not first nodes never gets filled. > Also IMO memory allocation logic should only coded once. > I will try it with the HeapCreate/HeapDestroy for every > pool_init/pool_destroy as mentioned by Frank. Let's see what the > overhead of HeapCreate is. you have to check the overhead both in terms of speed, but also in terms of overall memory consumption A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 30, 2007

Re: Winscard support (for smart cards)

by Eric Pouech

Mounir IDRASSI a écrit : > Hi Eric, > I have tested your hint concerning the final single call to > MultiByteToWideChar in order to convert the whole area but it didn't > work: even when I specify the whole length of the multi-string, it keeps > stoping at the first NULL character. I guess MultiByteToWideChar and > WideCharToMultiString don't understand multi-strings ( MSDN say nothing > about that). > they should work across the whole buffer are you sure you don't pass -1 as the length for the input buffer ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 30, 2007

Re: dbghelp: Directly use Heap functions.

by Markus Amsler

Eric Pouech wrote: > Markus Amsler a écrit : >> Dmitry Timoshkov wrote: >>> The old code at least bothered to actually free some memory. >> Good point. I wasn't aware that some memory is only temporarily >> used. I'm going to rework it. >> >> Markus >> >> >> >> > does this patch gives you lots of improvements ? > A+ > > ------------------------------------------------------------------------ > > diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c > index e196143..c3ccaf5 100644 > --- a/dlls/dbghelp/storage.c > +++ b/dlls/dbghelp/storage.c > @@ -73,30 +73,28 @@ void pool_destroy(struct pool* pool) > > void* pool_alloc(struct pool* pool, unsigned len) > { > - struct pool_arena** parena; > struct pool_arena* arena; > void* ret; > > len = (len + 3) & ~3; /* round up size on DWORD boundary */ > assert(sizeof(struct pool_arena) + len <= pool->arena_size && len); > > - for (parena = &pool->first; *parena; parena = &(*parena)->next) > + for (arena = pool->first; arena; arena = arena->next) > { > - if ((char*)(*parena) + pool->arena_size - (*parena)->current >= len) > + if ((char*)arena + pool->arena_size - arena->current >= len) > { > - ret = (*parena)->current; > - (*parena)->current += len; > + ret = arena->current; > + arena->current += len; > return ret; > } > } > - > + > arena = HeapAlloc(GetProcessHeap(), 0, pool->arena_size); > if (!arena) {FIXME("OOM\n");return NULL;} > > - *parena = arena; > - > ret = (char*)arena + sizeof(*arena); > - arena->next = NULL; > + arena->next = pool->first; > + pool->first = arena; > arena->current = (char*)ret + len; > return ret; > } > I cant try it at the moment, but I tried also the same approach. It went down from 100s to around 27s compared to 18s with Heap functions. The other problem here is, not all allocated memory is used, the gaps in not first nodes never gets filled. Also IMO memory allocation logic should only coded once. I will try it with the HeapCreate/HeapDestroy for every pool_init/pool_destroy as mentioned by Frank. Let's see what the overhead of HeapCreate is. Markus

April 30, 2007

[try 2] Move console input/output codepages to server - what's wrong?

by Kirill K. Smirnov

Hi, A week ago I've sent a patch which fixes console input/output codepages handling. http://www.winehq.org/pipermail/wine-patches/2007-April/038429.html It is still not applied, so please, explain, what is wrong with it? It even fixes 2 tests: $wine kernel32_test.exe.so process before: process: 510 tests executed (0 marked as todo, 6 failures), 0 skipped. after: process: 510 tests executed (0 marked as todo, 4 failures), 0 skipped. Thanks, -- Kirill

April 30, 2007

Re: Winscard support (for smart cards)

by Mounir IDRASSI

Hi Eric, I have tested your hint concerning the final single call to MultiByteToWideChar in order to convert the whole area but it didn't work: even when I specify the whole length of the multi-string, it keeps stoping at the first NULL character. I guess MultiByteToWideChar and WideCharToMultiString don't understand multi-strings ( MSDN say nothing about that). Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > you have to ensure that binary compat is present for both pcsc-lite > and MS APIs > if not, then you'll have to convert back and forth the non "portable" > types > actually, we don't provide exported variables when those are used from > a native module (those would work from a builtin module though) > if you really need to access them from a builtin module you have to: > - define a pointer to this (exported) variable > - get the address of this variable: > GetProcAddress(GetModuleHandle("modname.dll"), "varname") > - access the variable through the pointer > > A+ >

April 30, 2007

Re: Winscard support (for smart cards)

by Eric Pouech

Mounir IDRASSI a écrit : > Hi , > Thank you for all your comments. > Concerning the header files, they contain portions taken from Microsoft > headers. We will rewrite them to remove any copyright issues. > For the types used, they are more close to pcsc-lite than Microsoft but > still compatible at the binary level. We will modify them to be more > close to MS SDK definitions. > you have to ensure that binary compat is present for both pcsc-lite and MS APIs if not, then you'll have to convert back and forth the non "portable" types > We understand the issue of having a big patch. I'll split it into small > parts as you advised. The same applies to winscard.c file. > Concerning the exported variables, we think we have followed the msvcrt > example: "@ extern name" in the spec file and the declaration in a c > file. The variables exported are visible from win32 programs and are > used without any problem. > However, there is still an issue: when when try to compile a source file > that uses them using winegcc, we get an unresolved symbol error. Did we > miss something? The only difference we see with msvcrt source is that > winscard exported variables have a structure as a type, whereas msvcrt > exported variables are pointers. > actually, we don't provide exported variables when those are used from a native module (those would work from a builtin module though) if you really need to access them from a builtin module you have to: - define a pointer to this (exported) variable - get the address of this variable: GetProcAddress(GetModuleHandle("modname.dll"), "varname") - access the variable through the pointer A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 30, 2007

Re: [PATCH 2/11] msi: Add base class for OLE automation objects.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > +interface AutomationObject { > + /* > + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo > + */ > + const IDispatchVtbl *lpVtbl; > + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; > + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; > + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; IProvideClassInfo and IProvideClassInfo2 are base classes of IProvideMultipleClassInfo, so you don't need 3 different vtbls. -- Alexandre Julliard julliard(a)winehq.org

April 30, 2007

Re: Winscard support (for smart cards)

by Mounir IDRASSI

Hi , Thank you for all your comments. Concerning the header files, they contain portions taken from Microsoft headers. We will rewrite them to remove any copyright issues. For the types used, they are more close to pcsc-lite than Microsoft but still compatible at the binary level. We will modify them to be more close to MS SDK definitions. We understand the issue of having a big patch. I'll split it into small parts as you advised. The same applies to winscard.c file. Concerning the exported variables, we think we have followed the msvcrt example: "@ extern name" in the spec file and the declaration in a c file. The variables exported are visible from win32 programs and are used without any problem. However, there is still an issue: when when try to compile a source file that uses them using winegcc, we get an unresolved symbol error. Did we miss something? The only difference we see with msvcrt source is that winscard exported variables have a structure as a type, whereas msvcrt exported variables are pointers. Cheers, Mounir IDRASSI IDRIX – Cryptography and IT Security Experts http://www.idrix.fr Eric Pouech wrote: > from a cursory look, it looks a very goot start !!! > > a couple of comments though: > - some functions are declared (), they should be (void) (it's C, not C++) > - wstrlen already exists: it's strlenW (even if we don't check for > NULL strings) > - don't use malloc/free but rather HeapAllocate... in windows, malloc > boils down to HeapAllocate through msvcrt, but in Wine it uses the > glibc one, which is not what you want > - ConvertListToANSI: IMO, after computing the final length, only a > single call to MultiByteToWideChar is necessary (it will convert the > whole area) > - ditto for ConvertListToWideChar > - headers: > + the rule for including new headers in Wine is really to have them > fully retyped... looking at the comments in the file, it looks to me > you mostly copied the existing headers and their comments as well > + some types are not the correct ones (at least on my latest SDK) > => e.g. you use long for SCARDCONTEXT whereas it's defined as a > ULONG_PTR (it will not correctly work when compiling on a 64bit > machine) (I'm not saying that your code must be 64 compliant at first, > but the headers must be) > - spec file: > + don't define an entry point if you don't absolutely need it (most > of them should still be stubs) > - you still use C++ comments, whereas Wine only allows C comments > > from the inclusion into Wine, it's already way to big to be included > in a single operation. So, you should split up your work in smaller > pieces. For example: > - patch #1-3: new header files > - patch #4: bare DLL infrastructure (mostly .spec file (only stubs), > Makefile.in and .c file with DllMain, configure.ac) > - patch #5: a small set of functions XXX (c file, modified .spec file) > - patch #6: a small set of functions YYY (c file, modified .spec file) > > it would be also interesting to think about having several c files for > the DLL (given the number of APIs to implement) > > finally, it seems that the DLL exports some variables => they have to > be specially handled (see details on how to do it in some other DLLs, > like msvcrt) > > A+ >

April 30, 2007

Re: kernel32: Add AllUsersPfogile env variable to each process during init.

by Alexandre Julliard

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > Native initializes this variable somewhere during the log-on. And since > Wine doesn't really have such a thing, it's more logical to do it during > the process initialization. The only side affect is that if registry values > change, new process will get new value. If it's set during logon on Windows, it's very unlikely that an app would depend on modifying this, so you could set it in the registry once and for all. -- Alexandre Julliard julliard(a)winehq.org

April 30, 2007

Re: dbghelp: Directly use Heap functions.

by Eric Pouech

Markus Amsler a écrit : > Dmitry Timoshkov wrote: >> The old code at least bothered to actually free some memory. > Good point. I wasn't aware that some memory is only temporarily used. > I'm going to rework it. > > Markus > > > > does this patch gives you lots of improvements ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) diff --git a/dlls/dbghelp/storage.c b/dlls/dbghelp/storage.c index e196143..c3ccaf5 100644 --- a/dlls/dbghelp/storage.c +++ b/dlls/dbghelp/storage.c @@ -73,30 +73,28 @@ void pool_destroy(struct pool* pool) void* pool_alloc(struct pool* pool, unsigned len) { - struct pool_arena** parena; struct pool_arena* arena; void* ret; len = (len + 3) & ~3; /* round up size on DWORD boundary */ assert(sizeof(struct pool_arena) + len <= pool->arena_size && len); - for (parena = &pool->first; *parena; parena = &(*parena)->next) + for (arena = pool->first; arena; arena = arena->next) { - if ((char*)(*parena) + pool->arena_size - (*parena)->current >= len) + if ((char*)arena + pool->arena_size - arena->current >= len) { - ret = (*parena)->current; - (*parena)->current += len; + ret = arena->current; + arena->current += len; return ret; } } - + arena = HeapAlloc(GetProcessHeap(), 0, pool->arena_size); if (!arena) {FIXME("OOM\n");return NULL;} - *parena = arena; - ret = (char*)arena + sizeof(*arena); - arena->next = NULL; + arena->next = pool->first; + pool->first = arena; arena->current = (char*)ret + len; return ret; }

April 30, 2007