> From: Joerg Hoehle
>
> There's no mention of win95/98 in the attachment so I assume these
> were not included, or was that because there was no error?
Right, they were not included. I ran into some problems trying to attach
the .iso to those VMs and gave up. Win9x should die :-).
Ge.
There are quite a few failures in kernel32:locale on Vista+. The attached
patch tries to address those. Although any comment on the patch is
welcome, I'm particularly interested in feedback on the changes to
test_FoldStringW() (the part that starts at "@@ -2081,43 +2136,49 @@
static void test_FoldS
Hi Detlef,
> The mlang tests where reordered and now it crashed on
> on your Win98 machine with mlang.dll "4.72.3110.0".
>
>
http://test.winehq.org/data/675e6e93b1d2b4555d05e311764510abf763d21d/98_gvg-
w98/mlang:mlang.html
>
> Please send me the results for the test with:
> set WINETEST_REPORT_SU
Hi Nikolay,
>From: Nikolay Sivov [mailto:bungleh...@gmail.com]
>
>Ge van Geldorp wrote:
>>> From: Nikolay Sivov
>>>
>>> I've just prepared some simple MRU tests and I need test them on various
>>> native platfoms -
>>>
>>&g
> From: Nikolay Sivov
>
> I've just prepared some simple MRU tests and I need test them on various
native platfoms -
> tested only on xp sp2 so this one could be skipped.
>
> Could somebody do it?
Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get
crashes which were not there
Hi Joel,
> From: Joel Holdsworth
>
> Is there a reason why my patch (attached) hasn't been included yet? This
> is my first patch, so maybe someone can help me get it in.
You are aware that this patch introduces test failures on Windows 2000,
Vista and 2008? See
http://www.winehq.org/pipermail/wi
Hi Joel,
> From: Joel Holdsworth
>
> How do you deal with this problem, because presumably not every test
> contributor has VMs ready to confirm the behaviour of 95, 98, ME, 2000,
> XP and Vista. Do I submit the patch as-is, in the knowlege that it will
> cause failures in old windows? Presumably
Hi Paul,
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
>
> I've added these to the tests to show that Windows crashes. This is thus
> a test (although not run) for behavior. It just means that Windows
> doesn't check the input parameters thoroughly and so we shouldn't
> either. It wa
Hi Paul,
> From: Paul Vriens
>
> Why did you remove:
>
> -if (0) /* Crashes on Windows */
> -rc = pGetUserNameExW(NameSamCompatible, NULL, NULL);
> -
>
> The point of these additions was to show/document that Windows crashes
> when called like this.
Because Alexandre told me for an
> From: Austin English [mailto:austinengl...@gmail.com]
>
> Shouldn't these be win_skip's?
Another day that wasn't wasted because I learnt something new :-). Thanks,
resubmitted.
Ge.
Hi Paul,
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
> Ge van Geldorp wrote:
> > Try 2: Add buffer overflow tests
> >
> > Changelog:
> > secur32/tests: Add simple tests for GetUserNameExA/W()
> >
> > --
Hi Paul,
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
> > Ge van Geldorp wrote:
> > Try 2: Add buffer overflow tests
> >
> > Changelog:
> > secur32/tests: Add simple tests for GetUserNameExA/W()
> >
> >
From: "James Hawkins"
> On Fri, Jun 13, 2008 at 8:40 AM, Francois Gouget wrote:
> >
> > Someone asked to check which tests require interaction when running in
> > my Windows 2003 VM. However I cannot find the corresponding email (it
> > might have been on irc), so I'm sending this data to the lis
> From: Reece Dunn
> 2009/4/1 Ge van Geldorp :
> > Modify load_state only in ReadyState_Changed callback.
> >
> > Changelog:
> > ?Fix tests on Windows
> >
> > ---
> > ?dlls/mshtml/tests/htmldoc.c | ? 28 +++-
> > ?1 fil
Hi Jacek,
I've been investigating the failures in the urlmon ftp protocol tests that
show up on quite a few WinXP and higher machines. It seems to me that there
is an inherent race condition in the test.
The main thread waits in line 1822 until IInternetProtocolSink_Switch has
been called. It will
> From: Alexandre Julliard
>
> Paul Vriens writes:
>
> > I sent out an email earlier to ask if we should include more
> > information in the header of the report. We could use that
> > information, if this change will be accepted by AJ, to
> > limit the reporting only to boxes were we have a
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
>
> Paul Vriens wrote:
> > Juan Lang wrote:
> >> This removes the unused variables in the last version.
> >> --Juan
> >>
> >>
> >>
> -
> >> ---
> >>
> >>
> > I think that t
> From: Florian Köberle [mailto:flor...@fkoeberle.de]
>
> I ran the test 30 times using the same way you did without
> any failure.I used a vm with 1 CPU assigned too. Installed
> is a Windows XP with SP2.
>
> If I start the test twice so that two tests are running
> parallel then I get test f
> From: Ge van Geldorp [mailto:g...@gse.nl] On Behalf Of 'Florian Köberle'
Sorry, I messed up the headers. The previous message containing:
> BTW, this causes failures also with my own fix applied (althoug only a
> single failure instead of a bunch), so my own fix wasn
Florian,
> From: Florian Köberle [mailto:flor...@fkoeberle.de]
> How many cores do your processor have?
> I have a dual core which might make the difference.
I ran inside a VM that had 1 CPU assigned, so single core.
> How exactly do you execute the tests?
> I executed "../../../tools/runtest -
Hi Florian,
> From: Florian Köberle [mailto:flor...@fkoeberle.de]
> I think the main problem is that the thread might run
> parallel with some other test code.
>
> That is why I would suggest to wait for the thread to finish
> at the end of the test.
>
> I made a patch and attached it to this
> From: Reece Dunn [mailto:mscl...@googlemail.com]
>
> Do you know why you need to do a SetForegroundWindow there to
> make the tests succeed?
> Why is the input being sent to a different window?
> Why does it vary from platform-to-platform and machine-to-machine?
It's a timing issue. It doesn't
> From: Reece Dunn
>
> The Wine tests are now passing on a Windows XP machine
>
(http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group
_XP).
Actually, that was not the first time. On 20 Jan an XP machine passed:
http://test.winehq.org/data/e9d8c9f572998054b1f9c386ea81a3570
> From: Rob Shearman [mailto:robertshear...@gmail.com]
> > -error = RegCreateKeyEx(HKEY_CLASSES_ROOT, buffer, 0, NULL, 0,
> > KEY_SET_VALUE, NULL, &hkey,
> > +error = RegCreateKeyEx(HKEY_CURRENT_USER, buffer, 0, NULL, 0,
> > KEY_SET_VALUE, NULL, &hkey,
>
> This appears to have cau
Hi Henri,
> From: Henri Verbeet
> 2009/1/26 Ge van Geldorp :
> > Changelog:
> > d3d8/tests: Make tests pass on W2K8
> >
>
> >-ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL,
"IDirect3D8_CreateDevice failed with %#08x\n", hr);
> >+
> From: Austin English [mailto:austinengl...@gmail.com]
>
> Just do as we do in other tests:
> ok(GetLastError == Error1 /* Win9X */ ||
> Error2 /* Win2K */ ||
> Error3 /* WinXP */...
Not possible like that in this case since the error ch
Hi Jacek,
> From: Jacek Caban
> Subject: Re: urlmon/tests: Fix protocol tests when proxy is configured
>
> Ge van Geldorp wrote:
> > There is a large amount of proxy configurations possible on
> > Windows (WPAD, proxy.pac, fixed proxy values), which might behave
>
Hi James,
> From: James Hawkins [mailto:trui...@gmail.com]
>
> On Sun, Jan 18, 2009 at 3:38 PM, Ge van Geldorp wrote:
> > I see different estimated size values for Windows Installer 2.x and
> > 3.0 compared to 3.1 and later.
> >
>
> Please don't remove
> From: Dylan Smith [mailto:dylan.ah.sm...@gmail.com]
>
> On Fri, Jan 16, 2009 at 6:21 PM, Ge van Geldorp wrote:
> >
> > The riched20:editor test seems to be sending Ctrl-C
> > keystrokes to the wrong window on Windows. When running
> > "winetest -q"
> From: Paul Vriens [mailto:paul.vriens.w...@gmail.com]
>
> It looks like we've had exceptions on anything but XP and
> W2K3 for a long time.
> The exceptions (as reported on test.winehq.org) for XP and
> W2K3 started happening after the move to use winetest.exe
> from test.winehq.org.
I'm n
> From: Rob Shearman [mailto:robertshear...@gmail.com]
>
> 2009/1/12 Alexandre Julliard :
> > "Ge van Geldorp" writes:
> > >
> > > Changelog:
> > > NdrVaryingArrayUnmarshall() is broken on Windows
> >
> > If it's broke
Hi Rob,
Is WIDL supposed to generate code that's compatible with Windows RPCRT4.DLL?
Because it appears this is currently not the case. When you look at
http://test.winehq.org you'll see that the rpcrt4:server test fails on
pretty much any Windows version.
I investigated a bit more, the failures
> From: "Rob Shearman" <[EMAIL PROTECTED]>
>
> I believe that Windows terminates all threads on process
> exit
It does, see
http://blogs.msdn.com/oldnewthing/archive/2007/05/03/2383346.aspx
> I am trying to fix the bug 13408 related with ActiveSync, but
> i need some information of how and when appear the string
> {\style} on msi.
> I need some specification or url for begin.
Try http://msdn.microsoft.com/en-us/library/aa367524(VS.85).aspx (or search
for "Adding Controls and Text")
> From: Alexandre Julliard [mailto:[EMAIL PROTECTED]
>
> "Ge van Geldorp" <[EMAIL PROTECTED]> writes:
>
> > +if (! CopySid(SidSize, Sid, UserInfo->User.Sid))
> > +{
> > +HeapFree(GetProcessHeap(), 0, Sid);
> > +
> If I understand it correctly, there was an idea floating
> around that Ge van Geldorp had which was to auto generate the
> needed DIB engine code for certain color depths and functions
> so you would not have to implement the whole thing at once.
> if I remember correctly he
nGL setup:
> configure: WARNING: No OpenGL library found on this system.
I found the easiest way around this problem is to run configure using
--without-opengl. I doubt OpenGL is very useful at the moment for 64-bit
Wine anyway.
Ge van Geldorp.
> 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
unicated back to the author. Focusing solely on
review doesn't solve the problem of patches getting lost either.
Ge van Geldorp.
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.
Ge van Geldorp.
has to look at a patch twice before sending a reply. Not to
mention the time it costs the author. Shouldn't we be looking at the
productivity of everyone involved in Wine development and not just at
Alexandres productivity (although I acknowledge his special position)? I'm a
bit surpri
e list of pending patches, repeat.
> and how it would be different from what we are doing now.
It would make sure the author always receives some kind of feedback (either
from the bot, other developers or yourself) and would make sure patches
don't get lost (patches are automatically entered into the system and only
leave the system when the author withdraws them or when you make a final
decision).
Ge van Geldorp.
> From: Kai Blin
>
> Now, getting back to the patch submission process, you're talking about a
> patch management system. How would that look like, in your opinion. We
were
> discussing a couple of ideas, but in the end figured that most of those
would
> slow down the submission speed of patches
27;m not going to beg for an explanation. If
the Wine community can't be bothered to provide feedback I can't be bothered
to resubmit. After all, I've already scratched my itch, the bug is already
fixed in my tree, it's the communities loss, not mine.
Ge van Geldorp
on't disappear into the big
void) because Alexandre refuses to use it if it won't work in Emacs I'm
starting to wonder if people realise that the developers don't work for
Alexandre. He's a great Benovelent Dictator on technical issues, but in my
opinion only a Dictator on patch process management.
Ge van Geldorp.
I'm not sure what you want changed in
request_send_message to make it fit in 64 bytes?
Ge van Geldorp.
> From: Dmitry Timoshkov [mailto:[EMAIL PROTECTED]
>
> What exactly size is required then to avoid an assert?
This is the assert:
assert( sizeof(union generic_request) == sizeof(struct request_max_size) );
So the way the assert is written now "struct request_max_size" should have a
size exactl
> From: Dmitry Timoshkov [mailto:[EMAIL PROTECTED]
>
> "Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
>
> > --- a/include/wine/server_protocol.h
> > +++ b/include/wine/server_protocol.h
> > @@ -33,6 +33,9 @@ struct reply_header
> > struct req
> From: Boaz Harrosh
>
> Why not compile the all of Wine as PE with a GCC
> cross-compiler (MinGW), But for the 3 low level DLL's. In
> effect a ReactOS system and Makefiles (On a Linux kernel).
> Sure we will maybe want an alternate system for
> Builtin/Native, maybe different system folder
> From: Troy Rollo [mailto:[EMAIL PROTECTED]
>
> These are complications rather than impenetrable barriers.
> Wine->Wine (and Winelib App->Wine) calls would not need to go
> through the thunks. Many of the issues involved have already
> been dealt with for 16<->32 thunking and cross-process CO
ables. Some more info on the Wine64
wiki page http://wiki.winehq.org/Wine64
Ge van Geldorp.
> From: Alexandre Julliard [mailto:[EMAIL PROTECTED]
>
> Ge van Geldorp <[EMAIL PROTECTED]> writes:
>
> > Changelog:
> > Ge van Geldorp <[EMAIL PROTECTED]>
> > - Move handle indicator to upper 32 bits for Win64
>
> Why do you need this
dd -D_WIN64 to EXTRACFLAGS in dlls/Makedll.rules
and programs/Makeprogs.rules. This would mimic the behaviour of MSVC better
(it has _WIN64 predefined).
Ge van Geldorp.
> From: Ge van Geldorp [mailto:[EMAIL PROTECTED]
>
> Yes, this works fine, both with and without the change to
> include/msvcrt/string.h.
Sorry, I only tested dlls/msvcrt. When doing a full rebuild I get errors,
will investigate and let you know.
Ge.
h
> @@ -37,8 +37,6 @@
> #ifndef __WINE_MSVCRT_H
> #define __WINE_MSVCRT_H
>
> #include
> -#include
> -#include
>
> #include "windef.h"
> #include "winbase.h"
Yes, this works fine, both with and without the change to
include/msvcrt/string.h.
Best regards, Ge van Geldorp.
> diff --git a/include/msvcrt/string.h b/include/msvcrt/string.h
> index a821aa2..cc0b25e 100644
> --- a/include/msvcrt/string.h
> +++ b/include/msvcrt/string.h
> @@ -18,8 +18,18 @@ typedef unsigned short wchar_t;
> #endif
> #endif
>
> +#ifndef _MSC_VER
> +# ifndef __int64
> +# define __int64
nvestigate
something else please let me know.
Ge van Geldorp.
> From: Alexandre Julliard [mailto:[EMAIL PROTECTED]
>
> > Changelog:
> > Ge van Geldorp <[EMAIL PROTECTED]>
> > - Allow relocation on x86_64
>
> Is that really needed for Win64? And if so, shouldn't it use
> a more appropriate address?
The sta
> From: Eric Pouech [mailto:[EMAIL PROTECTED]
>
> this one is questionnable. Now that we have stackwalk64
> implemented (I'm not saying it works flawlessly on 64bit
> machines), it may be more interesting here to use the 64 bit
> version of the call back
That's actually a separate issue. The
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> > Except that dlls/ntdll/tests/generated.c was hand-modified.
>
> That would explain the rather large diff that I saw when I
> regenerated these tests :/
Sorry, I mixed up two files :( I have no evidence that
dlls/ntdll/tests/generated.c was
as it's
> done, in addition to posting it here. Note that the only way
> for me to test it would be to inspect the assembly output, as
> I'm not running 64 bit environment here (even though I'm on a
> 64 bit AMD processor). So it'd need testing from 64 bit
> people here at least.
I'm volunteering. I could also give you ssh access to a 64 bit environment.
Ge van Geldorp.
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> I think you're a bit behind the times:
>
>
http://cvs.winehq.org/cvsweb/wine/dlls/mapi32/mapi32_main.c.diff?r1=1.13&r2=
1.14
>
http://cvs.winehq.org/cvsweb/wine/dlls/user/user32.spec.diff?r1=1.114&r2=1.1
15
Indeed... Being on the European side
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> Ge van Geldorp wrote:
>
> > +SPEC_SRC32 = $(BASEMODULE).spec
> > +SPEC_SRC64 ?= $(SPEC_SRC32)
>
> Not sure we want seperate spec files. In any case, ?=
> doesn't look portable.
I don't want t
With the Win64 patches I just submitted to wine-patches, I'm able to
successfully build Win64-enabled Wine and execute the following 64-bit
winelib (winelib64? wine64lib?) application:
#include "windows.h"
int WINAPI WinMain(HINSTANCE hinst, HINSTANCE hprev, LPSTR cmdline, int
cmdshow)
{
DWORD
> From: Michael Jung
>
> What do people think about getting rid of shfldr_fs.c in the
> long run, in order to remove the redundancy? Does ReactOS use
> wine's shell32.dll? I guess it would be a problem for them?
Yes, we do and yes, it would be a problem... We don't import the
shfldr_unixfs.c fi
> From: Boaz Harrosh
>
> Hi! I was Just wondering. Is there at all a MinGW build
> system for the "Mozilla ActiveX control"? I guess not so the
> Question is:
> Any body knows what are the Main hurdles for that? Is that mainly COM
> TLB(s) related? or there are other problems?
I've built Firefo
> From: Dan Kegel
>
> The Mozilla ActiveX control download feature is cool and all, but
> until we repackage the sucker to include MSVCP60.DLL to fix
> http://bugs.winehq.org/show_bug.cgi?id=4064
> it's going to leave a lot of users scratching their heads as to why it
> keeps asking where its fi
> From: Vitaliy Margolen
>
> Saturday, November 26, 2005, 10:34:22 AM, Ge van Geldorp wrote:
> > As proposed here:
> > http://www.winehq.org/pipermail/wine-devel/2005-November/042583.html
> > I didn't receive any replies, which I'll take as a "no o
The PSDK defines some NTSTATUS values in both ntstatus.h and in winnt.h,
guarded by "#ifndef WIN32_NO_STATUS". Unfortunately, the definitions in the
PSDK are not equivalent. In ntstatus.h:
#define STATUS_xxx ((NTSTATUS) 0x)
In winnt.h:
#define STATUS_xxx ((DWORD) 0x)
The Wine he
ked another component,
widl, at Wine-20050628). Of course, our changes are available to Wine, I'd
be happy to work with one of you guys to get the Wine/ReactOS versions back
in sync. BTW, I'm the guy who usually merges the Wine changes into the
ReactOS tree after a Wine release.
Ge van Geldorp.
istry, I don't think
that's very likely (and it would be driver-dependent). That doesn't mean
that Wine can't store the info where it pleases (e.g. in the registry).
Ge van Geldorp.
is messed up. Fixing this allowed one of the todo
tests to succeeed.
Since looking at/tracing through the ShellExecuteEx code makes me scream in
agony every time, I would appreciate a review of the patch below.
Ge van Geldorp.
Index: dlls/shell32/cpanelfolder.c
Michael,
> I'm aware of this problem (though I didn't know about the
> exact numbers).
> There was a short discussion on wine-devel about it:
>
> http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html
I actually read the discussion but didn't make the connection when looking
at th
> From: Jesse Allen
>
> Quick question. Does React OS or DJGPP include a portable
> implementation of printf in msvcrt? I tried looking using
> your source browser but I could not tell where it is actually located.
It's in lib/crt/stdio
(http://svn.reactos.com/viewcvs/trunk/reactos/lib/crt/st
> From: Vijay Kiran Kamuju
>
> can we use the reactos implementation of the _mbsbtype?
> http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html
>
> Any ReactOS guys, please respond regarding the licensing of the above
> code?
Most of the code in our C Runtime originates from the DJGPP compiler
and Unicode implementations both ways (which
is kind of boring to write) on NT and skip the Unicode tests on Win9x.
Difficult stuff. I guess it's not an option to drop Win9x compatibility in
Wine .
Ge van Geldorp.
> From: Michael Jung
>
> SHBindToParent does not allocate a
> new PIDL for pidlLast, but returns a pointer to right
> location in pidl. This means you should not free it.
> There's still the problem that the shell folder isn't
> released in failure cases.
>
> Sorry, I didn't realize this.
I
e, but the shell
COM interfaces easily confuse me, so perhaps someone with a better understanding
of this stuff should look it over before I submit it to wine-patches.
Ge van Geldorp.
Index: dlls/shell32/pidl.c
===
RCS file: /home
is interest in this from the Wine side, I'd be happy to
provide assistance.
Ge van Geldorp.
I'm wondering what happened to the reworked widl patch at
http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't
been applied yet, does that mean there's no interest on the Wine side and I
can drop it from my TODO list?
Best regards, Ge van Geldorp.
ignificantly increase the chance of introducing
bugs and b) take too much of my time.
Maybe we can try to find a solution at WineConf?
Ge van Geldorp.
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> Ge van Geldorp wrote:
> > I have some shortcuts (created in Windows 2000) which only have 24
> > bytes of LOCATION_INFO, i.e. they are missing the dwFinalPathOfs
> > member. Also lots of shortcuts seem to have an
clude_next in Wine anyway (not every compiler supports it) I'm not going
to bother creating and testing a Wine patch for it. If I misjudged and there
is interest in this from the Wine side just let me know.
Ge van Geldorp.
Index: libs/wpp/ppl.l
> From: Ivan Leo Puoti
>
> Interestingly if you run the validation program on wine,
> and the version of windows you're emulating is prior to
> 2000 or is windows server 20003, you get a message saying
> a validation code couldn't be found, because of technical
> difficulties or because you're runn
mailing lists? If so, I can begin to understand why they banned
you, it gets _really_ annoying.
Ge van Geldorp.
character is an '\0'?
That sane implementation already exists as lstrcpynA/lstrcpynW in kernel32.
Ge van Geldorp.
> From: Dmitry Timoshkov
>
> "Steven Edwards" <[EMAIL PROTECTED]> wrote:
> > Its nice to note where the code came from. We always try to
> > do it in ReactOS so please credit Jim for his advpack function.
>
> It's sad to say that, but unfortunately that's not the case
> on the ReactOS side some
stubs from shlwapi.dll but then doesn't call them
in our usage scenarios.
I'm just a little bit surprised that stubs are ok for elf builds but not for
PE builds. It's not a big issue, I'm going to keep the code in ReactOS CVS
anyway .
Ge van Geldorp.
l instead
> of killing the app). You can view the lack of stubs support
> on PE as an encouragement to help us remove them from the
> spec files ;-)
Seems impossible for functions with unknown calling conventions and number
of parameters.
Ge van Geldorp.
> From: Jon Griffiths
>
> >Maybe the height/width at which to switch to the Rectangle drawing
> >algorithm needs a bit of tuning?
>
> Ge, Can you confirm this fixes the size for you? It works for
> me if I change my system font to a larger one...
Yes, this wo
Stubs declared in .spec files were not generated or exported for PE (MinGW)
builds. The patch below fixes that. It adds a new mode to winebuild, --pedll,
which generates the stubs.
Since it's a global change I'm sending it here for review first.
Ge van Geldorp.
Index: Mak
> From: Ge van Geldorp
>
> Ekush (http://www.ekush.com) published some binaries.
> Surprise, surprise, it looks like ReactOS very much (Check
> e.g. the radio buttons on the "Accept License" screen during
> 2nd stage setup).
> Some string searching in their bina
would be an improvement for large icon sizes, but I
don't think it's good for small icon sizes. See attached screenshot of
regedit. Maybe the height/width at which to switch to the Rectangle drawing
algorithm needs a bit of tuning?
Ge van Geldorp.
<>
> From: Alexandre Julliard
>
> Ge van Geldorp <[EMAIL PROTECTED]> writes:
>
> > Changelog:
> > Ge van Geldorp <[EMAIL PROTECTED]>
> > - GetFullPathName returns length without nul byte
>
> If it does that's a bug, it's supposed to c
> From: Dmitry Timoshkov
>
> "Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
>
> > I compared the results of CT_CTYPE1 GetStringTypeW()
> > between Windows 2000 and Wine and found a lot of differences
>
> That's a known incompatibility. Another one i
I compared the results of CT_CTYPE1 GetStringTypeW() between Windows 2000
and Wine and found a lot of differences (about 12000 of them). Nothing
really spectacular, e.g. codepoint 0x00b5 (MICRO SIGN) is classified
C1_PUNCT in Win2k and (C1_ALPHA | C1_LOWER) in Wine. I noticed that the Wine
table is
dlls/shell32/control.c contains some 16-bit code (function RunDLL_CallEntry16),
which I would like to separate out. I wonder if the attached patch is the
correct way to do that?
On Win2k export 122 is just a stub. Maybe it would be ok to turn our export 122
into an empty function too?
Ge van
ways seems to
read the input in 4096 byte chunks. Maybe you could enlarge InputBuffer
from 0x400 to 0x1000?
Ge van Geldorp.
> From: Tom
>
> Steven is USB by chance working in ROS?
> http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/w32api/include/ddk/
No, not yet. Some work is being done on USB but it will take a while
before support is finished.
Ge van Geldorp.
Last week I submitted the following patches:
http://www.winehq.org/hypermail/wine-patches/2004/06/0227.html
(dlls/commdlg "old style" file dialogs - take 2)
and
http://www.winehq.org/hypermail/wine-patches/2004/06/0276.html
(dlls/shell32 RestartDialog and RestartDialogEx)
Is there any particula
1 - 100 of 118 matches
Mail list logo
