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

Re: dbghelp: Directly use Heap functions.

by Frank Richter

On 30.04.2007 08:56, Eric Pouech wrote: > Markus Amsler a écrit : >> This reduces WoW debug symbol load time from about 100s to 18! > this also removes two key design features: > - memory is free:d (as Dimitry already pointed out) > - a memory pool is associated to every module, so that all allocations > for a specific module are free:d when the module is unloaded If using the Heap* functions gives such a significant speed boost it may make sense to create a heap with HeapCreate() per module and use that. When a module is unloaded you can just call HeapDestroy() to get rid of the memory allocated for that module. -f.r.

April 30, 2007

Re: dbghelp: Directly use Heap functions.

by Eric Pouech

Markus Amsler a écrit : > This reduces WoW debug symbol load time from about 100s to 18! this also removes two key design features: - memory is free:d (as Dimitry already pointed out) - a memory pool is associated to every module, so that all allocations for a specific module are free:d when the module is unloaded 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 all, > We have managed to integrate our winscard source code into the wine source tree, including the configure.ac and Makefine.in files. > As described in the developer's guide, I am attaching with this email the output of the command "git format-patch origin". > Can someone please check if I have done it the right way? If this is ok, should I post it also to the patches mailing list. > For your information, our implementation uses pcsc-lite through wine_dlopen and wine_dlsym, so pcsc-lite is not required at compile time. > We have not included test files as they include the use of smart cards with proprietary applications. > I will try in the near future to include a wine implementation of a graphical tool that can manipulate smart cards using the wine winscard dll. > Thanks for your help. > Cheers, > > Mounir IDRASSI > IDRIX - Cryptography and IT Security Experts > http://www.idrix.fr > > > 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+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 30, 2007

AW: wine killing X?

by Roland Kaeser

Hello I saw the same problem starting SimCity 4 and Railroad Tycoon on Nvidia drivers and 0.9.36. But only sometimes. Roland ----- Ursprüngliche Mail ---- Von: Juan Lang <juan_lang(a)yahoo.com> An: wine-devel(a)winehq.org Gesendet: Freitag, den 27. April 2007, 21:58:37 Uhr Betreff: wine killing X? I just upgraded to the latest wine version and tried wineprefixcreate (no .wine directory), and it kills X. Nvidia drivers 1.0.9755. Anyone else see this? --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __________________________________ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever

April 30, 2007

Re: Winscard support (for smart cards)

by Kai Blin

On Monday 30 April 2007 00:58, Mounir IDRASSI wrote: > Hi all, > We have managed to integrate our winscard source code into the wine source > tree, including the configure.ac and Makefine.in files. As described in the > developer's guide, I am attaching with this email the output of the command > "git format-patch origin". Can someone please check if I have done it the > right way? I have to admit that somewhere around line 500 of the patch I gave up. Please split this patch into smaller, easier to read chunks. That will make getting it accepted much easier. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton.

April 30, 2007

Re: Extensive ScrollDC investigation

by Aric Stewart

I do a scanf() inside of DRAW_CHECK so that you can look at the scroll results and hit enter in the console to go on. If that is not good I can change or even remove the DRAW_CHECK but when i was comparing the results it was handy to be able to have the test pause. -aric Dmitry Timoshkov wrote: > "Aric Stewart" <aric(a)codeweavers.com> wrote: > >> Reworking some parts of ScrollDC to properly mask and scroll the >> right areas of the DC as well as generate the correct update regions. >> Extensive testing used to verify the behavior. > > > This test hangs forever for me under XP displaying a listbox with > "ENTRY xx" > entries if winetest_debug != 0. Once I forcibly set winetest_debug = 0 > the > test never produces test statistics (failed, skipped). The whole idea of > playing with winetest_debug and DRAW_CHECK inside of the drawing test > looks > broken to me. >

April 30, 2007

Re: dbghelp: Directly use Heap functions.

by Markus Amsler

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

April 30, 2007

Re: dbghelp: Directly use Heap functions.

by Dmitry Timoshkov

"Markus Amsler" <markus.amsler(a)oribi.org> wrote: > void pool_destroy(struct pool* pool) > { > - struct pool_arena* arena; > - struct pool_arena* next; > - > -#ifdef USE_STATS > - unsigned alloc, used, num; > - > - for (alloc = used = num = 0, arena = pool->first; arena; arena = arena->next) > - { > - alloc += pool->arena_size; > - used += arena->current - (char*)arena; > - num++; > - } > - FIXME("STATS: pool %p has allocated %u kbytes, used %u kbytes in %u arenas,\n" > - "\t\t\t\tnon-allocation ratio: %.2f%%\n", > - pool, alloc >> 10, used >> 10, num, 100.0 - (float)used / (float)alloc * 100.0); > -#endif > - > - for (arena = pool->first; arena; arena = next) > - { > - next = arena->next; > - HeapFree(GetProcessHeap(), 0, arena); > - } > - pool_init(pool, 0); > + return; > } The old code at least bothered to actually free some memory. -- Dmitry.

April 30, 2007

Re: Extensive ScrollDC investigation

by Dmitry Timoshkov

"Aric Stewart" <aric(a)codeweavers.com> wrote: > Reworking some parts of ScrollDC to properly mask and scroll the right > areas of the DC as well as generate the correct update regions. > Extensive testing used to verify the behavior. This test hangs forever for me under XP displaying a listbox with "ENTRY xx" entries if winetest_debug != 0. Once I forcibly set winetest_debug = 0 the test never produces test statistics (failed, skipped). The whole idea of playing with winetest_debug and DRAW_CHECK inside of the drawing test looks broken to me. -- Dmitry.

April 30, 2007

Re: Compiling quartzdrv

by Francois Gouget

On Tue, 17 Apr 2007, Jaka Janar wrote: > I've looked into this a bit further, and it appears gdi.h is now wingdi.h. Actually gdi.h was a Wine-only header and as such it has been removed quite a long time ago. So the best would be to see if it compiles without that include at all. > I've changed the includes, but there are other problems. As far as I can > tell the wineserver display protocol has changed a little, and only > x11drv has been corrected correspondingly. Yeas, that possible. If you manage to fix those issues, then don forget to upload your fixes somewhere and post the URL on this mailing list so others can benefit. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

April 29, 2007