Kirill K. Smirnov wrote:
>
> WriteFile does not output unicode characters to console screen buffer, so if
> ConsoleOutputCP is smth like 65001, this will fail.
> The page http://msdn2.microsoft.com/en-us/library/ms687401.aspx contains
> remedy by Microsoft how to deal with problem:
> 1) If device
Hi,
On the git web page, the commands to run to perform "Cleaning up your
existing tree" and "Staying Up-To-Date" have been merge to one line.
Best Regards
Alistair Leslie-Hughes
Hello,
As you probably have noticed, downloading Gecko on first use confuses
users. Now, with last week patches, there is an other way to do it,
transparent for users. MSHTML code looks for cab file in $data_dir/gecko
(that is usually /usr/share/wine/gecko). Alternatively, if you run Wine
from bui
On Wednesday 24 October 2007 23:58:51 [EMAIL PROTECTED] wrote:
> Hi,
> would be great to have a longer period to stay logged in.
> A setting under preference for the period seems a good solution,
> Btw: What is the status of appdb/bugzilla(wiki?)-account-fusion?
>
> Bye,
> Julian
The login period
Hi,
would be great to have a longer period to stay logged in.
A setting under preference for the period seems a good solution,
Btw: What is the status of appdb/bugzilla(wiki?)-account-fusion?
Bye,
Julian
On Wednesday 24 October 2007 20:57:08 Hans Leidekker wrote:
> I count 20 InternetConnect calls in ftp.c so with your 20 second
> quota we have about one second per connection. On my Windows VM
> the test takes about 13 seconds so I think we should be able to
> bring it down to below 20 seconds. I'
> Note that the http test also makes several connections to winehq
> but it doesn't show up in your list.
Okay, but those fail immediately for me, so they don't take any time.
(Yes, I should log a bug. Sorry.)
--Juan
On Wednesday 24 October 2007 20:17:19 Dan Kegel wrote:
> Here are all the tests that take more than five seconds:
>
> 5.407s advapi32_test.exe.so service.c
> 6.010s kernel32_test.exe.so console.c
> 6.252s user32_test.exe.so msg.c
> 9.657s kernel32_test.exe.so process.c
> 12.053s winmm_test.ex
Hello.
I've sent a patch that changes X11DRV_GetSystemPaletteEntries behavior and a
test something like a week ago. I guess they fell into that so called not
obviously correct category (or maybe not correct at all one). I'll appreciate
any comments or suggestions on possible improvements. Than
> IMHO we should disable the ftp test until its runtime can
> be brought down below 20 seconds. It's just too slow,
> and too dependent on stuff not under Wine's control
> (e.g. one's internet connection).
Agreed, it takes too long to bother with here as well, and I'm also
suffering with a really
Here are all the tests that take more than five seconds:
5.407s advapi32_test.exe.so service.c
6.010s kernel32_test.exe.so console.c
6.252s user32_test.exe.so msg.c
9.657s kernel32_test.exe.so process.c
12.053s winmm_test.exe.so timer.c
14.080s shell32_test.exe.so shlexec.c
17.760s msi_test.ex
Markus Gömmel <[EMAIL PROTECTED]> writes:
>> I suppose it was rejected by AJ based on the patch content.
>
> Hm, but the content of the patch is what Windows do, so rejecting cause of
> the content sounds a bit unlikely to me...
We of course have to create the directory, but I think it would be
L. Rahyen wrote:
> Now 2.6.23 is stable so everyone can easily try and test it. All major
> distribution should provide precompiled 2.6.23 kernels in near future.
Thanks for your test!
> So it's really ok to create a patch with only the patch as text without any
> attachment?
At one point that was the preferred way. I don't know whether it
still is, but I'm sure it's still accepted. Its risky with some (bad)
mailers, because they may wrap lines, but if you absolutely can't use
So it's really ok to create a patch with only the patch as text without any
attachment?
Markus
"Juan Lang" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> I usually use the archives for viewing patches, sometimes the patches
>> are archived separately to the email.
>>
>> Markus'
> I suppose it was rejected by AJ based on the patch content.
Hm, but the content of the patch is what Windows do, so rejecting cause of
the content sounds a bit unlikely to me...
bye bye
Markus
Oh God!
Sorry about that!
Dmitry Timoshkov wrote:
"Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
+HRESULT WINAPI HRESULT OleLoadPictureFile(
+ VARIANT varFileName,
+ LPDISPATCH *lplpdispPicture )
HRESULT is duplicated.
$ diff -up /usr/src/wine/dlls/oleaut32/stubs.c stubs.c
---
Added OleLoadPictureFile stub.
Dmitry Timoshkov wrote:
"Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
$ diff -up liboleaut32.def /usr/lib/wine/liboleaut32.def
--- liboleaut32.def 2007-08-23 16:15:48.0 +0200
+++ /usr/lib/wine/liboleaut32.def 2007-10-15 00:48:35.0
I'll try to find the correct files to add the stub and then send the
patch for that!
Dmitry Timoshkov wrote:
> "Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
>
>> $ diff -up liboleaut32.def /usr/lib/wine/liboleaut32.def
>> --- liboleaut32.def 2007-08-23 16:15:48.0 +0200
>> +++ /u
I hope it to be OK now!
Dmitry Timoshkov wrote:
"Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
Attached is the "patch" file (diff -up) regarding the bug:
http://bugs.winehq.org/show_bug.cgi?format=multiple&id=10156
The patch is reversed, please change the source/dest, rediff
and resend.
Yeah after I submitted the patch, I was thinking about that as well.
I will look at doing that.
-aric
Juan Lang wrote:
> Hi Aric,
>
> @@ -104,6 +104,9 @@ DWORD getInterfaceStatsByName(const char
> {
>FILE *fp;
>
> +#ifdef __APPLE__
> + return ERROR_NOT_SUPPORTED;
> +#endif
>
> This is ug
Hi Aric,
@@ -104,6 +104,9 @@ DWORD getInterfaceStatsByName(const char
{
FILE *fp;
+#ifdef __APPLE__
+ return ERROR_NOT_SUPPORTED;
+#endif
This is ugly. Why not just change the case when fp is NULL? You've
already got:
fp = fopen("/proc/net/dev", "r");
if (fp) {
...
}
else
ERR
"Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
> +HRESULT WINAPI HRESULT OleLoadPictureFile(
> + VARIANT varFileName,
> + LPDISPATCH *lplpdispPicture )
HRESULT is duplicated.
--
Dmitry.
"Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
> $ diff -up liboleaut32.def /usr/lib/wine/liboleaut32.def
> --- liboleaut32.def 2007-08-23 16:15:48.0 +0200
> +++ /usr/lib/wine/liboleaut32.def 2007-10-15 00:48:35.0 +0200
> @@ -366,7 +366,6 @@ EXPORTS
> [EMAIL PROTEC
On Wed, 24 Oct 2007, Robert Shearman wrote:
> It's a false positive, probably coming from the compiler not picking
> up that it is set when the exception variable is false and that when
> exception is true it is set earlier in the function.
Ah, thanks for the analysis. I couldn't convince myself
On Wed, Oct 24, 2007 at 01:29:03PM +0200, Jan Zerebecki wrote:
> On Tue, Oct 23, 2007 at 02:53:19PM +0200, Stefan Dösinger wrote:
> > This is how your mail arrived at the mailing list archive as far as I can
> > see:
> > http://www.winehq.org/pipermail/wine-patches/2007-October/045287.html
>
> It
"Marcos Gutiérrez Batz" <[EMAIL PROTECTED]> wrote:
> Attached is the "patch" file (diff -up) regarding the bug:
>
> http://bugs.winehq.org/show_bug.cgi?format=multiple&id=10156
The patch is reversed, please change the source/dest, rediff
and resend.
--
Dmitry.
Dan Hipschman <[EMAIL PROTECTED]> writes:
> This patch sets up the oleaut32 Makefile and shuffles some files
> around so we can use widl to generate oaidl_p.c. The patch is *very*
> large since it contains a diff for all of oaidl_p.c (which was
> removed), and also two for oaidl.idl (which was mo
Gerald Pfeifer wrote:
> It seems there are some code paths (in the error case?) which may
> leave this unitialized. At least the compiler thinks so, and I
> could not convince myself otherwise reading this code for a while.
>
It's a false positive, probably coming from the compiler not picking
On Wed, Oct 24, 2007 at 01:29:03PM +0200, Jan Zerebecki wrote:
> On Tue, Oct 23, 2007 at 02:53:19PM +0200, Stefan Dösinger wrote:
> > This is how your mail arrived at the mailing list archive as far as I can
> > see:
> > http://www.winehq.org/pipermail/wine-patches/2007-October/045287.html
>
> It
On Tue, Oct 23, 2007 at 02:53:19PM +0200, Stefan Dösinger wrote:
> This is how your mail arrived at the mailing list archive as far as I can see:
> http://www.winehq.org/pipermail/wine-patches/2007-October/045287.html
It seems that is a problem with pipermail. It displays fine with
mutt (from loca
Hi ,
I have an executable that resides and compiled on windows 2003 server,
I want to approach from my UNIX Solaris machine and run the executable.
If anyone knows how to do that, or what can I use to run that I will be very
happy.
Thanks,
SE
> static void output(const char *message)
> {
>- DWORD count;
>- WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message),
>&count, NULL);
>+ DWORD count = 0;
>+ WCHAR *mesW = NULL;
>+ char *mes = NULL;
>+ int wlen = 0;
>+ int len = 0;
>+
On Monday October 8 2007 23:01, TheBlunderbuss wrote:
> L. Rahyen wrote:
> Please test with your uniprocessor and get back to us on it. Not all of us
> can have the top-of-the-line system. To all: stay away from Celerons! 128KB
> L2 isn't enough!
Sorry for a big delay in reply. In practi
34 matches
Mail list logo
