June 2009 - Wine-Devel - list.winehq.org

Re: Simplify code in dlls/imm32/tests/imm32.c
by Paul Vriens June 20, 2009

June 20, 2009

Gerald Pfeifer wrote: > Not sure how to else handle this; possibly remove this whole subtest? > > Gerald > > ChangeLog: > Simplify code in dlls/imm32/tests/imm32.c (and avoid false warning). > > diff --git a/dlls/imm32/tests/imm32.c b/dlls/imm32/tests/imm32.c > index 1951242..3e35ac1 100644 > --- a/dlls/imm32/tests/imm32.c > +++ b/dlls/imm32/tests/imm32.c > @@ -210,7 +210,7 @@ static void test_ImmNotifyIME(void) { > > /* behavior differs between win9x and NT */ > ret = ImmGetCompositionString(imc, GCS_COMPSTR, resstr, sizeof(resstr)); > - ok(ret || !ret, "You'll never read this.\n"); > + ok(TRUE, "You'll never read this.\n"); > We could use broken() to make sure we follow the wanted behaviour for Wine. From the patch that changed that item it should be: ok(!ret || broken(ret), .....) If you look however at test.winehq.org it looks like hardly any box meets the proper requirements to run these tests at all. So I'd say: ok(!ret, "After being cancelled the composition string is empty.\n"); (Tested on my W2K3 and Vista boxes). -- Cheers, Paul.

1 0

Simplify code in dlls/imm32/tests/imm32.c
by Joris Huizer June 20, 2009

June 20, 2009

Hello Gerald Pfeifer, You did, /* behavior differs between win9x and NT */ ret = ImmGetCompositionString(imc, GCS_COMPSTR, resstr, sizeof(resstr)); - ok(ret || !ret, "You'll never read this.\n"); + ok(TRUE, "You'll never read this.\n"); Wouldn't it be better to do something like: ok(ret || broken(!ret), "You'll never read this.\n"); or marking the other case broken()? Note that broken() should be interpreted as, "unwanted functionality for Wine" HTH, Joris

1 0

Re: Alexandre Julliard : configure: Don't accept mingw32 as target name, we need an explicit CPU specification.
by Steven Edwards June 20, 2009

June 20, 2009

On Fri, Jun 19, 2009 at 9:27 AM, Alexandre Julliard<julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: ccbf959969e32c9d71d2b4c46dbfe4db1ad2ab3f > URL: http://source.winehq.org/git/wine.git/?a=commit;h=ccbf959969e32c9d71d2b4c46… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Thu Jun 18 21:35:51 2009 +0200 > > configure: Don't accept mingw32 as target name, we need an explicit CPU specification. I don't think this change is right. It is a very common convention to use mingw32 as a generic convention for 32bit x86. It seems the best practice would be if mingw32 is passed then to assume a sensible lowest common default. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

4 5

Re: winex11: Get rid of glext.h in remaining locations [try 2]
by James Mckenzie June 19, 2009

June 19, 2009

Austin English <austinenglish(a)gmail.com> wrote about Re: winex11: Get rid of glext.h in remaining locations [try 2] > >On Fri, Jun 19, 2009 at 9:02 AM, Detlef Riekenberg<wine.dev(a)web.de> wrote: >> Already removed from dlls/opengl/* by Roderick. >> winex11 on linux works without GL/glext.h (OSX untested) >> >> Now with configure.ac > >Works fine on OS X. Sorry I forgot to do this myself. > Thank you. I have not set up my build system, yet. James McKenzie

1 0

Re: winex11: Get rid of glext.h in remaining locations [try 2]
by Austin English June 19, 2009

June 19, 2009

On Fri, Jun 19, 2009 at 9:02 AM, Detlef Riekenberg<wine.dev(a)web.de> wrote: > Already removed from dlls/opengl/* by Roderick. > winex11 on linux works without GL/glext.h (OSX untested) > > Now with configure.ac Works fine on OS X. Sorry I forgot to do this myself. -- -Austin

1 0

Re: advpack: Implement ExtractFilesW [try 2]
by James Hawkins June 19, 2009

June 19, 2009

2009/6/11 Vladimir Pankratov <scriptkid(a)mail.ru>: > Hello all. > > Implemented ExtractFilesW > > Changed files: > advpack/files.c > + if (GetFileAttributesA(ExpandDir) == INVALID_FILE_ATTRIBUTES) + return HRESULT_FROM_WIN32(ERROR_PATH_NOT_FOUND); Why are you testing this in ExtractFilesA? Almost all of the logic should be passed on to ExtractFilesW so we don't duplicate code. + if (FileList != NULL) Please don't change the style of the file. if (FileList) is fine. + WideCharToMultiByte( CP_ACP, 0, FileList, -1, szFileList, sizeof(szFileList), NULL, NULL ); + szConvertedList = convert_file_list(szFileList, &dwFileCount); I'm not sure this is the way to go. You're converting A -> W -> A. This happens because cabinet.Extract is (as far as we know) ansi-only. In this case, I think it's ok to make ExtractFilesW call into ExtractFilesA, with an appropriate comment as to why this is happening. -- James Hawkins

2 1

Looking for a fast way to clean up AppDB comments
by Florian Köberle June 19, 2009

June 19, 2009

Hi, I now became one of the application maintainers of Warcraft 3 The Frozen Throne and got asked to cleanup the comments. I started to do so, but there are just to much comments. I stopped deleting with 459 comments remaining. See: (http://appdb.winehq.org/objectManager.php?sClass=version&iId=3126) Is there a way to delete multiple comments at once? E.g. it would be cool if I could just check the comments to delete and hit then a button "delete selected comments" which opens the dialogue for the delete reason. Or some button "Delete all comments older then one year" would be quite useful. Best regards, Florian Köberle

4 4

NT4 passing
by André Hentschel June 19, 2009

June 19, 2009

WinNT4 is passing now for the first time since a long time(maybe since ever?). So special congratulations to Paul Vriens, who spent much time making the test-suite run on NT4. This is a great step for the test-suite. Now NT4, 2K, XP and 2K3 are passing partially. Keep it up!

4 6

Wine MIME handling
by Roderick Colenbrander June 18, 2009

June 18, 2009

Hi, For the past few days I have been looking at MIME handling in Wine. A program I'm using uses CreateProcess to launch a pdf file and I would like to use the default native pdf viewer. Initially I wrote a simple script which calls xdg-open to launch the file offered by Wine. (xdg-open "`wine winepath -u "$1"`") The script works properly and it could be used for all sorts of file formats. It would be useful to have a 'winemime' mechanism for this in Wine (either a script, program or shell32 code). The issue could be solved in different ways. For instance there is already some XDG MIME code in shell32 which could be extended, a winebrowser-like winelib program could be written or we could use a script. Personally I would favor either of the last two solutions. The main downside of a script is that as far as I know I need to set the whole linux path (e.g. /usr/local/bin/winemime) in the registry and this could be avoided if the tool was a winelib program as it would be in the wine path by default. Second I would like not to depend on the xds-open script on linux but have this code merged inside winemime. A winelib based winemime would be very similar to winebrowser, so if we would go the winelib way might it make sense to extend winebrowser for this? I hope to get some feedback and suggestions on how to proceed before I start writing code. Thanks, Roderick Colenbrander

2 3

Re: user32/tests: Added tests for DrawIcon and DrawIconEx (try 6)
by Joel Holdsworth June 18, 2009

June 18, 2009

> cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIcon. Expected 00003163 (modern), or 00003868 (legacy). Got 000020B8 from line 1109 > cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1110 > cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIcon. Expected 00003163 (modern), or 00003868 (legacy). Got 000020B8 from line 1112 > cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1113 > cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 00003163 (modern), or 00003868 (legacy). Got 000020B8 from line 1114 > cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1115 > cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIconEx flags 00000003. Expected 00003163 (modern) or 00003868 (legacy). Got 000020B8 from line 1256 > cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIconEx flags 00000003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1257 > cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIconEx flags 00000003. Expected 00003163 (modern) or 00003868 (legacy). Got 000020B8 from line 1259 > cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIconEx flags 00000003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1260 > cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIconEx flags 00000003. Expected 00003163 (modern) or 00003868 (legacy). Got 000020B8 from line 1261 > cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIconEx flags 00000003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1262 > I've tracked down the problems with an NT4 VM. The problem comes when screen depth is set to less than 32-bit. Even though I'm drawing from an icon made from 32-bit bitmaps, and making DrawIcon draw to a 32-bit DIB section, old versions of windows don't respect that, and will truncate the color data. In 16-bit only the top 5 bits of a color channels emerge ungarbled, and in 8-bit and less, the colors go via the palette (logical palette?), which knocks them completely off. The most obvious solution would be something like this as a color test: const int screen_bpp = GetDeviceCaps(hdc, BITSPIXEL); ok (result == modern_expected || /* Windows 2000 and up */ broken(result == legacy_expected) || /* Windows NT 4.0, 9X and below */ broken((result & 0x00F8F8F8) == (legacy_expected & 0x00F8F8F8) && screen_bpp == 16) || broken(result != legacy_expected && screen_bpp <= 8), How acceptable would that be?

2 3

Sugestion to Wine
by Sérgio R. da Silva June 18, 2009

June 18, 2009

Hello to all developers of wine. My name is Sergio R. da Silva, and I sent some suggestions to improve the wine. First of all I apologize for any errors in spelling, because I am Brazilian and I do not know very well and I write in English using Google Translator to send these suggestions and also send the wrong address, if possible please move to the correct department or send me an email where I send my suggestions. Here are my suggestions: 1) I suggest that in the file. Conf of wine is possible to configure other extensions without the DLL, such as OCX, EXE, CAB, etc.. or create a tab to add these extensions, this flap could be close to the tab "Libraries" and could be called "Extensions" which add extensions without which DLL that windows USA, such as. CAB,. ini (boot.ini). bat (autoexec.bat). msc (gpedit.msc). config,. sys ( pagefile.sys, etc.). This is my first suggestion will soon send more. PS: If you have any questions about my suggestion is just send me an email to sergiordasilva17(a)gmail.com

2 1

[Bug 18786] patch
by Guy Albertelli June 18, 2009

June 18, 2009

Hello Juan, Could you look at bug 18786 and my suggested patch to get MINITAB working again. It is a partial revert of one of your patches from 6/25/08 (see comment #7). I have verified that the associated tests (dlls/inetmib1/tests/main.c) exercise that code both pre and post revert. However the tests don't detect an error either way. I know nothing about this code. Thanks, Guy

2 2

Fate of PulseAudio in WINE
by Arthur Taylor June 18, 2009

June 18, 2009

Recent activity in http://bugs.winehq.org/show_bug.cgi?id=10495 has caused some issues. This is also a response to http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html First the background. WinePulse has been an attempt to write a winmm backend for pulseaudio for wine. Currently the primary audio system used by wine is through winmm.dll which sends messages to a backend which basically represents the MS waveOut and waveIn APIs. WaveOut works through wavehdrs, a single-linked list structure which contains a data field pointing at a buffer. Applications feed wavehdrs via waveOutWrite and receive a message when they have finished being played. wavehdrs can be formed into loops using flags. This is all simple enough except for how variable it is. Applications usually allocate a set size of wavehdrs and then use them circularly. Applications usually use when a wavehdr is returned for timing purposes rather than waveOutGetPosition. The number of wavehdrs and their sizes is entirely up to the application. There are two common problems with audio drivers implementing this system. The first is drivers which return a wavehdr as soon as it is written to output (waveesd.dr for example) as it will cause timing issues for applications when large batches of wavehdrs are returned at once. The second problem is when a windows application makes a smaller buffer of wavehdrs than the backend provides. In this case wavehdrs are not returned because they have not been played, and no more data can be written to fill the buffer because all the wavehdrs are waiting to be returned from the playback that is stalled. This can happen with alsa on top of plugins. If the buffered wavehdrs and playback buffer are very close in size sometimes the audio stutters by, oscillating to and from underrun and playback. Winepulse attempts to overcome these problems. It returns wavehdrs accurately and avoids stalls by modifying the pulseaudio server buffer size. In tests it works consistently. Most of the people I've had contact with have been positive toward development of such a backend. That said, the response from wine developers has been overwhelmingly negative. I can understand the desire for only clean and maintainable code to be considered for submissions. However, often it appears that the rejection is wholly philosophical rather than logical. Continual reports of problems are always contributed to silly users who are not using ALSA on top of direct hardware. I do not dislike either ALSA nor winealsa.drv, but I do reject this skepticism toward a world of Linux audio beyond SB-16 style "direct hardware." The arguments that PulseAudio adds latency or is not suitable for professional audio are not relevant to the issue of whether or not a pulseaudio backend for wine should be added. The _addition_ of said backend _enables_ audio in wine for those who _choose_ to use pulseaudio. I can't imagine stopping pulseaudio just so I can listen to music through foobar2000, as that would stop all my voice chats, notification sounds, and other native audio, etc. For those whom pulseaudio is not appropriate, the other backends would still exist and pulseaudio can either be disabled temporarily via pasuspender, not started or not installed. That said, latency in pulseaudio is managed and through the winepulse patch exposed to the windows application. The daemon is usually run with realtime priority and will use data buffers if the requesting application locks temporarily, allowing less worry with recording. The method of audio playback and capture through waveOut and waveIn are quite broken. Even if winealsa uses the "safe ALSA api subset" it means that the poor and varied behaviours are translated to poor and varied alsa calls (DSound HEL is an exception here.) The winepulse patch attempts to overcome these issues by buffering sanely while trying to keep applications happy in a _consistant_ way. It is true that currently whitespace is an issue with the patches in the bug report. I will work to resolve this. The file was (supposed to be) indented using 4 spaces as this was the convention in all the other audio backends. Frankly, calling the code a search and replace from ALSA to PULSE is insulting. If this is true then it is therefore true that winealsa was a search and replace from OSS to ALSA. Almost all the wine audio backends share a common ancestor. The latest patch does not contain comment out code. There has been no *useful assistance* from wine developers (re "No Fucking Way"). As for which parts of the code aren't wine-64 ready, could you please expand? A detailed, constructive response with a clear vision for where the future of audio in wine lies would be appreciated. Thanks -- Arthur Taylor art(a)ified.ca theycallhimart(a)gmail.com

12 15

[review] np2 fixup patch for ARB path
by Tobias Jakobi June 17, 2009

June 17, 2009

You can find the current patchset here: http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_arb/ Of course the GLSL patchset is needed as well: http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_glsl/ I hope both can finally go into master, so please take a look. Going to resend the GLSL part tomorrow if they don't make it in by then. Greets, Tobias

1 0

Re: [3/6] WineD3D: Handle SM 3.0 varyings in ARB
by Henri Verbeet June 17, 2009

June 17, 2009

2009/6/17 Stefan Dösinger <stefan(a)codeweavers.com>: > > +struct wine_rb_functions sig_tree_functions = > +{ > + sig_tree_alloc, > + sig_tree_realloc, > + sig_tree_free, > + sig_tree_compare > +}; Sorry for not mentioning this before, but you can just use wined3d_rb_alloc() etc. for that. wine_rb_init() can fail, although it should be rare enough that you might not care.

1 0

Re: [3/6] WineD3D: Handle SM 3.0 varyings in ARB
by Allan Tong June 17, 2009

June 17, 2009

On Wed, Jun 17, 2009 at 1:37 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(strcmp(rel_reg, "**aL_emul**") == 0) > + { > + DWORD idx = ctx->aL + reg->idx; > + if(idx < 10) Seems like this should be MAX_REG_INPUT instead of 10. > + { > + strcpy(register_name, ctx->ps_input[reg->idx]); Should this be "ctx->ps_input[idx]"? > + } > + else > + { > + ERR("Pixel shader input register out of bounds: %u\n", idx); > + sprintf(register_name, "out_of_bounds_%u", idx); > + } > + } - Allan

2 1

Re: [3/6] d3dx9: Implement ID3DXFont_GetDesc
by Roderick Colenbrander June 17, 2009

June 17, 2009

Hi Tony, + WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1, desc->FaceName, sizeof(desc->FaceName) / sizeof(CHAR), NULL, NULL); sizeof(desc->FaceName) / sizeof(CHAR) won't give you the length of the string (remember that sizeof is evaluated at compile time, so the value is a constant) Regards, Roderick

2 2

Re: [3/6] WineD3D: Handle SM 3.0 varyings in ARB
by Henri Verbeet June 17, 2009

June 17, 2009

> @@ -1465,9 +1471,14 @@ struct IWineD3DDeviceImpl > const struct fragment_pipeline *frag_pipe; > const struct blit_shader *blitter; > > + struct ps_signature *pshader_signatures; > + unsigned int num_pshader_signatures; > + unsigned int pshader_signatures_size; > + DWORD ps_sig_number; > + > unsigned int max_ffp_textures, max_ffp_texture_stages; > DWORD d3d_vshader_constantF, d3d_pshader_constantF; /* Advertised d3d caps, not GL ones */ > - DWORD vs_clipping; > + DWORD vs_clipping, need_ps_signatures; > > WORD view_ident : 1; /* true iff view matrix is identity */ > WORD untransformed : 1; > @@ -2730,6 +2741,7 @@ typedef struct IWineD3DPixelShaderImpl { > BOOL color0_mov; > DWORD color0_reg; > > + DWORD input_signature_idx; Please keep this private to the ARB backend. (I.e., store these in struct shader_arb_priv.) Also, it looks like you're trying to write a binary search tree. Would you like to use wine_rb_tree instead?

2 4

Re: [6/6] d3dx9: Add tests for basic ID3DXFont functions
by Roderick Colenbrander June 17, 2009

June 17, 2009

Hi Tony, + hr = D3DXCreateFontA(device, 12, 0, FW_DONTCARE, 0, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, "Arial", &font); A bunch of font tests all use Arial. On Windows this font is always around, what happens on Wine when this font isn't around? Perhaps the function fails on fonts which aren't around, so this could potentially result in a lot of test failures on Wine. Not sure what should be done if this is the case though (perhaps check at run time if the font is around or perhaps use a font which is always around as a fallback). Regards, Roderick

2 1

Re: [6/6] WineD3D: Emulate clipplanes in ARB if the NV extensions are not available
by Henri Verbeet June 17, 2009

June 17, 2009

2009/6/17 Stefan Dösinger <stefan(a)codeweavers.com>: > + //ERR("Using texcoord %u for clip\n", ps->clipplane_emulation); C99 features generally aren't allowed inside Wine code. > + if(!device->vs_clipping) > + { > + /* See if we can use fragment.texcoord[7] for clipplane emulation > + * > + * Don't do this if it is not supported, or fragment.texcoord[7] is used > + */ > + if(This->baseShader.reg_maps.shader_version.major < 3) > + { > + for(i = GL_LIMITS(texture_stages); i > 0; i--) > + { > + if(!This->baseShader.reg_maps.texcoord[i - 1]) > + { > + This->clipplane_emulation = i; > + break; > + } > + } > + } > + else > + { > + for(i = GL_LIMITS(texture_stages); i > 0; i--) > + { > + if(!This->baseShader.reg_maps.input_registers & (1 << (i - 1))) > + { > + This->clipplane_emulation = i; > + break; > + } > + } > + } > + } This is specific to ARB as well. > + char clipplane_emulation; Using a char for this is pretty useless. If you want to save memory or cachelines, use a bitfield. The compiler will just pad the structure for alignment, and if you add other elements below it you'll have a hole, like e.g. after vpos_uniform in the same structure.

2 2

Re: [4/6] d3dx9: Implement ID3DXFont_GetDC
by Stefan Dösinger June 17, 2009

June 17, 2009

Am Wednesday 17 June 2009 18:29:57 schrieb Tony Wasserka: > @@ -300,6 +301,12 @@ HRESULT WINAPI D3DXCreateFontIndirectW(LPDIRECT3DDEVICE9 device, CONST D3DXFONT_ > object->device=device; > object->desc=*desc; > > + object->hdc = CreateCompatibleDC(NULL); Device contexts are scarce resources, please avoid holding one all the time. Instead, create it in GetDC and destroy it in ReleaseDC. Besides this, after ReleaseDC the DC is supposed to be invalid - the only way to do this is to destroy it. (Yes, I know that's broken in wined3d too. Needs fixing there as well) You'll also have to attach the DC to the font bitmap, or whatever you have, to have it draw to the correct device. I think the current code means that the DC will draw to the screen directly, which is maybe not what you want. If the font has a d3d surface underneath, you should use d3dsurface9::GetDC

2 1

Re: [4/6] WineD3D: Don't run out of varyings because of clipplanes
by Henri Verbeet June 17, 2009

June 17, 2009

2009/6/17 Stefan Dösinger <stefan(a)codeweavers.com>: > If I have to choose between a compile failure or disabling some clipplanes > I'll throw the clipplanes under the bus. > > If the shader is using relative addressing, look at the highest directly > addressed constant register. We know that the constant array must be at least > highest_idx+1 elements large, otherwise the shader will fail for sure. If we > see this problem coming, only enable as many clipplanes as we can fit into the > hardware limit. > > Something similar should be done in GLSL, but GLSL can only support all > clipplanes or none at all. I don't think we want this for GLSL. ARB is your own responsibility, but personally I think compile errors are much nicer to debug than the kind of graphics glitches missing clipplanes will create.

2 1

Re: Request for Patchreview
by Juan Lang June 17, 2009

June 17, 2009

Hi Andre, > I fixed the strange problems in try8 ( > http://www.winehq.org/pipermail/wine-patches/2009-June/074340.html ) and it > still dont get commit. > can you please do a review for this try? (Just say it, if it gets disturbing > you.) This one looks fine to me. And don't worry, you're not disturbing me. --Juan

1 0

Re: [PATCH 2/2] wined3d: improved ATI Radeon HD 4xxx detection
by Stefan Dösinger June 17, 2009

June 17, 2009

The patches seem ok to me, although I'd probably merge them into one patch(there's no point in adding unused defines)

3 2

Re: oleaut32/tests: Add some tests for [lcid] parameters.
by Paul Vriens June 17, 2009

June 17, 2009

Huw Davies wrote: > --- > dlls/oleaut32/tests/tmarshal.c | 53 +++++++++++++++++++++++++++++++- > dlls/oleaut32/tests/tmarshal.idl | 6 +++ > dlls/oleaut32/tests/tmarshal_dispids.h | 1 + > 3 files changed, 59 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > In an effort to get a green NT4, I ran your new tests on NT4: tmarshal.c:1376: Test failed: ITypeInfo_Invoke failed with error 0x80010105 tmarshal.c:1377: Test failed: got 0 tmarshal.c:1378: Test failed: got 0 On W2K3: tmarshal.c:1376: Test failed: ITypeInfo_Invoke failed with error 0x80010105 tmarshal.c:1377: Test failed: got 0 tmarshal.c:1378: Test failed: got 0 and a maybe unrelated on W2K3 (wasn't here before): tmarshal.c:605: Test failed: Struct parameter passed by pointer corrupted On W98: tmarshal.c:1376: Test failed: ITypeInfo_Invoke failed with error 0x80010105 tmarshal.c:1377: Test failed: got 0 tmarshal.c:1378: Test failed: got 0 Am I doing something wrong here? -- Cheers, Paul.

2 3