Kuba Ober wrote:
Popping up console windows is equal to not working for me. (...)
Also, I'd love it a lot if all the ncurses crap was avoided. The compilers
output plain text on the standard output (whatever that is on windows).
Why don't you just use "wcmd "?
As I gather, "wineconsole"
On Tue, 2006-08-08 at 13:48 +0100, Mike Hearn wrote:
>
> It's not that we need to slow it down - slowing something down is
> never an acceptable solution to a race. We are missing some kind of
> synchronisation somewhere,
>
Actually, I don't think it has to do with synchronization--I think it
Monday, August 7, 2006, 10:33:02 AM, Krzysztof Foltman wrote:
> Vitaliy Margolen wrote:
>> I think this patch takes number of asserts per line to the highest level I've
>> ever seen. Could you explain why you adding asserts everywhere (only 11 in
>> this
>> patch alone!!!)? Instead of using prope
Monday, August 7, 2006, 1:48:49 PM, Phil Krylov wrote:
>> Have you even tried your code on purposely broken rtf? How does it handle it?
> Broken rtf can only possibly break the RTF reader code, although it
> has not been happening for quite a long time. And the asserts are
> there to report Wine r
Duane Clark wrote:
Changelog: In text mode a ctrl-z signals EOF
Spotted by David Hagood with test suggested by Dan Kegel
Howdy David. Any chance you could try out this patch? I added a
conformance test, as suggested by Dan, and it looks like any data after
a ctrl-z is stripped. O
On Tue, Aug 08, 2006 at 09:27:23PM +0200, Eric Pouech wrote:
> what I don't like is that in order to plug a hole (casting from const
> foo* to foo*), we create a bigger hole by allowing to cast from const
> foo* to bar* (and the compiler will not give any warning)
> if we want to go into this, th
And weren't you going to work on a conformance test for this?
On 8/8/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
Please put a link to your patch that has been sent to wine patches.
So that interested people can easily locate it and review it.
Thanks,
VJ
On 8/8/06, Augusto Arcoverde da Ro
Tijl Coosemans <[EMAIL PROTECTED]> writes:
> Only the super-user can increase the max limit. Other users can only
> decrease it. And all those unix shared libs (x11, etc.) need heap space
> as well. I don't know how much they all need. Maybe a 128Mb heap would
> be sufficient? That would bring us
Tijl Coosemans <[EMAIL PROTECTED]> writes:
> You mean prepending all functions with msvcrt_ or something?
> Or just execve?
Just execve (other functions that conflict with libc are already
prefixed with MSVCRT).
--
Alexandre Julliard
[EMAIL PROTECTED]
Please put a link to your patch that has been sent to wine patches.
So that interested people can easily locate it and review it.
Thanks,
VJ
On 8/8/06, Augusto Arcoverde da Rocha <[EMAIL PROTECTED]> wrote:
Hi all,
A little time ago I have sent this patch and now I'm asking to the
Wine devel co
Hi all,
A little time ago I have sent this patch and now I'm asking to the
Wine devel community about the correctness of that code.
May be a fix for "Icons in Notes" bug would be incorporated in the
next Wine release with some peer-review efforts.
Regards,
Augusto Arcoverde da Rocha
On 7/21/06
On Tuesday 08 August 2006 20:02, Alexandre Julliard wrote:
> Tijl Coosemans <[EMAIL PROTECTED]> writes:
>
> > * use execve on FreeBSD
>
> Renaming the msvcrt function would really be better. Particularly
> since "extern char **environ" doesn't work right on all platforms.
You mean prepending all
On Tuesday 08 August 2006 20:05, Alexandre Julliard wrote:
> Tijl Coosemans <[EMAIL PROTECTED]> writes:
>
> > Currently I lower RLIMIT_DATA to 0x1800 (384Mb) in wine-glibc and
> > locate wine-pthread at 0x6400. Is this an acceptable location?
> >
> > There has to be enough room after wine-
Hi Hendric & Xiaojing,
hendric wrote:
> Hmm Chinese characters were shown as "??". I think there must be
> something wrong with the code page. Either can't I input Chinese characters.
> Applications could not detect their running in Chinese local correctly. I
> think wine still need a gre
Andrew Talbot wrote:
David Laight wrote:
On Mon, Aug 07, 2006 at 09:54:20PM +0100, Andrew Talbot wrote:
would like to submit a patch that, for example, changes strchrW() to:
extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
WCHAR *ret = NULL;
do { if (*str == ch) re
Jeff L <[EMAIL PROTECTED]> writes:
> +cMaxItems = 255; /* Pick an abritary size for buffers */
> +analysis = (string_analysis*) pssa;
> +if (!*pssa) { /* Clean it out and start again */
> +prtssa(*pssa);
> +ScriptStringFree((SCRIPT_ST
Tijl Coosemans <[EMAIL PROTECTED]> writes:
> Currently I lower RLIMIT_DATA to 0x1800 (384Mb) in wine-glibc and
> locate wine-pthread at 0x6400. Is this an acceptable location?
>
> There has to be enough room after wine-pthread + data segment for
> every lib and dlopen'ed object. Moreover,
Tijl Coosemans <[EMAIL PROTECTED]> writes:
> * use execve on FreeBSD
Renaming the msvcrt function would really be better. Particularly
since "extern char **environ" doesn't work right on all platforms.
--
Alexandre Julliard
[EMAIL PROTECTED]
Marcus Meissner wrote:
> I asked our gcc gurus.
>
> - If you want to cast, do not use size_t but uintptr_t.
>
> Or:
>
> - Do not inline the function, and compile its file without -Wcast-qual.
>
> - Fix the prototype to read "extern inline const WCHAR *strrchrW( const
> WCHAR *str, WCHAR ch )"
> I try to explain why memcpy worked before.
>
> It did not worked. As far as I noticed, this bug does not affect small
> files (<=0x1000) but if file was large enough (>0x1000 byte) - it will
> appear.
[ . . . ]
Makes sense. Thanks for the explanation.
Cheers, Kuba
> > If anyone needs me to put money where my mouth is, I offer $100 via
> > PayPal if someone in charge wants financial coercion to avoid putting in
> > the X/graphical/ncurses crap for console applications. I'm dead serious.
>
> I'll see your bet, and raise you $150.
Wow, so you're saying that
Hi,Rob
Hmm Chinese characters were shown as "??". I think there must be
something wrong with the code page. Either can't I input Chinese characters.
Applications could not detect their running in Chinese local correctly. I think
wine still need a great improvement in supporting multiple
> > I know that not too many people are using wine like that, but right now
> > it works fine and I'd kindly ask for it to keep working, rather than get
> > broken.
>
> Nobody is suggesting to change the behavior for apps that don't use
> wineconsole. The only suggested change is to default to X in
hendric wrote:
> Hi,
> I'm very glad to read your words as I'm Chinese too. Well I've tried
> wine for running software of Windows but unfortunately I found it very poor
> in supporting Chinese.Well,any solution is appreciated.
>
You need to be specific. What is poor? Do Chinese character
Hi,
I'm very glad to read your words as I'm Chinese too. Well I've tried
wine for running software of Windows but unfortunately I found it very poor in
supporting Chinese.Well,any solution is appreciated.
Cheers!
Hendric Lee
--
hend
On 8/6/06, Vincent Povirk <[EMAIL PROTECTED]> wrote:
The patches in comments #13 and #5 had no effect.
I didn't try #2 because firefox doesn't change the screen resolution.
#2, #5, and #13 were all alternative versions of patches for the same
issue for the "Thief" game. It's not surprising th
Hi Matt,
On 07/08/06, Matt Finnicum <[EMAIL PROTECTED]> wrote:
This patch modifies ME_CharFromPoint to work properly with password
controls (the patch i sent in / got committed a couple days ago).
Should not the temp string be freed afterwards?
-- Ph.
hi
how are you?
i am one of wine users , it is a very amazing software i like it very much ,
and i have a problem here , does wine support other language? i use it to run one of foreign software which
is Chinese, but , the wine software can not display the language, so what can i do
Have you even tried your code on purposely broken rtf? How does it handle it?
Broken rtf can only possibly break the RTF reader code, although it
has not been happening for quite a long time. And the asserts are
there to report Wine riched20 developer's errors, not the app
developers'.
-- Ph.
Ad i suppose this should go to wine-patches. Same as the original
patch, but properly destroys the temporary string when it's no longer
needed.
Thanks,
--Matt
On 8/7/06, Matt Finnicum <[EMAIL PROTECTED]> wrote:
Oops! Good Call, Phil.
Attached is an updated patch.
--Matt
On 8/7/06, Phil Kr
On 8/8/06, Kuba Ober <[EMAIL PROTECTED]> wrote:
On Tuesday 08 August 2006 04:18, Alexandre Julliard wrote:
> Eric Pouech <[EMAIL PROTECTED]> writes:
> > also changing the default to user is a bad idea... especially for
> > users wanting to run a text only win32 app from a linux console
> > withou
Kuba Ober <[EMAIL PROTECTED]> writes:
> Also, I'd love it a lot if all the ncurses crap was avoided. The compilers
> output plain text on the standard output (whatever that is on windows). I'd
> hate to have some terminal crap inserted into that.
>
> I know that not too many people are using win
Why?
Er, if the memcpy worked (or almost worked) and failed due to overlap
problems, then memmove will do the trick. Did it ever work at all before?
Either this code never worked, or you're either seeing a problem that doesn't
exist/misunderstanding things.
Cheers, Kuba
Um, sorry, I didn't
"Dimi Paun" <[EMAIL PROTECTED]> writes:
> I used Wine for a while to run some command line tools (like some
> embedded assembler and linker). I certainly did not want a new console
> popup on each invocation. Not sure if this would be the case here,
> but it's certainly one of the most irritating
On Tue, 8 Aug 2006 09:37:09 -0400, Kuba Ober <[EMAIL PROTECTED]> wrote:
> > Fix rather unusual bug in LZ77 decompressor. We cannot use
> > memcpy
> > with overlapped areas because of unpredictable result. We must
> > copy byte-by-byte.
> Why don't you use memmove instead? The man page for m
On Tuesday 08 August 2006 04:18, Alexandre Julliard wrote:
> Eric Pouech <[EMAIL PROTECTED]> writes:
> > also changing the default to user is a bad idea... especially for
> > users wanting to run a text only win32 app from a linux console
> > without X started
>
> I think that's a very small minori
> > > Fix rather unusual bug in LZ77 decompressor. We cannot use
> > > memcpy
> > > with overlapped areas because of unpredictable result. We must
> > > copy byte-by-byte.
> > Why don't you use memmove instead? The man page for memcpy says:
> > Use memmove(3) if the memory areas do overlap.
> W
People, I am working on ScriptStringXtoCP etc in usp10. In setting up
the tests for this I notice that ABC widths returned ScriptPlace (GetCharABCWidthsI)
is not the same as Windows does. Have tried an couple of fonts
and the results are the subtly different. Before I get too carried
away wi
Tuesday, August 8, 2006, 1:48:51 AM, Alexandre Julliard wrote:
> Vitaliy Margolen <[EMAIL PROTECTED]> writes:
>>> GetCursorPos really needs to query X, because there's no guarantee
>>> that the app is processing X events, and even if we hack around that
>> What do you mean here? X will always send
On 8/7/06, James Liggett <[EMAIL PROTECTED]> wrote:
Turns out you're right, Mike. If I add a small (2 ms) sleep after the
dock event is sent, things work perfectly. :) But, this really strikes
me as a hack that doesn't stand a chance of getting into Wine. Is there
a better way to slow down the ex
> HolyLich wrote:
> > ChangeLog:
> > Fix rather unusual bug in LZ77 decompressor. We cannot use
memcpy
> > with overlapped areas because of unpredictable result. We must
copy
> > byte-by-byte.
> Why don't you use memmove instead? The man page for memcpy says:
> Use memmove(3) if th
On Tue, August 8, 2006 4:18 am, Alexandre Julliard wrote:
> I think that's a very small minority, what most people want is a real
> console in a separate window. We could certainly fall back to the
> curses backend when we aren't under X and can't create a user32
> window.
I used Wine for a while
HolyLich wrote:
> ChangeLog:
> Fix rather unusual bug in LZ77 decompressor. We cannot use memcpy
> with overlapped areas because of unpredictable result. We must copy
> byte-by-byte.
Why don't you use memmove instead? The man page for memcpy says:
Use memmove(3) if the memory areas do
Use this updated patch. I forgot to initialize some constants to zero and made
the diff against a wrong file because of which some crucial changes were missed.
Roderick
> Hi,
>
> This patch adds most missing shader capabilities. Some capabilitise are
> read from OpenGL but not everything is ma
On Mon, Aug 07, 2006 at 09:54:20PM +0100, Andrew Talbot wrote:
> Although I accept that my opinion may not be universally shared :-), I
> believe that it is better to turn -Wcast-qual on permanently and
> double-cast the appropriate return values of the relevant wide-string
> functions (strchrW(),
Eric Pouech <[EMAIL PROTECTED]> writes:
> also changing the default to user is a bad idea... especially for
> users wanting to run a text only win32 app from a linux console
> without X started
I think that's a very small minority, what most people want is a real
console in a separate window. We
Andrew Talbot <[EMAIL PROTECTED]> writes:
> In shlwapi/ordinal.c, FDSA_InsertItem(), I would like to change the third
> parameter's declaration from void * to const void *.
If there's no official prototype in the SDK then it's OK to fix it.
--
Alexandre Julliard
[EMAIL PROTECTED]
Vitaliy Margolen <[EMAIL PROTECTED]> writes:
>> GetCursorPos really needs to query X, because there's no guarantee
>> that the app is processing X events, and even if we hack around that
> What do you mean here? X will always send notifies to a window (or am I wrong
> here?) And in notify handler
Monday, August 7, 2006, 1:28:45 PM, Alexandre Julliard wrote:
> Vitaliy Margolen <[EMAIL PROTECTED]> writes:
>> Current dinput has lots of problems with lots of games for number of
>> different
>> reasons (and I'm talking about just mouse). To fix some(all) of them we need
>> to
>> move managing
49 matches
Mail list logo