February 2013 - Wine-Devel - list.winehq.org

Re: A new demangler test?

by Eric Pouech

Le 24/02/2013 07:07, Max TenEyck Woodbury a écrit : > On 02/23/2013 02:54 AM, Eric Pouech wrote: >> Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : >>> Would it be appropriate to add a test to the name demangler that: >>> >>> 1) Scans all '.dll' and '.spec' files for mangled names, and >>> >>> 2) Tries to decode those names. >>> >>> 3) Prints the mangled and decoded names and where they occur. >>> >>> Success would be that all names decode without the decoder blowing up >>> or failing. >>> >>> >>> >> adding tests for demangler is good >> but you just need to have a set of mangled/unmangled strings for the >> test >> as core demangler in msvcrt, test should be added here... >> (but grabbing the mangled strings shall be left out of the test itself) >> A+ >> > One of the important aspects of name demangling is that it should work > on _all_ the names in the current system. The current test does > demangle a list of known strings, but that list was incomplete with > respect to all the features used in real names the last time I dug into > the details (which was none too recently). > > Scanning for all the real mangled names not only makes sure that the > demangler is working properly, it also assures that all the names used > are properly formed and decode to their intended values. > > > I'm just saying that the test shouldn't embed the way to grab the mangled names it should be made outside of the test A+

Feb. 24, 2013

Re: A new demangler test?

by Max TenEyck Woodbury

On 02/23/2013 02:54 AM, Eric Pouech wrote: > Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : >> Would it be appropriate to add a test to the name demangler that: >> >> 1) Scans all '.dll' and '.spec' files for mangled names, and >> >> 2) Tries to decode those names. >> >> 3) Prints the mangled and decoded names and where they occur. >> >> Success would be that all names decode without the decoder blowing up >> or failing. >> >> >> > adding tests for demangler is good > but you just need to have a set of mangled/unmangled strings for the test > as core demangler in msvcrt, test should be added here... > (but grabbing the mangled strings shall be left out of the test itself) > A+ > One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently). Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values.

Feb. 24, 2013

Re: [0/13] Patch series description

by Saulius Krasuckas

* On Sat, 23 Feb 2013, André Hentschel wrote: > Am 22.02.2013 15:09, schrieb Saulius Krasuckas: > > * On Thu, 21 Feb 2013, André Hentschel wrote: > > > >> So where do we go from here? > > > > Right to the binary translation (or even dynamic recompilation), I > > guess. > > I won't do that, and i guess there's not much interest out there for > someone else to do it, so have fun :) OK, I understand this. And by main part it probably belongs to different project (qemu-user, I guess). S.

Feb. 23, 2013

Re: Why complain about X1R5G5B5?

by Henri Verbeet

On 23 February 2013 17:20, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Personally, I suspect the test is just overly restrictive. Also, just to clarify something, initially on IRC I was under the impression the driver *only* exposed X1R5G5B5, i.e. instead of X8R8G8B8, while clearly supporting 32 bpp display modes. That would be much more suspicious than just exposing X1R5G5B5 instead of the more common R5G6B5.

Feb. 23, 2013

Re: Why complain about X1R5G5B5?

by Henri Verbeet

On 23 February 2013 16:42, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > There are also potential issues because X1R5G5B5 is a 16 bit format, just like R5G6B5, which makes depth<->format mapping tricky. If the current setup uses a color depth of 16 bits and the app does not request a specific adapter format, which one does the driver choose? > I don't think applications can actually do that. (Although if you mean backbuffer format instead of adapter format there, that would just be whatever format it's currently using.) Personally, I suspect the test is just overly restrictive. Yes, there have been a couple of cases where applications break if you expose e.g. certain texture formats, but I don't think it necessarily makes sense to write tests like that until you actually find an application that breaks because of it. That doesn't mean it isn't a pretty uncommon format and something the QXL people may want to look into, but I don't think we want the tests to fail because of it. CheckDeviceType() probably just fails for every format combination because the driver can't do 3D.

Feb. 23, 2013

Re: Why complain about X1R5G5B5?

by Stefan Dösinger

Am 21.02.2013 um 17:24 schrieb Francois Gouget <fgouget(a)codeweavers.com>: > In essence our tests say that the driver must not support X1R5G5B5. Why? I think the tests were written this way because we did not find any driver that exposed this format, and we had a lot of cases in other areas where exposing additional features broke games. There are also potential issues because X1R5G5B5 is a 16 bit format, just like R5G6B5, which makes depth<->format mapping tricky. If the current setup uses a color depth of 16 bits and the app does not request a specific adapter format, which one does the driver choose?

Feb. 23, 2013

Re: [0/13] Patch series description

by André Hentschel

Am 22.02.2013 15:09, schrieb Saulius Krasuckas: > * On Thu, 21 Feb 2013, André Hentschel wrote: >> Am 21.02.2013 21:31, schrieb Saulius Krasuckas: >>> >>> because I've got new(er) Sparc machine. >> >> You know that you most likely won't ever be able to run x86 apps on that >> machine, only winelib. Do you need that for something? > > Yes, I am aware of endianess issue found by Darwine people when > integrating it with Qemu to run x86/PE binaries on PowerPC: > http://wiki.winehq.org/MacOSX > > It is said byteswapping isn't worth trouble but if Rosetta did it (only in > reverse direction) isn't this issue only about developers work time and > not about performance? > > Then it seems Sparc V9 can switch to little endian to access data. > >> So where do we go from here? > > Right to the binary translation (or even dynamic recompilation), I guess. > > S. > I won't do that, and i guess there's not much interest out there for someone else to do it, so have fun :) -- Best Regards, André Hentschel

Feb. 23, 2013

Re: A new demangler test?

by Eric Pouech

Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : > Would it be appropriate to add a test to the name demangler that: > > 1) Scans all '.dll' and '.spac' files for mangled names, and > > 2) Tries to decode those names. > > 3) Prints the mangled and decoded names and where they occur. > > Success would be that all names decode without the decoder blowing up > or failing. > > > adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+

Feb. 23, 2013

Re: gdiplus: Remove debug traces from GdipBitmapGetPixel and GdipBitmapSetPixel.

by Vincent Povirk

> alpha_blend_bmp_pixels() calls them while copying bitmap bits with an > alpha channel. This makes debug logs huge, hard to analyze, and completely > unmanagable in size. GDI+ should be fixed so it doesn't call these functions internally. It's just not an efficient way to render to bitmaps.

Feb. 22, 2013

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.

by Akihiro Sagawa

On Fri, 22 Feb 2013 11:21:20 +0900, Byeongsik Jeon wrote: > This patch fix a original topic of the wine-bugs #16325. Thanks for your work on this. > +static DWORD get_associated_charset_info(void) > +{ > + static DWORD associated_charset = -1; > + > + if (associated_charset == -1) > + { > + const char *assoc_charset_reg_key = > + "System\\CurrentControlSet\\Control\\FontAssoc\\Associated Charset"; Please use WCHARs and W version of APIs in gdi32/font.c, like: const WCHAR yesW[] = { 'Y', 'E', 'S', 0 }; and so on. > @@ -3615,6 +3615,33 @@ static void update_font_info(void) > } > if (!done) > FIXME("there is no font defaults for codepages %u,%u\n", ansi_cp, oem_cp); > + > + if (RegCreateKeyA( HKEY_LOCAL_MACHINE, > + "System\\CurrentControlSet\\Control\\FontAssoc\\Associated Charset", As far as I know, in SBCS locale, this key doesn't exist. Therefore it should delete in SBCS locale initialization and create the key in DBCS locale initialization. Regards, Akihiro Sagawa

Feb. 22, 2013

newtestbot timings

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I've looked at some of newtestbot timing results. http://newtestbot.winehq.org/JobDetails.pl?Key=256 It's not too bad, but it's not superb either. >render.c:633: event after Stop.4 average 40.000ms deviation 0.06 from 100 samples That's exactly the expected 40ms, great! >render.c:618: Test failed: Wait iteration 40 gave 102 >render.c:633: event after Stop.1 average 10.925ms deviation 0.36 from 40 samples That's funny. I recently discovered that the Vista-w7 machines downgrade their event rate from 10 to 40.0ms exactly 2 seconds following IAC_Stop. Newtestbot's w8 results indicate that w8 continues sending 10ms events for 400ms after IAC_Stop, then ceases. Current wine*.drv immediately stop sending events after IAC_Stop, so Wine almost implemented w8 behaviour before it existed :-) >render.c:189: Returned periods: 10.1587 ms 3.0000 ms >render.c:633: event after Start.2 average 10.955ms deviation 0.16 from 100 samples >render.c:2200: Released 44800=100x448 -448 frames at 44100 worth 1006ms in 1087ms >render.c:2206: event average 10.878ms deviation 0.16 from 100 samples So the machines do not manage to deliver the expected 10.1587ms period. Well, 10.9 is not that far away. By comparison, a native box meets the average: < event after Start.4 average 10.159ms deviation 0.01 from 100 samples < Released 44800=100x448 -896 frames at 44100 worth 996ms in 1018ms < event average 10.161ms deviation 0.03 from 100 samples The exclusive mode test shows some degradation: >render.c:928: Testing exclusive mode at 44100 >render.c:948: Latency: 15.0113 ms >render.c:967: BufferSize 22528 estimated fragment 662 x 33 = 21846 >render.c:991: Clock Frequency 44100 >render.c:1060: Test failed: Position 5696 too far after stop 100ms -- 129ms 30% off, quite a lot. >render.c:1070: padding 0 past sleep #2 >render.c:1089: padding 0 position 22528 past stop #2 This is worrying. Padding 0 means that within 200ms, the driver emptied its whole half second buffer. That's not physical. Do you have PulseAudio running on the UNIX VM host? It's known from winealsa to eat lots of samples when starting up. By contrast, a native box yields: < padding 13308 past sleep #2 < padding 13251 position 9277 past stop #2 -- 210ms >render.c:1148: position 6208 past 100ms sleep #3 -- 141ms >render.c:1152: Test failed: Position 6208 too far after playing 100ms >render.c:1168: padding 16256 position 6272 past stop #3 -- 142ms >render.c:1173: Test failed: Position 6272 too far after stop 100ms Again, a native box yields values fully in range: < position 4757 past 100ms sleep #3 -- 108ms < padding 17706 position 4822 past stop #3 -- 109ms Interestingly, only exclusive mode is affected by huge deviations, upto 50%. Regarding shared mode, oddly w8 machines exhibit some failures. They are quite small (I think we should raise the margins to fit): render.c:1060: Test failed: Position 39424 too far after stop 100ms -- 111ms render.c:1060: Test failed: Position 43008 too far after stop 100ms -- 121ms render.c:1094: Test failed: Position 78848 too far after playing 200ms --223ms One machine stalled for 44 seconds: >render.c:633: event after Stop.2 average 444.809ms deviation 4294.73 from 100 samples That would have caused a test failure if it had happened at another location within the tests. Regards, Jörg Höhle

Feb. 22, 2013

Re: [0/13] Patch series description

by Saulius Krasuckas

* On Thu, 21 Feb 2013, André Hentschel wrote: > Am 21.02.2013 21:31, schrieb Saulius Krasuckas: > > > > because I've got new(er) Sparc machine. > > You know that you most likely won't ever be able to run x86 apps on that > machine, only winelib. Do you need that for something? Yes, I am aware of endianess issue found by Darwine people when integrating it with Qemu to run x86/PE binaries on PowerPC: http://wiki.winehq.org/MacOSX It is said byteswapping isn't worth trouble but if Rosetta did it (only in reverse direction) isn't this issue only about developers work time and not about performance? Then it seems Sparc V9 can switch to little endian to access data. > So where do we go from here? Right to the binary translation (or even dynamic recompilation), I guess. S.

Feb. 22, 2013

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Johannes Kroll wrote: >I don't understand what you mean by "decompose LongMsg into snippets". >Is it possible that either >A) the app expects the API code to scan the buffer for a trailing 0xf7 >end marker and send only the bytes up to that marker; or >B) that the mysterious "dwBytesRecorded" should really contain the >bytes to be sent, and that it should be set by a function calling >LongMsg (i. e. somewhere else in Wine)? We have no evidence that dwBytesRecorded shall be used. Neither A nor B. I'll explain. Net.wisdom has it that midiOutLongMsg can be used to play chords, e.g. send 2 note-on events: 91 K1 V1 92 K2 V2 If MIDI worked only over the serial port, there would be no complication: Simply send all those bytes over the serial port. Let the receiver handle them. The OSS interface works like this: just dump bytes one by one. http://source.winehq.org/source/dlls/wineoss.drv/midi.c?v=wine-1.5.23#L1559 That's why I believe OSS would work fine as is with your app. The ALSA interface is much more complex. It expects markup - use snd_seq_ev_set_sysex() for a SysEx, - use snd_seq_ev_set_noteoff() for NOTE_OFF, - snd_seq_ev_set_noteon|keypress|controller|... http://source.winehq.org/source/dlls/winealsa.drv/midi.c?v=wine-1.5.23#L844 Therefore, winealsa needs to scan the buffer and decompose it into snippets, then call the matching snd_seq_ev_set_* function. So winealsa must call snd_seq_ev_set_noteon on each 91 K1 V1 snippet. In the case of your app it would call snd_seq_ev_set_sysex on the F0...F7 snippet, then ... well I don't know what to call on the remaining three 00 00 00 bytes. The "simply send bytes over the serial port" analogy would mean to not skip those bytes rather than find some means to send them via ALSA. Regards, Jörg Höhle

Feb. 22, 2013

Re: vbscript: Added support for a few more constants.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24500 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Feb. 22, 2013

Re: comctl32/treeview: Protect TVM_GETITEM from invalid item pointers

by Nikolay Sivov

On 2/22/2013 14:09, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> @@ -2101,9 +2102,17 @@ TREEVIEW_GetItemT(const TREEVIEW_INFO *infoPtr, LPTVITEMEXW tvItem, BOOL isW) >> { >> if (!item) return FALSE; >> >> - TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); >> - infoPtr = item->infoPtr; >> - if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; >> + __TRY >> + { >> + infoPtr = item->infoPtr; >> + TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); >> + if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; > You can't return from a try block. Ah, thanks. > > Also have you verified that this is not just masking some other Wine > bug? Honestly, I have not. I only looked at +treeview log attached to bug. Will try to figure out what's going on exactly.

Feb. 22, 2013

Re: server/advapi32: Report administrator ownership by default for registry objects (try 4).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > + else > + { > + struct object_type *type = obj->ops->get_type( obj ); > + static const WCHAR key_type[] = {'K','e','y'}; > + const WCHAR *type_name = NULL; > + data_size_t type_len = 0; > + > + if (!type) goto done; > + type_name = get_object_name( &type->obj, &type_len ); > + release_object( type ); > + if (memcmp(type_name, key_type, type_len) != 0) goto done; > + } You clearly need to spend more time studying how the server works. -- Alexandre Julliard julliard(a)winehq.org

Feb. 22, 2013

Re: comctl32/treeview: Protect TVM_GETITEM from invalid item pointers

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -2101,9 +2102,17 @@ TREEVIEW_GetItemT(const TREEVIEW_INFO *infoPtr, LPTVITEMEXW tvItem, BOOL isW) > { > if (!item) return FALSE; > > - TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); > - infoPtr = item->infoPtr; > - if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; > + __TRY > + { > + infoPtr = item->infoPtr; > + TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); > + if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; You can't return from a try block. Also have you verified that this is not just masking some other Wine bug? -- Alexandre Julliard julliard(a)winehq.org

Feb. 22, 2013

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.

by Qian Hong

On Fri, Feb 22, 2013 at 10:21 AM, Byeongsik Jeon <bsjeon(a)hanmail.net> wrote: > This patch fix a original topic of the wine-bugs #16325. Thanks for the great work! I've been waiting for this fix for a really long time :) Out basic Wine test VM does not include Chinese/Japanese Windows, so I submit Byeongsik's patch to the testbot again with Chinese/Japanese Windows included: https://testbot.winehq.org/JobDetails.pl?Key=24496 All tests related to this patch passed (Those failed tests are not related to this patch) I also manually test the patch on Windows with Korean locale and the test case passed as well. Hopes that helps :) -- Regards, Qian Hong - http://www.winehq.org

Feb. 22, 2013

Re: [0/13] Patch series description

by André Hentschel

Am 21.02.2013 21:31, schrieb Saulius Krasuckas: > * On Thu, 21 Feb 2013, André Hentschel wrote: > >> Really? :) I mean this was 2004, and it doesn't look like you took >> action on this. Did you read e.g. http://wiki.winehq.org/SPARC or >> http://bugs.winehq.org/show_bug.cgi?id=24142 in the meantime? > > Well, I didn't took actions but such intention is still present. Just > because I've got new(er) Sparc machine. > You know that you most likely won't ever be able to run x86 apps on that machine, only winelib. Do you need that for something? So where do we go from here? -- Best Regards, André Hentschel

Feb. 21, 2013

Re: [0/13] Patch series description

by Saulius Krasuckas

* On Thu, 21 Feb 2013, André Hentschel wrote: > Really? :) I mean this was 2004, and it doesn't look like you took > action on this. Did you read e.g. http://wiki.winehq.org/SPARC or > http://bugs.winehq.org/show_bug.cgi?id=24142 in the meantime? Well, I didn't took actions but such intention is still present. Just because I've got new(er) Sparc machine. I've been reading this wiki page from time to time but haven't been into the bugreport. Thanks for it:) S.

Feb. 21, 2013

Re: [12/13] winedump: Remove SPARC support

by André Hentschel

Am 21.02.2013 20:55, schrieb Eric Pouech: > Le 20/02/2013 21:11, André Hentschel a écrit : >> - case IMAGE_FILE_MACHINE_SPARC: return "SPARC"; >> >> > Actually this one should be kept, so that dumping such would print the relevant information. > A+ Thought about that for a second, too. But winedump only parses PE dlls, not the winelib ones and there are no SPARC PE dlls out there (Windows was never ported to it). -- Best Regards, André Hentschel

Feb. 21, 2013

Re: [0/13] Patch series description

by André Hentschel

Am 21.02.2013 07:16, schrieb Saulius Krasuckas: > * On Wed, 20 Feb 2013, André Hentschel wrote: > >> this patch series removes the broken SPARC support. >> Reasons: >> * It's broken, i wasted enough time already trying to fix that > > It's sad to hear. Can you be more verbose on brokenness, please? > Eg. namely what Sparc platform were you using for development? Not sure anymore, Austin English was so kind to provide a machine with ssh access for me. >> * Nobody cares - I sent an e-mail to everyone ever related to >> Wine/SPARC based on addresses from our mailing lists - no answer in a >> week (and cw also has no customers for it) > > You didn't catch this then: > http://www.winehq.org/pipermail/wine-devel/2004-October/030355.html > I care :) Really? :) I mean this was 2004, and it doesn't look like you took action on this. Did you read e.g. http://wiki.winehq.org/SPARC or http://bugs.winehq.org/show_bug.cgi?id=24142 in the meantime? Oh and you asked about learning SPARC assembler... It's quite easy to learn and a clever architecture, but anyway: >> * If someone _would_ care the right thing to do would be a clean SPARC >> 64-bit port > > So, the old port was 32-bit or mixed or what? Yes, the old port was 32-bit only. >> * It really can confuse people (more than a ARM/ARM64 port xD) > > You mean random readers about host platforms Wine runs on;)? OK, not the best point, i agree :) I think i meant to talk about Wine/SPARC confuses people, so don't mention it anywhere ;) >> * SPARC is dead on the Desktop > > :( > >> And last but not least: I had a bad experience with the Solaris >> community regarding Wine/SPARC > > Oh. Is there any related public messages on the net? It would > interesting to read and know those stories. Mhh, that was on IRC, looks like there are no logs... -- Best Regards, André Hentschel

Feb. 21, 2013

Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

by Johannes Kroll

On Wed, 13 Feb 2013 19:18:42 +0100 <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Johannes Kroll wrote: > >It is in the log line that you deleted. > Oops. > > >No, I don't have wineOSS. Does it require a proper OSSv4? > Currently, yes. You'd have to try out wine-1.3.24 or older. > > I'll try and see how to use virtual MIDI devices to dump data > without using a serial port. > > Anyway, I'll start writing a patch that decomposes LongMsg > into snippets, although I don't know how to handle the three > 00 00 00 bytes. I don't understand what you mean by "decompose LongMsg into snippets". Is it possible that either A) the app expects the API code to scan the buffer for a trailing 0xf7 end marker and send only the bytes up to that marker; or B) that the mysterious "dwBytesRecorded" should really contain the bytes to be sent, and that it should be set by a function calling LongMsg (i. e. somewhere else in Wine)?

Feb. 21, 2013

Why complain about X1R5G5B5?

by Francois Gouget

If I run Wine's conformance tests in a QEmu VM using Spice's QXL driver I get the following errors: d3d8:device device.c:1004: Test failed: Unexpected display mode returned for mode 0: 0x18 d3d9:device device.c:1366: Test failed: EnumAdapterModes(D3DFMT_X1R5G5B5) did not return D3DERR_INVALIDCALL (got 00000000)! In essence our tests say that the driver must not support X1R5G5B5. Why? Further notes: * If I then call Direct3D9::CheckDeviceType() for this format I get NOTAVAILABLE which is inconsistent. But then that's exactly what Microsoft's Standard VGA driver does for the R5G6B5 and X8R8G8B8 formats. http://www.winehq.org/pipermail/wine-patches/2013-February/122388.html * See the exact list of formats returned by IDirect3D8::EnumAdapterModes() http://newtestbot.winehq.org/JobDetails.pl?Key=243&log_103=1#k103 Test executable and source: https://bugs.freedesktop.org/attachment.cgi?id=75248 * See the list of formats that IDirect3D8::EnumAdapterModes() claims are supported, and how CheckDeviceType() refuses them. http://newtestbot.winehq.org/JobDetails.pl?Key=249&log_103=1#k103 Test executable and source: https://bugs.freedesktop.org/attachment.cgi?id=75260 * I think it's important to get Spice's QXL driver and Wine's conformance tests to play nice together. First they are both open-source so if one is wrong we should work to resolve that. But also the new WineTestBot is uses QEmu and the QXL driver looks like it will be _the_ paravirtualized(*) graphics driver there. (*) I.e. high performance and most used driver. * See also QXL bug 61227: https://bugs.freedesktop.org/show_bug.cgi?id=61227 -- Francois Gouget <fgouget(a)codeweavers.com>

Feb. 21, 2013

A new demangler test?

by Max TenEyck Woodbury

Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spac' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing.

Feb. 21, 2013