Does testbot's MingW miscompile winmm:midi tests?
Hi, on test.winehq, WinME systems always report 8 rc=MMSYSERR_INVALPARAM errors. However, when running a MSVC compiled binary (as found in testbot job #4990), no such error occurs. Paul Vriens wrote: I only see those 8 errors with the winetest executable from test.winehq.org. My own cross-compiled version is fine, no errors there. Likewise, Octavian Voicu's machines saw no failure with the MSVC binary, but constantly produce red color on testbot. This could - Either be a bug in testbot's MingW (compilation or includes)? What's the difference between testbot compilation and Paul Vriens'? - Some weird memory corruption affecting only WinME? - a bug in my tests? Those INVALPARAM errors happen since May. However my May-19 patch did not change the tests that since fail, so it must be a side effect of something else. 1. dwBytesRecorded is left uninitialised, which may produce random results -- if it were used. 2. dwOffset is now set to 0xDEADBEEF; previously uninitialised. Yet that does not explain why MSVC's and Paul's cross compiled binary succeed. Paul and I found a bug in the mingw includes once. Perhaps that's another instance? How to proceed from here? Jörg Höhle
Re: Does testbot's MingW miscompile winmm:midi tests?
On 09/06/2010 11:02 AM, joerg-cyril.hoe...@t-systems.com wrote: Hi, on test.winehq, WinME systems always report 8 rc=MMSYSERR_INVALPARAM errors. However, when running a MSVC compiled binary (as found in testbot job #4990), no such error occurs. Paul Vriens wrote: I only see those 8 errors with the winetest executable from test.winehq.org. My own cross-compiled version is fine, no errors there. For the record. I'm talking about the crosscompiled winetest executable from test.winehq.org and not something from the testbot. One can extract the single test from the winetest executable and that is what I did in this case. I've seen differences between winetest executable and my local crosscompiled tests in the past but never found a cause (or solution). Likewise, Octavian Voicu's machines saw no failure with the MSVC binary, but constantly produce red color on testbot. When you say red color on testbot you mean 'red' on test.winehq.org? -- Cheers, Paul.
Does testbot's MingW miscompile winmm:midi tests?
Hi, please excuse the numerous errors in my last message: Likewise, Octavian Voicu's machines saw no failure with the MSVC It's actually Saulius Krasuckas' machines. binary, but constantly produce red color on testbot. When you say red color on testbot you mean 'red' on test.winehq.org? Yes, indeed. I also got the subject wrong. Does test.winehq's MingW miscompile winmm:midi tests? Jörg Höhle
Re: wined3d: separate driver info from GPU info (try4)
On 6 September 2010 00:45, Roderick Colenbrander thunderbir...@gmail.com wrote: -driver_info-version_low = MAKEDWORD_VERSION(8, 6); /* Nvidia RIVA TNT, arbitrary */ + } You messed up the indentation here, but otherwise I think this looks reasonable.
Re: setupx.dll16: Handle the error case for VCPM_VSTATWRITE in vcpUICallbackProc16. (RESEND)
Gerald Pfeifer ger...@pfeifer.com writes: Just realized I did not see a response to this patch. Based on feedback I received for a different patch, I looked at this patch again and believe it indeed is easier. 1. We only set, but never used cbres, so removing it loses nothing. 2. With this patch we now set the return value to VCPN_FAIL in this case. However, this is not the only case in vcpUICallbackProc16; for example, in another case in this function we pass the return value of VCP_UI_CopyStart and that returns VCPN_FAIL all over the place. That doesn't mean it's appropriate in this case. Unless there is evidence that a zero return from VCPM_DISKPREPINFO is supposed to cause an error, it's better not to change the current behavior. -- Alexandre Julliard julli...@winehq.org
Re: oleaut32: Handle TKIND_COCLASS subtype for VT_PTR/VT_USERDEFINED.
+ // Use IID of the coclass' default interface Don't use C++ comments. On Mon, Sep 6, 2010 at 10:31 AM, Jan Ohlsen jan.t.ohl...@gmail.com wrote: --- dlls/oleaut32/tmarshal.c | 69 ++ 1 files changed, 69 insertions(+), 0 deletions(-)
msvcrt unimplemented function calls
I see calls to the following two functions just prior to a crash when testing wine64. Any idea what these are? wine: Call from 0x7b8497d9 to unimplemented function msvcp80.dll.??0?$comp...@n@std@@q...@aebn0@Z, aborting wine: Call from 0x7f7b04cf40d9 to unimplemented function MSVCR80.dll.__C_specific_handler, aborting err:seh:setup_exception stack overflow 2432 bytes in thread 0009 eip 7f7b04d32341 esp 7f7b03b10c80 stack 0x7f7b03b1-0x7f7b03b11000-0x7f7b03c1 Segmentation fault Thanks.
Re: [PATCH] winealsa.drv: Count micelem in mixer chans, don't add spare capture input for half-duplex mics.
Den 2010-09-05 11:45 skrev David Laight: On Wed, Sep 01, 2010 at 05:40:35PM +0200, Alexandre Julliard wrote: Jeff Cook j...@deserettechnology.com writes: @@ -520,7 +520,12 @@ static void ALSA_MixerInit(void) } /* Add master channel, uncounted channels and an extra for capture */ -mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + 1; +/* Do not add the extra channel needed for capture on half-duplex capture cards + like snd_usb_audio mics */ +if (micelem !mastelem !captelem) +mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + !!micelem; +else +mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + !!micelem + 1; This statement wasn't exactly clear before, but now it's really impossible to follow. Please rewrite this in a way that makes sense to a casual reader. Clearly it should be: mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + (micelem !mastelem !captelem); ducks quickly ... :-) Clearly not, since it is harder to debug code than to write it, and you failed to write it correctly in the first place (assuming the patch was indeed correct). Good thing you ducked... :-) Cheers, Peter
Re: Console issues in recent git
Hi,
after the console patch series, it appears a couple of problems are left
over:
to summarize, the problems with their status:
A/ when a program is running, no echo is seen for characters being typed.
B/ after running a wine program, the console is a bad shape and needs
'reset' to get back in a sane state.
Status
A/ IMO, it's barely a bug as you can't make an hypothesis about what a
program will do with character input. However, it's a change from
previous behavior as one could see the echo. This only happens when the
running program doesn't read its input. However, since now wine runs in
raw console mode, it's likely the typed characters will not be useful to
the shell when the program exits (as the shell will run in cooked mode
and will start with an empty buffer). Low priority for a fix (if any)
B/ actually, it's likely a race (in the simple way of running one single
program) about resetting the console in decent shape. Could the folks
having the issue try the attached patch (file conclean) to see if it
helps ? (I never could reproduce it here, tested with konsole xterm.
If you still see the issue, please detail console and shell program)
Clearly an annoying impact for most users, need fixing.
Actually, there's another issue with the same symptoms:
1- program A is launched from shell
2- program A starts another program B (for example winedbg when a fault
occurs)
3- at this point, both A B can read/write to the console
4- program A exits. As it way the group leader, B is set into the
background and loses (read) access to the console.
5- When B exits, as it no longer has access to the console, the state of
the console cannot be reset to normal
this was happening before the patch series, but as we didn't tweak the
console, it was just fine (except that some program dies when in the
background, eg winedbg)
fix will not be 100% easy
among the potential fixes:
S1: no longer do the console attribute management in server, but only in
kernel32, and only for the livespan of the process creating the bare
console. this means that the console will not be accessible to the
children of this process after its death (but I don't see how to do it
anyway)
S2: when the process that created the bare console, it's about to
terminate it should wait for all its children to die. This would require
a cloak of invisibility (from the win32 space) to let the other
win32-process see that it actually died.
S3: combine S1 and S2
comments welcome
also, I may have forgotten (or misunderstood) some issue reports. Don't
hesitate to jump in.
NB: I also have a patchset ready that shall enable key/arrows support in
bare console mode (with history bells whistles... handy for any
program with a CLI)
A+
--
Eric Pouech
The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot. (Douglas Adams)
diff --git a/server/console.c b/server/console.c
index 2ca6bd4..ea262fd 100644
--- a/server/console.c
+++ b/server/console.c
@@ -481,6 +481,17 @@ int free_console( struct process *process )
return 1;
}
+void close_console( struct process* process)
+{
+struct console_input* console = process-console;
+
+if (console console_input_is_bare(console) --console-num_proc == 0)
+{
+process-console = NULL;
+release_object(console);
+}
+}
+
/* let process inherit the console from parent... this handle two cases :
* 1/ generic console inheritance
* 2/ parent is a renderer which launches process, and process should
attach to the console
diff --git a/server/process.c b/server/process.c
index a3aa586..10f4bd7 100644
--- a/server/process.c
+++ b/server/process.c
@@ -566,6 +566,7 @@ static void terminate_process( struct process *process,
struct thread *skip, int
struct thread *thread;
grab_object( process ); /* make sure it doesn't get freed when threads
die */
+close_bare_console( process );
restart:
LIST_FOR_EACH_ENTRY( thread, process-thread_list, struct thread,
proc_entry )
{
diff --git a/server/process.h b/server/process.h
index cee7be9..e8546e6 100644
--- a/server/process.h
+++ b/server/process.h
@@ -126,6 +126,7 @@ extern void enum_processes( int (*cb)(struct process*,
void*), void *user);
/* console functions */
extern void inherit_console(struct thread *parent_thread, struct process
*process, obj_handle_t hconin);
extern int free_console( struct process *process );
+extern int close_bare_console( struct process *process );
extern struct thread *console_get_renderer( struct console_input *console );
/* process tracing mechanism to use */
Re: [PATCH 2/2] shlwapi: Improved UrlEscapeW implementation (try2)
On 09/05/10 22:29, (Marvin) wrote: 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=5040 Your paranoid android. === W98SE (32 bit url) === url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x url 'c:dir\file' Expected file:///c:dir/file, but got file:///c:/dir/file, index 42 This patches are not introducing new test failures.
Re: [PATCH 2/2] include: Define C++ operators inside extern C++ blocks.
d3c4106d6f6d587ec4b9013692dc1cf6da29c279 still doesn't fix the initial problem (see log below). There is still another problem in shlobj.h caused by the inclusion on shobjidl.h from an extern C block: http://source.winehq.org/git/wine.git/?a=blob;f=include/shlobj.h;h=cda13060195f1c4104ee226f4132155a354d46de;hb=HEAD#l39 Should I send a patch to move the three includes before extern C? How to reproduce the problem: $ cat test.cpp #include shlobj.h $ wineg++ test.cpp In file included from /usr/local/include/wine/windows/propsys.h:164, from /usr/local/include/wine/windows/shobjidl.h:368, from /usr/local/include/wine/windows/shlobj.h:39, from test.cpp:1: /usr/local/include/wine/windows/propkeydef.h: In function ‘bool operator==(const PROPERTYKEY, const PROPERTYKEY)’: /usr/local/include/wine/windows/propkeydef.h:61: error: declaration of C function ‘bool operator==(const PROPERTYKEY, const PROPERTYKEY)’ conflicts with /usr/local/include/wine/windows/guiddef.h:110: error: previous declaration ‘bool operator==(const GUID, const GUID)’ here /usr/local/include/wine/windows/propkeydef.h: In function ‘bool operator!=(const PROPERTYKEY, const PROPERTYKEY)’: /usr/local/include/wine/windows/propkeydef.h:65: error: declaration of C function ‘bool operator!=(const PROPERTYKEY, const PROPERTYKEY)’ conflicts with /usr/local/include/wine/windows/guiddef.h:114: error: previous declaration ‘bool operator!=(const GUID, const GUID)’ here winegcc: g++ failed
Re: Wine .NET app
On 6 September 2010 23:00, Vassilis Virvilis vas...@iit.demokritos.gr wrote:
Hi everybody,
My name is Vassilis Virvilis and I am trying to get .net app to run under
wine.
The objective of the questions below is to determine what needs to be
implemented in wine in order to support the app.
So the app bring its window momentarily and then it crashes with a
'Unsupported color conversion request'
How difficult to implement are the following error messages?
1) Where is the code that prints 'Unsupported color conversion request'. I
can't find it
Googling the error indicates that it is coming from libjpeg:
JMESSAGE(JERR_CONVERSION_NOTIMPL, Unsupported color conversion request)
You probably want the windowscodecs trace output to see where it is failing.
2) JpegDecoder_Frame_GetResolution doesn't look terribly difficult to
implement. Am I completely misguided?
Looking at the parameter names they indicate that the resolutions are
in dots per inch (DPI), so that may complicate things a bit. As
always, this will need test coverage.
3) URL_ParseUrl lives in in dlls/shwapi/url.c around 1979. The implementation
looks fleshed enough. What is the problem?
URL_ParseUrl is being passed a URL like System.Xml -- the function
is not handling this as a valid URL.
Here, tests will be needed to see how Windows behaves and the wine
implementation should then be improved to cover that/those cases.
4) The GUID are referring to IManaged, IProvideClassInfo, IMarshal,
IRpcOptions. What is the implementation scope of these?
Looking at the fixme's -- fixme:ole:OLEPictureImpl_QueryInterface ()
-- those interfaces are being requested for and not found in the
OLEPicture implementation.
NOTE: A test case will need to be added for each of these to check if
Windows actually implements those interfaces for the OLEPicture
object.
Something along the lines of:
IUnknown *picture = ...; /* OLEPicture object from existing tests. */
IManaged * managed = NULL;
HRESULT hr;
int refcount;
hr = picture-QueryInterface(IID_IManaged, (void **)managed);
ok(hr == S_OK, OLEPicture should support IManaged: expected S_OK,
got 0x%08x\n, hr);
IUnknown_AddRef(picture);
refcount = IUnknown_Release(picture);
ok(refcount == 2, Expected there to be 2 references to
OLEPicture, got %d\n, refcount);
text_picture_managed(managed); /* test IManaged methods */
IUnknown_Release(managed);
Here is the log:
fixme:actctx:parse_manifest_buffer root element is Lasmv1:assembly, not
assembly
Manifest parsing should support xmlns:name=... qualifiers for
elements as well as xmlns=... qualifiers. This will need tests.
fixme:sync:CreateMemoryResourceNotification (0) stub
fixme:shell:URL_ParseUrl failed to parse LMicrosoft.VisualBasic
fixme:shell:URL_ParseUrl failed to parse LSystem
fixme:shell:URL_ParseUrl failed to parse LSystem.Windows.Forms
fixme:shell:URL_ParseUrl failed to parse LSystem.Drawing
fixme:shell:URL_ParseUrl failed to parse LSystem.Runtime.Remoting
fixme:shell:URL_ParseUrl failed to parse LSystem.Configuration
fixme:shell:URL_ParseUrl failed to parse LSystem.Xml
fixme:shell:URL_ParseUrl failed to parse Lmscorlib.resources
fixme:shell:URL_ParseUrl failed to parse Lmscorlib.resources
fixme:shell:URL_ParseUrl failed to parse LSystem.Drawing.resources
fixme:shell:URL_ParseUrl failed to parse LSystem.Drawing.resources
fixme:gdiplus:GdipGetFamilyName No support for handling of multiple languages!
fixme:shell:URL_ParseUrl failed to parse LLMA.resources
fixme:shell:URL_ParseUrl failed to parse LLMA.resources
fixme:shell:URL_ParseUrl failed to parse LLMA.resources
fixme:gdiplus:GdipCreateHalftonePalette stub
fixme:shell:URL_ParseUrl failed to parse LSystem.Xml.XmlSerializers
fixme:shell:URL_ParseUrl failed to parse LLMA.resources
fixme:wincodecs:JpegDecoder_Frame_GetResolution (0x16d2dc,0x32dd48,0x32dd40):
stub
fixme:shell:URL_ParseUrl failed to parse LLMA.resources
fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported
interface {c3fcc19e-a970-11d2-8b5a-00a0c9b7c9c4}
fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported
interface {b196b283-bab4-101a-b69c-00aa00341d07}
fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported
interface {0003---c000-0046}
fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported
interface {0144---c000-0046}
fixme:wincodecs:JpegDecoder_Frame_GetResolution (0x1a9924,0x32de38,0x32de30):
stub
Unsupported color conversion request
Thanks in advance
Vassilis Virvilis
Re: Wine .NET app
On 07/09/2010 02:02 πμ, Reece Dunn wrote: Googling the error indicates that it is coming from libjpeg: JMESSAGE(JERR_CONVERSION_NOTIMPL, Unsupported color conversion request) thanks. You probably want the windowscodecs trace output to see where it is failing. 2) JpegDecoder_Frame_GetResolution doesn't look terribly difficult to implement. Am I completely misguided? Looking at the parameter names they indicate that the resolutions are in dots per inch (DPI), so that may complicate things a bit. As always, this will need test coverage. 3) URL_ParseUrl lives in in dlls/shwapi/url.c around 1979. The implementation looks fleshed enough. What is the problem? URL_ParseUrl is being passed a URL like System.Xml -- the function is not handling this as a valid URL. Here, tests will be needed to see how Windows behaves and the wine implementation should then be improved to cover that/those cases. 4) The GUID are referring to IManaged, IProvideClassInfo, IMarshal, IRpcOptions. What is the implementation scope of these? Looking at the fixme's -- fixme:ole:OLEPictureImpl_QueryInterface () -- those interfaces are being requested for and not found in the OLEPicture implementation. NOTE: A test case will need to be added for each of these to check if Windows actually implements those interfaces for the OLEPicture object. Something along the lines of: IUnknown *picture = ...; /* OLEPicture object from existing tests. */ IManaged * managed = NULL; HRESULT hr; int refcount; hr = picture-QueryInterface(IID_IManaged, (void **)managed); ok(hr == S_OK, OLEPicture should support IManaged: expected S_OK, got 0x%08x\n, hr); IUnknown_AddRef(picture); refcount = IUnknown_Release(picture); ok(refcount == 2, Expected there to be 2 references to OLEPicture, got %d\n, refcount); text_picture_managed(managed); /* test IManaged methods */ IUnknown_Release(managed); Here is the log: fixme:actctx:parse_manifest_buffer root element is Lasmv1:assembly, notassembly Manifest parsing should support xmlns:name=... qualifiers for elements as well as xmlns=... qualifiers. This will need tests. Also thanks for the code dump. I will try to add that code as an OLE test and see what happens. I am a wine and git newbie so that may take while. One more question: Based on your experience what do you think is the first thing look after in order to move my application forward. I would say the color conversion problem and or the jpegDecoder_Frame_GetResolution... Vassilis
Re: Wine .NET app
On 7 September 2010 00:26, Vassilis Virvilis vas...@iit.demokritos.gr wrote: On 07/09/2010 02:02 πμ, Reece Dunn wrote: Googling the error indicates that it is coming from libjpeg: JMESSAGE(JERR_CONVERSION_NOTIMPL, Unsupported color conversion request) thanks. You probably want the windowscodecs trace output to see where it is failing. 2) JpegDecoder_Frame_GetResolution doesn't look terribly difficult to implement. Am I completely misguided? Looking at the parameter names they indicate that the resolutions are in dots per inch (DPI), so that may complicate things a bit. As always, this will need test coverage. 3) URL_ParseUrl lives in in dlls/shwapi/url.c around 1979. The implementation looks fleshed enough. What is the problem? URL_ParseUrl is being passed a URL like System.Xml -- the function is not handling this as a valid URL. Here, tests will be needed to see how Windows behaves and the wine implementation should then be improved to cover that/those cases. 4) The GUID are referring to IManaged, IProvideClassInfo, IMarshal, IRpcOptions. What is the implementation scope of these? Looking at the fixme's -- fixme:ole:OLEPictureImpl_QueryInterface () -- those interfaces are being requested for and not found in the OLEPicture implementation. NOTE: A test case will need to be added for each of these to check if Windows actually implements those interfaces for the OLEPicture object. Something along the lines of: IUnknown *picture = ...; /* OLEPicture object from existing tests. */ IManaged * managed = NULL; HRESULT hr; int refcount; hr = picture-QueryInterface(IID_IManaged, (void **)managed); ok(hr == S_OK, OLEPicture should support IManaged: expected S_OK, got 0x%08x\n, hr); IUnknown_AddRef(picture); refcount = IUnknown_Release(picture); ok(refcount == 2, Expected there to be 2 references to OLEPicture, got %d\n, refcount); text_picture_managed(managed); /* test IManaged methods */ IUnknown_Release(managed); Here is the log: fixme:actctx:parse_manifest_buffer root element is Lasmv1:assembly, notassembly Manifest parsing should support xmlns:name=... qualifiers for elements as well as xmlns=... qualifiers. This will need tests. Also thanks for the code dump. I will try to add that code as an OLE test and see what happens. I am a wine and git newbie so that may take while. One more question: Based on your experience what do you think is the first thing look after in order to move my application forward. I would say the color conversion problem and or the jpegDecoder_Frame_GetResolution... I'd say look at what is causing the color conversion error first, then look at GetResolution. I don't know that area of the code -- that would be Vincent Povirk. These two traces could be related, so I would alse check adding the wincodecs debug channel to see the jpegformat.c tracing and which function the color conversion error is happening in. Also, if it is failing to load a specific jpeg on disk, you might want to see if libjpeg can decode it properly. - Reece
Re: Wine .NET app
Reece Dunn wrote: On 6 September 2010 23:00, Vassilis Virvilis vas...@iit.demokritos.gr wrote: fixme:shell:URL_ParseUrl failed to parse LMicrosoft.VisualBasic fixme:shell:URL_ParseUrl failed to parse LSystem fixme:shell:URL_ParseUrl failed to parse LSystem.Windows.Forms fixme:shell:URL_ParseUrl failed to parse LSystem.Drawing fixme:shell:URL_ParseUrl failed to parse LSystem.Runtime.Remoting fixme:shell:URL_ParseUrl failed to parse LSystem.Configuration fixme:shell:URL_ParseUrl failed to parse LSystem.Xml fixme:shell:URL_ParseUrl failed to parse Lmscorlib.resources fixme:shell:URL_ParseUrl failed to parse Lmscorlib.resources fixme:shell:URL_ParseUrl failed to parse LSystem.Drawing.resources fixme:shell:URL_ParseUrl failed to parse LSystem.Drawing.resources fixme:shell:URL_ParseUrl failed to parse LLMA.resources fixme:shell:URL_ParseUrl failed to parse LLMA.resources fixme:shell:URL_ParseUrl failed to parse LLMA.resources fixme:shell:URL_ParseUrl failed to parse LSystem.Xml.XmlSerializers fixme:shell:URL_ParseUrl failed to parse LLMA.resources These appear to be .NET errors and it might be a good idea to look into using Mono and see if these 'go away'. What version of .NET does the program require? winetricks supports installation of Mono 2.x and is, for now, the best way to get the product installed. Yes, we are looking into including it into the Wine package or as an add-on (like the Gecko engine.) Mono supports 1.1, 2.0 and 3.0 very well and 3.5 somewhat (and maybe better than that.) .NET 3.5 will not install, due to .dll dependencies, on Wine as it stands today. James McKenzie
Re: [1/4] msxml3/tests: Add a helper to create document instance, remove useless output
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=5059 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5804: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5804: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5804: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: [2/4] msxml3/domdoc: Implement IXMLDOMNamedNodeMap::removeQualifiedItem()
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=5060 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5869: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5869: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5869: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Must copy static const D3DVERTEXELEMENT9 into dynamically alllocated D3DVERTEXELEMENT9 * before pointer passed correctly in Wine?
Dear All:
Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I
encountered a very strange error.
Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter
to D3DXCreateMesh,
a) in Windows - one can create
static const D3DVERTEXELEMENT9 decl1[3] = {
{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,
D3DDECLUSAGE_POSITION, 0},
{0, 0xC, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,
D3DDECLUSAGE_NORMAL, 0},
D3DDECL_END(), };
and pass (LPD3DVERTEXELEMENT9 *)decl1 directly.
b) in Wine tests - I must first allocate a D3DVERTELEMENT9 *, then call
HeapAlloc, and finally copy my original decl1 and pass decl (pointer to
newly allocated structure) for it to work. Any ideas?
Here is my git diff
http://wine.1045685.n5.nabble.com/file/n2805542/patch patch
Thx
Misha
--
View this message in context:
http://wine.1045685.n5.nabble.com/Must-copy-static-const-D3DVERTEXELEMENT9-into-dynamically-alllocated-D3DVERTEXELEMENT9-before-pointe-tp2805542p2805542.html
Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: [3/4] msxml3/tests: Some tests for ::get_ownerDocument() returned document instance
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=5061 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5947: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5947: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5947: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: Wine .NET app
On Mon, Sep 6, 2010 at 6:26 PM, Vassilis Virvilis vas...@iit.demokritos.gr wrote: One more question: Based on your experience what do you think is the first thing look after in order to move my application forward. I would say the color conversion problem and or the jpegDecoder_Frame_GetResolution... If the program isn't using WIC directly (and few programs do), the GetResolution stub is probably harmless. It's most likely the color conversion problem. This will have to be debugged in libjpeg. I believe libjpeg errors currently result in a call to abort() instead of a failure return code. I really need to fix that someday.
Re: [4/4] msxml3/tests: Basic test for ::setAttributeNode()
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=5062 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5998: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5998: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5998: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: Console issues in recent git
Eric Pouech eric.pou...@orange.fr wrote: +void close_console( struct process* process) Shouldn't it be named close_bare_console()? Otherwise it won't compile. -- Dmitry.
Re: [5/6] urlmon: Some IUri's don't include the userinfo component in the absolute URI string
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=5068 Your paranoid android. === WXPPROSP3 (32 bit uri) === uri.c:5172: Test failed: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135].str_props[0]. uri.c:5172: Test failed: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136].str_props[0]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === WVISTAADM (32 bit uri) === uri.c:5172: Test failed: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135].str_props[0]. uri.c:5172: Test failed: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136].str_props[0]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === W2K8SE (32 bit uri) === uri.c:5172: Test failed: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135].str_props[0]. uri.c:5172: Test failed: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136].str_props[0]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0].
Re: winebuild: Don't segfault when running without arguments
André Hentschel n...@dawncrow.de wrote:
-if (!spec-dll_name) /* set default name from file name */
+if (!spec-dll_name spec-dll_name) /* set default name from file
name */
{
char *p;
spec-dll_name = xstrdup( spec-file_name );
Did you intend to check for spec-file_name?
--
Dmitry.
Re: [6/6] urlmon: Implemented IUriBuilder_{Get/Set}UserName
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=5069 Your paranoid android. === WXPPROSP3 (32 bit uri) === uri.c:5204: Test failed: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135].str_props[0]. uri.c:5204: Test failed: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136].str_props[0]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === WVISTAADM (32 bit uri) === uri.c:5204: Test failed: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135].str_props[0]. uri.c:5204: Test failed: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136].str_props[0]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === W2K8SE (32 bit uri) === uri.c:5204: Test failed: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135].str_props[0]. uri.c:5204: Test failed: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136].str_props[0]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got Lhttp://@gov.uk/; on uri_tests[135]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got Lhttp://:@gov.uk/; on uri_tests[136]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0].
Must copy static const D3DVERTEXELEMENT9 into dynamically alllocated D3DVERTEXELEMENT9 * before pointer passed correctly in Wine?
Sorry for reposting - apparently my original nabble link did not work :(
---
Dear All:
Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I
encountered a very strange error.
Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter
to D3DXCreateMesh,
a) in Windows - one can create
static const D3DVERTEXELEMENT9 decl1[3] = {
{0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,
D3DDECLUSAGE_POSITION, 0},
{0, 0xC, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,
D3DDECLUSAGE_NORMAL, 0},
D3DDECL_END(), };
and pass (LPD3DVERTEXELEMENT9 *)decl1 directly.
b) in Wine tests - I must first allocate a D3DVERTELEMENT9 *, then call
HeapAlloc, and finally copy my original decl1 and pass decl (pointer to
newly allocated structure) for it to work. Any ideas?
Here is my git diff
http://wine.1045685.n5.nabble.com/file/n2805603/patch patch
Thx
Misha
--
View this message in context:
http://wine.1045685.n5.nabble.com/Must-copy-static-const-D3DVERTEXELEMENT9-into-dynamically-alllocated-D3DVERTEXELEMENT9-before-pointe-tp2805603p2805603.html
Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: Wine .NET app
On 07/09/2010 02:53 πμ, James McKenzie wrote: These appear to be .NET errors and it might be a good idea to look into using Mono and see if these 'go away'. What version of .NET does the program require? I tried it. I didn't mention it because I didn't want to clutter my first message. The application dies a similar death with gif and jpeg warnings and finally a color conversion error winetricks supports installation of Mono 2.x and is, for now, the best way to get the product installed. Yes, we are looking into including it into the Wine package or as an add-on (like the Gecko engine.) Mono supports 1.1, 2.0 and 3.0 very well and 3.5 somewhat (and maybe better than that.) .NET 3.5 will not install, due to .dll dependencies, on Wine as it stands today. winetricks managed to install dotnet 3 Vassilis
