On 9/28/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
"James Hawkins" <[EMAIL PROTECTED]> wrote:
> make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests'
> msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not
> complete: expected - actual 0021
0021 is WM_MOUSEACTIVATE
"James Hawkins" <[EMAIL PROTECTED]> wrote:
make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests'
msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not
complete: expected - actual 0021
0021 is WM_MOUSEACTIVATE. Please re-run the test without touching
mouse and see if it
On 9/28/06, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
James Hawkins wrote:
> On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote:
>> > Hi,
>> >
>> > Running make test fails with:
>> >
>> > make[2]: Entering directory `/usr/local/src/wine/
James Hawkins wrote:
> On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote:
>> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote:
>> > Hi,
>> >
>> > Running make test fails with:
>> >
>> > make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests'
>> > ../../../tools/runtest -q -P win
On 28/09/06, James Hawkins <[EMAIL PROTECTED]> wrote:
Then whoever wrote the test needs to figure out why the test fails on
most machines, but passes on mine. 'make test' should not fail on any
machine.
Stefan wrote that test. It's probably succeeding because your card
supports GL_ARB_texture_n
On Do, 2006-09-28 at 05:31 +0900, Mike McCormack wrote:
> > When switching the Instructions for the Wine tree
> > from cvs to git, the Instructions for the
> > additional modules (docs, lostwages, ...) got lost.
>
> They're still available at the old link:
>
> http://www.winehq.org/site/cvs
I w
Paul Vriens wrote:
> On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote:
>
>>Hi,
>>
>>Running make test fails with:
>>
>>make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests'
>>../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
>>comctl32_test.exe.so tab.c && touc
Hi,
This is with a clean .wine.
make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests'
../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p
user32_test.exe.so sysparams.c && touch sysparams.ok
sysparams.c:1471: Test failed: wrong value in registry -1, expected 154
sysparams.
Hi,
make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests'
msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not
complete: expected - actual 0021
msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0
fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet
f
Hi,
make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests'
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR)
monitor.c:143: Test failed: Failed to change resolution[0]: -2
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR)
moni
The spec file line read '+@ stdcall wglUseFontOutlinesW(long long long long
long long long ptr) gdi32.wglUseFontOutlinesW' the last part wasn't needed I
think. I thought it was about that. Didn't see the FontBitmaps/FontOutlines
issue ..
I guess I'll need a take 4 and hope it is right then.
T
On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote:
> Again as mentioned by Huw, the gdi32.spec file wasn't correct.
> It should be correct this time.
No. Your gdi32.spec was fine. It was the opengl32.spec that was
wrong (hint: that's why I quoted that bit of the patch ;-).
Y
Hi,
make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests'
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p
shell32_test.exe.so shlfileop.c && touch shlfileop.ok
shlfileop.c:168: Test failed: The requested file does not exist, ret=3
make[2]: *** [shlfileop.ok] Error 1
On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote:
On Thu, 2006-09-28 at 11:30 -0700, James Hawkins wrote:
> Hi,
>
> This test passes on my machine, should it not?
>
> make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests'
> ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p
On 9/28/06, Paul Vriens <[EMAIL PROTECTED]> wrote:
On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote:
> Hi,
>
> Running make test fails with:
>
> make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests'
> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
> comctl3
On Thu, 2006-09-28 at 11:30 -0700, James Hawkins wrote:
> Hi,
>
> This test passes on my machine, should it not?
>
> make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests'
> ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p
> d3d9_test.exe.so surface.c && touch surface.ok
>
On Thu, 2006-09-28 at 11:27 -0700, James Hawkins wrote:
> Hi,
>
> Running make test fails with:
>
> make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests'
> ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
> comctl32_test.exe.so tab.c && touch tab.ok
> tab.c:184: Te
Hi,
This test passes on my machine, should it not?
make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests'
../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p
d3d9_test.exe.so surface.c && touch surface.ok
fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub,
Hi,
Running make test fails with:
make[2]: Entering directory `/usr/local/src/wine/dlls/comctl32/tests'
../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
comctl32_test.exe.so tab.c && touch tab.ok
tab.c:184: Test failed: no icon, set size: Expected [44,20] got [56,20]
tab.c:208: T
On 9/28/06, Chris Morgan <[EMAIL PROTECTED]> wrote:
I've almost never been unhappy with AJ's judgement except in cases
like the safedisc patches where it seemed like no one really knew what
was "good" and more effort wasn't put into at least providing
development guidance.
http://www.winehq.o
When I was creating the stub I looked around in several dll's and some
of the them export DllMain.
./advpack/advpack.spec:@ stdcall -private DllMain(long long ptr)
./dciman32/dciman32.spec:@ stdcall -private DllEntryPoint(long long ptr) DllMain
./itss/itss.spec:@ stdcall -private DllMain(long lon
On Thu, September 28, 2006 9:24 am, Chris Morgan wrote:
> I'm of the opinion that code is "art" as its implementation is
> subjective. The idea that you could document when a patch is
> acceptable or not seems like an impossibility.
I wholeheartedly subscribe to this. We are far away (as a profes
Vitaliy Margolen wrote:
> Thomas Weidenmueller wrote:
>> The parameter of RpcMgmtSetServerStackSize needs to be unsigned long,
>> not unsigned int.
>>
>> - Thomas
>>
> It's been discussed numerous times, you should avoid use of 'long' in
> Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) =
On Thu, 2006-09-28 at 07:01 -0600, Vitaliy Margolen wrote:
> Paul Vriens wrote:
> > Hi,
> >
> > I was browsing some code and found that we have several places where we
> > made our own implementation of a recursive delete of registry
> > keys/value.
> See winecfg.
>
> Vitaliy.
>
Do you mean wine
On 28.09.2006 15:26, Paul Vriens wrote:
> I'll have a few hours tomorrow and will have a look. The cleanest
> solution for now seems to create RegDeleteTree[A|W] in advapi32 and use
> that wherever possible (unless we find that it forwards to shlwapi).
> Most DLL's already import advapi32.
Hmm...
2. Alexandre documents the exact logic he uses to determine patch
acceptability which becomes the patch acceptance policy in the interim. This
should be done to the point that someone else could take over from Alexandre
and achieve the same result. This opens the way to multiple maintainers as
wel
Paul Vriens wrote:
> Hi,
>
> I was browsing some code and found that we have several places where we
> made our own implementation of a recursive delete of registry
> keys/value.
See winecfg.
Vitaliy.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Lunnon wrote:
arrgh, I know you're not supposed to feed the trolls, but...
I'm a user I find wine to be very useful. I've got a client who owns a
bus charter line that was able to move away from windows, and the only
thing they needed was th
Hi,
I was browsing some code and found that we have several places where we
made our own implementation of a recursive delete of registry
keys/value.
Apparently there is an official one in Vista:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/regopenkeyex.asp
I do
Thomas Weidenmueller wrote:
> The parameter of RpcMgmtSetServerStackSize needs to be unsigned long,
> not unsigned int.
>
> - Thomas
>
It's been discussed numerous times, you should avoid use of 'long' in
Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8.
Vitaliy.
> From: Jakob Eriksson [mailto:[EMAIL PROTECTED]
>
> I have been watching this thread with keen interest.
>
> Alexandre does not HAVE to respond to that patch, he can
> silently ignore it just like he can now.
>
> The only difference with Patchwork would be that after a
> certain time with no
This e-mail belongs in wine-user not here. Please read error messages
yourself first.
Vitaliy
Paul Wilkinson wrote:
> I’m running wine v 0.9.20 under Fedora Core 5.
>
>
>
> I'm trying to get the Syncrosoft License Control Center to run under
> wine. for some reason it can only load MFC42.DLL
There is bug in wine, which prevents me to play NFS MW with sound (and
even Call of Duty). I would like to offer some money for solving this
bug. I dont know how much will be good and i can give you all info from
my system to solve this (debug, system info). If you are interested in
just reply on
Julien <[EMAIL PROTECTED]> writes:
> +/***
> + * SetupDiDestroyClassImageList(SETUPAPI.@)
> + */
> +BOOL WINAPI SetupDiDestroyClassImageList(PSP_CLASSIMAGELIST_DATA
> ClassImageListData)
> +{
> +FIXME ("Stub %p\n",
Alexandre said
=
To be honest, I have no idea what it is that you are suggesting. All I
see is phrases like "community focused process" or "acceptance policy"
which frankly are just meaningless buzzwords. If you expect anything
to happen, you'll need to make
Benjamin Arai wrote:
+@ stdcall -private DllMain(long long ptr)
There's no need to export DllMain.
--
Rob Shearman
"James Hawkins" <[EMAIL PROTECTED]> writes:
> +static LPWSTR msi_read_text_archive(LPCWSTR path)
> {
> -FIXME("%p %s %s\n", db, debugstr_w(folder), debugstr_w(file) );
> +HANDLE file;
> +LPSTR data = NULL;
> +DWORD read, size = 0;
> +
> +file = CreateFileW( path, GENERIC_READ,
Hello Mike,
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> That sounds good, but it's not reasonable to put the
> responsibility on Alexandre, as he has enough work already.
Unless you can read Alexandres mind, he's really the only one who can tell
what he didn't like about a certain pa
Ge van Geldorp wrote:
My objective is to improve Wine by maximizing the number of patches of
acceptable quality. In my opinion, this can be done by:
1) assuring no patches get lost
2) assuring an author gets informed about why his patch is not acceptable in
its current form so he can improve it
On Thu, 2006-09-28 at 12:00 +0200, Detlef Riekenberg wrote:
> On Mi, 2006-09-27 at 14:43 +0200, Paul Vriens wrote:
>
> > Got an email from a Coverity guy.
>
> > Apparently they have some backlog but Wine is by no means not covered
> > anymore.
> > Things should settle down soon and we can look fo
On Mi, 2006-09-27 at 14:43 +0200, Paul Vriens wrote:
> Got an email from a Coverity guy.
> Apparently they have some backlog but Wine is by no means not covered
> anymore.
> Things should settle down soon and we can look forward to some nice
> reports again.
Great news.
Examining and fixing all
I’m running wine v 0.9.20 under Fedora Core 5.
I'm trying to get the Syncrosoft
License Control
Center to run under
wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I
put 'sudo' on the command line:
[EMAIL PROTECTED] LCC]$ wine LCC.exe
err:module:import_dll L
On Thursday 28 September 2006 05:49, Mike McCormack wrote:
> Seems like that is a system that doesn't scale well at all, as it
> requires Alexandre to specifically respond to each and every patch.
He still has to take an action to review each patch now, and presumably some
action to remove it fr
Ge van Geldorp gse.nl> writes:
>
> > From: Vitaliy Margolen kievinfo.com>
> >
> > So in a sense you will require some one to respond for any
> > incoming e-mail to wine-patches. And if no one does,
> > Alexandre don't get to see the status?
>
> Not sure I understand what you mean. If no-one
On Thu, Sep 28, 2006 at 08:01:00AM +0200, Roderick Colenbrander wrote:
> As mentioned by Huw, I forgot to attach the gdi32.spec changes :(
> This is (hopefully) a full patch.
>
> --- dlls/opengl32/opengl32.spec 2006-09-25 23:15:35.0 +0200
> +++ dlls/opengl32/opengl32.spec 2006-
> From: Vitaliy Margolen <[EMAIL PROTECTED]>
>
> So in a sense you will require some one to respond for any
> incoming e-mail to wine-patches. And if no one does,
> Alexandre don't get to see the status?
Not sure I understand what you mean. If no-one responds to the patch on
wine-devel the patc
"Benjamin Arai" <[EMAIL PROTECTED]> writes:
> + if (fAbbrev)
> +if (iFirstDay == 0)
> + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 5) %
> 7);
> +else
> + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) %
> 7);
> + else
> +if (iFirst
> On 28/09/06, James Hawkins <[EMAIL PROTECTED]> wrote:
> > Why should someone have to install glx to run Wine if they don't care
> > about using wined3d, or if they do need to use wined3d they don't care
> > about using glx? Wine should at least be able to compile in
> > circumstances such as the
On 28/09/06, James Hawkins <[EMAIL PROTECTED]> wrote:
Why should someone have to install glx to run Wine if they don't care
about using wined3d, or if they do need to use wined3d they don't care
about using glx? Wine should at least be able to compile in
circumstances such as these. There could
49 matches
Mail list logo
