Thanks Alexandre,
(BTW This createwindow / movewindow / draw to window is all occurring in
LBUTTONDOWN processing)
>> 1. MoveWindow doesn't update the DCEx clip_region region, and hence when
the
>> visible region changes, it is merged with the clip region and since there
is
>> no overlap the visi
Hello, I've been investigating defect 11562, and would appreciate some
thoughts on how to move forward...
Basically the application creates a new visible window (eg at 0,0 - 200,50)
and then draws in it by:
1. BeginPaint - This sets up the cliprgn to the whole window
2. Works out some sizes...
3.
>> Out of interest, what is meant by improving cmd.exe compatibility?
>Add support for all the cmd.exe switches and all the dos batch
>programming constructs?
I do track bugzilla for any cmd.exe issues regularly and aside from one
which I started work on, I don't know of any other batch issues.
Hiya,
Out of interest, what is meant by improving cmd.exe compatibility?
Jason
> Sending message to parent in tooltip code
> probably simply works around toolbar's broken behavior. In this case I
think
> I've identified a line in toolbar.c that fails to properly detect empty
string
> causing not appearing tooltips in Radmin. I'll try to submit another patch
with
> this fi
Hi Alexander,
> In the process of debugging I
> also determined that Windows doesn't seem to send this message to
> parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1
> normal installation). So I'm deleting this second call altogether and
> a conformance test for this situation
>Vitaliy
>Jason, please don't forget to cc wine-bugs when you reassign the bug.
Yeah, sorry... Its late here :-)
Out of interest, why don't we fix bugzilla to always enforce that userid (ie
if it gets removed, it automatically gets inserted back). I'm sure I'm not
the only one who forgets to do i
>I did a simple test here and it works, although I would like to test 2
>scnarios:
>a calls b which runs c
>a runs b runs c
I test that and found the previous email was very slightly wrong. I've coded
and sent my new patch into wine-patches as it corrects an identical trap to
what you were seeing
>I run a program which uses a *.bat files via "wine wineconsole
>--backend=user start program.bat" and this program runs well but after
>exit it program fails
The context should be valid as it was allocated a few lines higher up. To be
fair, there's no checking the LocalAlloc worked, but you wo
> We need to check context before than refer to context -> skip_rest .
But we have just referred to it higher up, and I didn't think it was valid
to get into this routine without a context.
Whats the problem you are trying to fix?
Jason
Out of interest, is there any way to get (read here 'write code for') the
wine's cmd.exe better integrated in the window you launch it from when it is
not in wineconsole mode.
For example, I would love to see cls clear the screen (I suppose I could
just launch 'clear'!), or command retrieval work
>> Does wine support this? I initially did it this way copying from
>> programs/msiexec
>Have a look at programs/uninstaller/main.c. Most likely you need to
>add -municode to APPMODE switches in Makefile.in.
Thanks Dmitry - 100% accurate, ie it was the -municode option. I'll submit
it as a patch
>> With git commit, you can use the --author switch
>> for example:
>> $ git commit -a --author "Jesse Allen <[EMAIL PROTECTED]>"
>Set "user.email" and "user.name" once with:
>git repo-config
Thanks! I found I'd already done it when installing git (must have made a
mistake and actually read the
>> Apologies for the size of this patch - I tried 3 or 4 ways of converting
>> chunks to unicode and always ended up duplicating huge bits of code and
>> having problems keeping track of duplicated variables that in the end I
>> did the lot in one go.
>You need TCHAR and friends to reduce the Patc
I'll double check later, but are you sure?
When I said I hadn't changed the patches, I meant the contents, but I had
done a git fetch, git rebase origin on the branch (and resolved the german
resource conflict) before resubmitting
Jason
>> Alexandre - How does the email address get into the change log, is it a
>> manual process or by hand. Ideally I'd like my main email address to be
the
>> one in the Changelog, rather than the gmail one which is purely to see if
it
>> resolves the problems I am having sending in patchsets - Is t
> int main (int argc, char *argv[])
> {
> + LPWSTR *argvW = NULL;
> + int args;
> + WCHAR *cmdW = NULL;
>If you will start using wmain() instead of main() you get unicode args for
>free, and that will help to avoid changing the command line parsing code.
Hi, Sorry for the delayed respons
>I believe what is happening is that the WineHQ mail server only accepts
>one SMTP connection at a time. This will probably reject half the
>messages sent by your mail server. Then they will get resent after a
>short period of time, but in batches so more messages will get rejected
>and then re
Apologies if this set arrives multiple times - I sent it all on Friday, and
the mailing list only shows 1,2 and 4. I sent then again tonight separately,
and immediately 3 went missing...
FYI I had this problem before the last hardware upgrade on winehq, and it
appeared fixed since then. I'll star
Whilst trying to convert cmd to Unicode, I've stumbled across a problem
which I either need to work around or fix, and I am not sure which.
WCHAR h[] = {'h','e','l','l','o','\0'};
WCHAR fmt[] = {':', '%', '1', '0','s',':','\0'};
char test[255];
WCHAR result[255];
sprintf(test, "'%10s'"
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Jason Edmeades <[EMAIL PROTECTED]> writes:
>
> > Note: This makes cmd.exe pull in msvcrt, but so does native
>
> Native doesn't have a choice, but we do. Unless there are good reasons
> to import msvcrt it's
Hiya,
Firstly, fantastic work, and its also explained to me something Eric said
which I didn't grasp...
>While preparing tests I found the 'user' backend of wineconsole works with
>WriteConsole/WriteFile correct (see test1 and test2), so I used it as etal.
>I figured out the main issue with cmd:
Detlef - Thanks... You can see what I added as an afterthough!
Eric, Thanks for taking the time to look at this and for your answers
>- ensure that all msvcrt's function needing to write unicode strings
>behave as follows:
>+ if the output handle is a console handle, use WriteConsoleW ->
>
(Meant to copy wine-devel as well, in case anyone else had any comments)
Subject: RE: locales, unicode and ansi with msvcrt (bug 8022)
>> My current plan, unless you have strong objections, is to make the
wprintf
>> msvcrt routines use WideCharToMultiByte on the string into the GetACP
>> codepage
>My current plan, unless you have strong objections, is to make the wprintf
>msvcrt routines use WideCharToMultiByte on the string into the GetACP
>codepage before being written out, and add file tests for this into the
>msvcrt testsuite
OK, A bit more testing and a bit more research starts to hel
>> Anything else I can test, or am I ok to put file tests into msvcrt test
>> buckets and allow the msvcrt unicode printf and friends to convert to
>> non-unicode using the console codepage before being output to the file
>> handle?
>Why don't you simply run native MSVCRT under +relay,+snoop and s
> > >What your test app is doing? It probably needs a test under Windows
> > >to see in which encoding (ANSI/OEM) a not unicode app should
> > >receive input via a pipe.
> >
> I meant things like 'dir >lst.txt', 'dir | sort > lst.txt'. 'dir' and
> 'sort' could be replaced by some external .exes
>What your test app is doing? It probably needs a test under Windows to
>see in which encoding (ANSI/OEM) a not unicode app should receive input
>via a pipe.
Sorry, just realized I had not addressed your last comment - Can you expand
on this sample test please and I'll do some experimenting. How d
>>> Apparently you need to use appropriate console output APIs directly
(that
>>> take into account the console input/output code page) instead of using
>>> MSVCRT APIs.
>>>
>> Unfortunately just using the wide console function will only help the
>> output to the screen, but as my test program sh
Hello,
Bug 8022 (http://bugs.winehq.org/show_bug.cgi?id=8022) has highlighted
something interesting which has me puzzled...
Basically lets take xcopy as an example command line application. It issues
messages to the screen using MSVCRT's wprintf(L"Unicode string") type
function
Wprintf -> vsnwpr
Further investigations shows the strstr bit is right, but the string I am
comparing with differs from windows. I have fixed up xcopy's output display
to mirror windows, and added that as a patch on the end of the resubmitted
patchset, as it is not directly related to the strstr bit
Regards,
Jason
>wouldn't it be nicer to use sizeof(copyCmd) here?
>if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) {
>There are many spots like this in wcmdmain.c
Yes... I'm blaming cut and paste as I didn't do all the wcmd ones :-)
Once I get all my xcopy patches in I want to continue my rework of th
Er... I have just managed to get git send-email set up and working, and it
would appear to be a feature of it. I do get one question which I answered n
to, perhaps I should anser yes to it and see what happens :-)
Anyone else using git send-email want to comment on how to avoid this?
Thanks!
Jaso
>> +if (wcsstr(copyFromUpper, pos->name) != NULL) {
>wcsstr() doesn't seem the right way to compare file names. You
>probably want to do a wcsicmp() of the end of the name or something
>like that.
It's not a file compare, it's a substring compare, eg if the file contains
just
Hiya,
If adding files for translation to a new directory (xcopy), can anyone
confirm of deny whether the following is all I need to do:
1. Add rsrc.rc containing (* - see below)
#include
#include "resources.h"
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
#include "En.rc
>> The installer I was fiddling with which caused me to write xcopy
>> actually uses (effectively) "cmd.exe /c xcopy". The fact I cant
>> run a wine supplied program from within another portion of wine was
>> what concerned me. I was trying to understand how wine locates it,
>> given that Creat
>However according to http://support.microsoft.com/kb/830473 : "the total
length
>cannot contain more than either 2047 or 8191 characters (as appropriate to
your
>operating system)"
I'd suggest changing it to MAXSTRING which is used throughout cmd to refer
to a 'big' string (of 8192 chars).
> Sage Line 50 already has a bug filed:
> http://bugs.winehq.org/show_bug.cgi?id=2956
> but we're hampered because there's no free demo for us to test.
>
You could register for a free trial cd?
http://www.sage.co.uk/considering/TryNow.aspx?tid=213114
As an FYI I sent the same patchset to another email account (not on my ISP,
just one of the free ones) and they all got through 4 times. It would start
to point to the wine-patches side of things, but I have never seen anyone
else have problems
Note I am not seeing any rejection emails either
Jas
>There does not seem to be a patch attached.
They followed
However - I sent all 9, and got immediate cc: copies returned to me for all
9. Browsing the patches through either gmame or wine-patches archives, only
shows 1,2,5 and 7 got through. This is the same as yesterday when a number
of the 19 I
>> diff --git a/programs/xcopy/Makefile.in b/programs/xcopy/Makefile.in
>> new file mode 100755
>All the files you create or modify are marked executable, could you
>please fix that?
Thanks for the heads up - I should have fixed it now, any problems please
let me know.
For reference, in case any
Hi Detlef, (again)
>Configure.ac - I included that because another 'regular' developer who
>added a dll recently added it (See:)
> http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html)
>I'll leave it in for that reason unless there's a big problem with it (I
>always thought you
Hi Detlef,
Firstly thanks for taking the time to comment on this...
Configure.ac - I included that because another 'regular' developer who added
a dll recently added it (See:)
http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html)
I'll leave it in for that reason unless there'
For reference:
'obviously'... adding this line to the makefile solves it
MODCFLAGS = -fno-builtin
(Copied from msvcrt\tests)
Jason
Hi,
Trying to convert my xcopy to Unicode proved simple on windows, but when
putting into wine has proved more interesting. Most of the wide string calls
are like lstrcmpW and they all work fine, but I really need the Unicode
equivalent to strchr and strrchr. As far as I can tell my only option is
Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of
XCOPY support. Does anyone have anything like this in their tree, or should
I try to knock something up?
I also assume it needs to be a separate program, not part of cmd.exe, to
mimic how windows does it?
Jason
Hello,
Its been a while since I did any wine work so thought I'd fix some bugs in
the cmd shell. I have come across a call which fails at compile time which I
was interested in knowing the 'right' way to solve
_splitpath appears to exist in ntdll, but none of the #includes I have tried
pick it up
>Again, the very first thing I'd suggest to do is to write a comprehensive
test
>case and send it to wine-patches with appropriate todo_wine statements to
make
>it pass. Then we could see exact steps which lead to a failure and could
start
>thinking of a possible fix.
Attached is a set of tests w
Hiya,
I've found my changes for this other bug, which also relates to the menu
code are wrong, and am trying to work out how to identify how windows does
it.
The problem is that there is a menu item with the same id as a popup menu.
In all the tests for all the calling functions, windows will re
>I attach it here now (bzip2'ed for once because of its size). Before
>submitting to wine-patches, I need some time to review the code once
>more for remnants of old way of thinking and to get rid of the
>IS__ITEM macro's ( or rename them to reflect the true intention).
Glancing through the p
>>The fact that you need to intorduce the txtWasAllocated flag suggests that
>>something is wrong. Also MF_OWNERDRAW certainly does not qualify as a
MF_STRING
>>alias. I'll try to play with your test case and see if I can find a better
fix.
The particular problem in the bug report was that the own
>You don't check SetMenuItemInfo return code after the above calls and I
very
>much suspect that they fail leading to the observed results.
Well spotted, thanks!
In the one case of string -> ownerdraw you are right, and I have now
modified the tests to flag a todo where this unexpectedly works on
Hi, How do you set breakpoints in 16 bit code, or cant you?
I can add in the winedos code a debugbreak at a particular point in time,
and I really want to step through some of the code following the return to
see why something is happening.
If I do, for example, break 0x1257:0x33f3 or *0x1257:0x
Ok, more information...
The routine (slightly modified to allow code before the return) is
ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc )
{
WNDCLASSEX16 wcex;
ATOM fred;
wcex.cbSize= sizeof(wcex);
:
Hiya,
I've got a weird issue and was wondering if anyone could advise on how to
resolve. (Comes from a 16bit windows app, but is a more general debugging
issue).
The problem is ...
1) If I run the application, it just hangs - no overly helpful information
at all.
2) If I add WINEDEBUG +relay trac
>How about an one line test case which simply does
>ret = DefWindowProc(hwnd, WM_MOUSEACTIVATE, 0, HTNOWHERE);
>ok(ret == MA_ACTIVATE, "expected to return MA_ACTIVATE\n");
Yes, the patch does that (via the window proc for the test, but it gets
forwarded on as its not handled). I didn't think of dr
Out of interest, does reversing this patch fix the wc3 fonts - If I recall
correctly if was the glTranslate calls which originally made the wc3 fonts
look correct, and I noticed in one of the patches Oliver changed them. He's
probably right, but just in case its worth a test
Try changing
glTransla
>LISTBOX_RemoveItem already does pretty much the same check, you should
>reuse that instead of duplicating it, you just need to remove the -1
>special case in there.
OK - Done, and changed the special case use by setcount appropriately
Changelog
Listbox delete string handling should validate the
I asked this a while ago and noone was too upset, but I am going to try to
spend some time slowly closing off some of the bugs which do not have enough
info in them to be reproduced, and have not had a response to a request to
see if the problem persists for a long time (e.g. 6 months).
I wont clo
> > Without removing the update region there's no way to step further in the
> > list, if I understand the problem correctly?
>
> Yes, but that's what needs to be fixed, we need to make progress even
> if the update region is not validated. We will then get a WM_PAINT in
> the main message loop, w
>the resulting patch that was attached to the bug do fix the problem. I'm
>not sure if the patch has been committed to CVS, but if it hasn't it
>probably should before the next wine release...
No it hasn't. The problem is that the fix does indeed solve the problem, but
also makes the behaviou
61 matches
Mail list logo
