As long as the CVS servers will be still available, or alternatively a
windows port of git is available that doesn't require thousands of other
tools...
- Thomas
Jan Zerebecki wrote:
> I hereby announce that with the upgrade of Bugzilla we will use
> Git for what the "bugzilla" cvs module is curr
Any feedback for why the patch hasn't been accepted?
- Thomas
Mike McCormack wrote:
> The version of the Windows Platform SDK that I'm looking at agrees
> with Wine.
This is how it is defined in the latest public platform SDK (Windows SDK
v6.0).
> There is also no reason to make a pointless change to the name of the
> argument, so this patch looks pointless a
Mike McCormack wrote:
> The version of the Windows Platform SDK that I'm looking at agrees
> with Wine.
This is how it is defined in the latest public platform SDK (Windows SDK
v6.0).
> There is also no reason to make a pointless change to the name of the
> argument, so this patch looks pointless a
Dmitry Timoshkov wrote:
> Then it should be changed to 'ULONG' or 'unsigned LONG' for compatibility
> with Win64.
It's also defined as "unsigned long" in the PSDK headers, not
ULONG/unsigned LONG.
- Thomas
Kai Blin wrote:
> Be aware that negotiate.c is a complete stub. If this function is
> changed, it should be changed like this:
I didn't intend to fix the logic or implementation, just the fact that
the structure was defined incorrectly. The fixes in the .c files are
just neccessary because the str
Rob Shearman wrote:
> IMHO, it would be better to see one patch that turns this warning off
> than ten patches that obfuscate the code
I absolutely appreciate this warning, IMO it's not code obfuscation.
- Thomas
MattK wrote:
> ChangeLog:
> Implementation of the MsiVerifyDiskSpace function
>
> dlls/msi/msiquery.c |32+-
> 1 files changed, 32 insertions(+), 0 deletions(-)
>
>
>
>
>
This patch doesn't look right.
1. GetD
Robert Shearman wrote:
> Thomas Weidenmueller wrote:
> If what you say is true about the PIPE_NOWAIT flag affecting this then
> it should be easy to fix.
The PIPE_NOWAIT flag is documented in the PSDK. In fact, named pipes are
handled slightly differently in ReadFile/WriteFile. Even if
Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise
the call to ConnectNamedPipe() will block the server thread if no
connection can be established, which causes the rpc server to dead-lock
during startup.
- Thomas
Index: dlls/rpcrt4/rpc_binding.c
Robert Shearman wrote:
> I have a patch that converts rpcrt4 over to using overlapped I/O, but I
> didn't submit it because the performance on Wine is horrible. When using
> overlapped I/O we have to perform several more server calls than when
> using non-overlapped I/O. Also, I think that this pat
Oops...this meant to go to wine-patches
Sorry about that.
- Thomas
Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise
the call to ConnectNamedPipe() will block the server thread if no
connection can be established, which causes the rpc server to dead-lock
during startup.
- Thomas
--
P.S.: Please let me know if there's something wrong with th
Peter Åstrand wrote:
> Disabling precompiled headers is the first thing I do when starting a
> new project. We are using Visual C++ 2003/7.1, which often fails if you
> are building from a network share (this is more or less unsupported
> though, see
> http://groups.google.com/groups?hl=en&lr=lang_
Robert Shearman wrote:
> What does NEWDEV do?
It's the driver installation wizard that pops up when the system detects
a new device.
> Will STI and STI_CI work with the GPL NEWDEV code? If so, I would submit
> them and then hope someone will come along and implement the necessary
> parts of NEWDE
@@ -1666,9 +1712,8 @@
*/
VOID SYSLINK_Register (void)
{
-WNDCLASSW wndClass;
+WNDCLASSW wndClass = {0};
-ZeroMemory (&wndClass, sizeof(wndClass));
wndClass.style = CS_GLOBALCLASS | CS_VREDRAW | CS_HREDRAW;
wndClass.lpfnWndProc = SysLinkWindowProc;
wndClass.
Mike McCormack wrote:
> +/*
> + * FIXME: 0 is a valid return from CreateFile
> + *but an invalid handle for the cabinet API
> + */
NULL cannot be a valid file handle. The very first handle in the handle
table has the value 0x4. Apart from that, the PSDK does
Thomas Weidenmueller wrote:
> Mike McCormack wrote:
>
>>+/*
>>+ * FIXME: 0 is a valid return from CreateFile
>>+ *but an invalid handle for the cabinet API
>>+ */
>
>
> NULL cannot be a valid file handle. The very
Juan Lang wrote:
> Sorry, I wasn't clear enough. I mean, _SHGetDefaultValue was already
> problematic for you, before I changed it to call wine_get_dos_file_name.
> The special cases portion of _SHGetDefaultValue don't apply to ROS, so
> they should be removed from your tree in any case.
Ah ok t
Juan Lang wrote:
> This function was already going to cause you trouble, as getenv("HOME")
> probably won't produce the correct results anyway. Just get rid of the
> special cases portion of _SHGetDefaultValue, they never apply to ROS.
Actually no as it is only used in shfldr_unixfs.c - which we
Juan Lang wrote:
> ChangeLog: use wine_get_dos_file_name rather than relying on
> GetFullPathNameW hack.
This is going to cause us poor ReactOS guys some trouble as that
kernel32 function neither exists in Windows nor ReactOS. Isn't there a
better solution?
- Thomas
=/library/en-us/intl/mui_set_thread_ui_lang.asp
Best Regards,
Thomas Weidenmueller
Thomas Weidenmueller wrote:
> The attached archive contains a stubbed objsel.dll and it's public
> header file objsel.h
Any comments why it got rejected?
Best Regards,
Thomas
James Hawkins wrote:
> I'm not exactly sure whether the LPVOID param of
> NtQueryInformationToken should be a BOOLEAN value or a DWORD like
> NumRestrictedSids (it isn't documented), but because we just want to
> know whether there exists at least one, the BOOLEAN does the trick
> until we know how
Shachar Shemesh wrote:
We have a minesweeper clone, after all, and I'm sure that the
reactos guys would appreciate it.
Actually, we've had a calculator since 11/2004, it's located in
subsys/system/cmd...
Best Regards,
Thomas
Dmitry Timoshkov wrote:
Since you didn't provide your test app I wrote my own (attached).
My comments are based on its results.
Well, since I was lazy I wrote it in Delphi and you'd have to enter
window handles yourself, I didn't attach it but since I keep being
accused of tainted sources I tr
Thomas Weidenmueller wrote:
4. It sets the last error code to ERROR_INVALID_MENU_HANDLE and
returns FALSE if the window handle is invalid
It's supposed to be ERROR_INVALID_WINDOW_HANDLE of course.
Thomas
Alexandre Julliard wrote:
Much worse, the class name is not a valid way of checking the Windows
type. You really need to send a message.
The results of the research I just did:
1. GetComboBoxInfo works with all handles, even with handles not
belonging to the calling process
2. It does NOT send
Alexandre Julliard wrote:
Log message:
Filip Navara <[EMAIL PROTECTED]>
Implement SB_SETBORDERS.
Just FYI: Win95, 98, 98SE, ME, NT4, NT5.0, NT5.1 and later do not
support this message even though MS Office might try to use them.
Best Regards,
Thomas
Dimitrie O. Paun wrote:
Why? There's little harm in supporting it, if some versions of the
real thing does. It's neither difficult, nor complex...
Because applications using them behave differently than on contemporary
versions of windows, just like the Local/GlobalSize issue - just not as
sev
Steven Edwards wrote:
Filip implemented this for me when I was testing Office97 under ReactOS and I never got around to
merging it to the ros tree.
SB_SETBORDERS does not exist in current versions of NT. It might be a
something from the old 3.x days. NT 5.0 and 5.1 for sure don't implement
the
Robert Shearman wrote:
How about this for ReactOS:
1. Create a replacement for include/wine/unicode.h that has the
following:
#define strlenW wcslen
#define strcpyW wcscpy
...
2. Apply a patch to each of the DLLs that currently link with
libunicode to instead link with ntdll or msvcrt.
Mike McCormack wrote:
If you don't build and test your patches against Wine, then don't
submit patches.
To my understanding it should build, but I unfortunately don't know what
each single build environment in the *nix world expects.
If you're trying to fix Reactos, then why don't you just fix y
Mike McCormack wrote:
Thomas Weidenmueller wrote:
-sz = strlenW(fmt) + 1;
+sz = wcslen(fmt) + 1;
libc and wine may have differing interpretations of what wchar_t.
Specifically, if -fshort-wchar is not used, wchar_t will be int, won't
it?
You'd be better off using lstrlenW() t
Sorry, this patch should compile.
Index: dlls/comctl32/progress.c
===
RCS file: /home/wine/wine/dlls/comctl32/progress.c,v
retrieving revision 1.36
diff -u -r1.36 progress.c
--- dlls/comctl32/progress.c11 Mar 2004 00:39:53 -
35 matches
Mail list logo
