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 of mouse
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 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]
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
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(),
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
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
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 to
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
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
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 notifies
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 with
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.
We cannot use
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 minority
On my
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 memcpy
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 Windows
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
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 wine like
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
without X
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
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.
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 now ,
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.
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 that
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
--
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 characters
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 instead of
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
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 you add
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
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 )
Ciao,
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]
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, the
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);
+
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)
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 great
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-pthread +
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 functions
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,
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
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]
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 to
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
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, then
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.
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
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 proper error
47 matches
Mail list logo
