Re: Move of the Bugzilla CVS to Git
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 currently used (if nothing unforeseen prevents this). This can be seen as a test for also moving our other remaining CVS modules. Anyone who has a problem with this should speak up now. Btw. the idea is to upgrade the server to Sarge shortly before the Bugzilla upgrade. Jan
Re: SHELL32: Implement the property sheet extension array functions (resend)
Any feedback for why the patch hasn't been accepted? - Thomas
Re: COMCTL32: Fix InitCommonControlsEx prototype
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 and wrong to me. While the name of the parameter is irrelevant, I picked the one used in the PSDK definition to make the implementation more readable when using the latest PSDK documentation. - Thomas
Re: COMCTL32: Fix InitCommonControlsEx prototype
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 and wrong to me. While the name of the parameter is irrelevant, I picked the one used in the PSDK definition to make the implementation more readable when using the latest PSDK documentation. - Thomas
Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype
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
Re: COMCTL32: Fix some gcc 4.1 warnings caused by windowsx.h macros.
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
Re: MSI: Implementation of the MsiVerifyDiskSpace function
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. GetDiskFreeSpace is called with a uninitialized buffer 2. GetDiskFreeSpaceEx should be used to support big partitions 3. missing error checks lead to bogus calculations 4. calculating whether there's enough space is completely wrong - Thomas
Re: [rpcrt4] Properly created named pipes
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 patch is incorrect because if you want to make the pipe overlapped then you have to fix up all of the ReadFile calls to take an OVERLAPPED structure. That's true, the ReadFile calls would also have to use the OVERLAPPED structure, but that would only work if the pipes were created with the PIPE_NOWAIT flag. Otherwise ReadFile and WriteFile will (or better should) be still synchronous regardless of the FILE_FLAG_OVERLAPPED flag. I'll shortly be starting a rewrite of part of the RPC server so that we can support more transports and I'll bear this bug in mind when I do it and I'll try to fix it. The solution I come to will probably involve a worker thread doing the ConnectNamedPipe. I hope the code gets fixed before the next wine release, because rpcrt4 currently deadlocks (or should deadlock) when starting a server (at least in ROS/Win). P.S. With WINE 0.9.5's implementation I noticed a massive thread leak on server-side (one thread per request?), is this a known bug? - Thomas
[rpcrt4] Properly created named pipes
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 === RCS file: /home/wine/wine/dlls/rpcrt4/rpc_binding.c,v retrieving revision 1.39 diff -u -r1.39 rpc_binding.c --- dlls/rpcrt4/rpc_binding.c 6 Sep 2005 10:26:14 - 1.39 +++ dlls/rpcrt4/rpc_binding.c 16 Jan 2006 23:00:15 - @@ -142,7 +142,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection-Endpoint) + 1); strcat(strcpy(pname, prefix), Connection-Endpoint); TRACE(listening on %s\n, pname); -Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, +Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname); @@ -166,7 +166,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection-Endpoint) + 1); strcat(strcpy(pname, prefix), Connection-Endpoint); TRACE(listening on %s\n, pname); -Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, +Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname);
Re: [rpcrt4] Properly created named pipes
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 the named pipe was created with FILE_FLAG_OVERLAPPED the connect, read write operations are still performed synchronously, unless the pipe was created with PIPE_NOWAIT. This is because named pipes are handled differently to other devices and it's up to the npfs driver to decide whether to perform the operation synchronously or not (by checking for PIPE_NOWAIT, which is internally mapped to FILE_PIPE_COMPLETE_OPERATION). So all in all, my patch in fact isn't quite correct because the PIPE_NOWAIT flag would be necessary. No. I'm pretty sure that the code works correctly and doesn't leak threads in Wine. If you can get a backtrace of the threads that shouldn't be around then I might be able to determine what is going wrong. Ok, then I guess it's the pipe implementation in ROS that causes this handle leak. - Thomas
[rpcrt4] Properly created named pipes
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 this patch or tell me why it was rejected. Otherwise I'm going to assume the fixes aren't appreciated or necessary because the implementation is considered mature and stable. Index: dlls/rpcrt4/rpc_binding.c === RCS file: /home/wine/wine/dlls/rpcrt4/rpc_binding.c,v retrieving revision 1.39 diff -u -r1.39 rpc_binding.c --- dlls/rpcrt4/rpc_binding.c 6 Sep 2005 10:26:14 - 1.39 +++ dlls/rpcrt4/rpc_binding.c 16 Jan 2006 23:00:15 - @@ -142,7 +142,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection-Endpoint) + 1); strcat(strcpy(pname, prefix), Connection-Endpoint); TRACE(listening on %s\n, pname); -Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, +Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname); @@ -166,7 +166,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection-Endpoint) + 1); strcat(strcpy(pname, prefix), Connection-Endpoint); TRACE(listening on %s\n, pname); -Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, +Connection-conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname);
Re: [rpcrt4] Properly created named pipes
Oops...this meant to go to wine-patches Sorry about that. - Thomas
Re: pch support
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=enlr=lang_enie=UTF-8oe=UTF-8selm=umBJLvIYDHA.2632%40TK2MSFTNGP09.phx.gbl). We've been using PCH with GCC for a long time in ReactOS, it's been working very well and reliable. Compiling ReactOS is *a lot* faster with PCH enabled. I don't really understand what the problem is. Nothing really should change except that all includes are grouped into one header file. It works the same with MSVC. The only difference is that dependency tracking needs to use one minor hack so it works properly with MSVC. Even ancient versions of GCC don't have a problem with it and should compile everything properly without any additional hacks (without PCH support of course). - Thomas
Re: wine's setupapi.dll / newdev.dll ?
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 NEWDEV or convince the ReactOS developers to re-license it. Both, newdev and setupapi are LGPL in ReactOS. - Thomas
Re: wine/dlls/comctl32 syslink.c
@@ -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.cbClsExtra= 0;
Is there a reason this change wasn't applied? Calling ZeroMemory is
slower and prevents certain optimizations by the compiler.
- Thomas
Re: MSI: Extract file directly to their target location
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 first handle in the handle table has the value 0x4. Apart from that, the PSDK doesn't mention it can ever return NULL. - Thomas Never mind, i noticed you corrected that in the following patch - Thomas
Re: MSI: Extract file directly to their target location
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 doesn't mention it can ever return NULL. - Thomas
Re: shellpath: use wine_get_dos_file_name
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
Re: shellpath: use wine_get_dos_file_name
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 don't port. - Thomas
Re: shellpath: use wine_get_dos_file_name
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 thanks. - Thomas
Re: Add KERNEL32.SetThreadUILanguage() stub
Andreas Mohr wrote: Hello all, this one is needed by XP's ping.exe and a reworked ReactOS version. Andreas Mohr This prototype is outdated. MS has documented this function in the meanwhile: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/mui_set_thread_ui_lang.asp Best Regards, Thomas Weidenmueller
Re: objsel: Add stubs for objsel.dll and objsel.h
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
Re: advapi32: Implement IsTokenRestricted
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 to handle TokenRestrictedSids. TokenRestrictedSids basically returns a TOKEN_GROUPS structure, the first member GroupCount indicates the number of restricted SIDs. Here's how i'd implement it: http://svn.reactos.com/viewcvs/trunk/reactos/lib/advapi32/token/token.c?rev=15958r1=15169r2=15958diff_format=h Best Regards, Thomas
Re: Calc
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
Re: combo - implement GetComboBoxInfo
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 tried to clarify this. The results of the research I just did: 1. GetComboBoxInfo works with all handles, even with handles not belonging to the calling process Most likely it's true. That's right, the reason I mentioned is that Christoph's implementation won't work because of different address spaces. Even if it points to the desktop heap (which ReactOS doesn't have yet) it's not guaranteed to work because it might have gotten mapped to another base address. So the implementation basically can't work this way. 2. It does NOT send a message, not even in the case it doesn't belong to the calling process True, but that might be an internal message catched by the message handling code. I of course only checked if a message would get dispatched to the window procedure of the owning thread. I don't know how windows handles it internally but I assume it reads the information from the desktop heap without reading the ptr using GetWindowLongPtr. If of course might send an internal message that only gets dispatched internally, but that'd be much overhead that could easily be a avoided. I forgot to mention that the function even works if the thread that owns the combo box hangs, it immediately returns the requested information. So sending a (internal) special message is not likely in my opinion. 3. It sets the last error code to ERROR_WINDOW_NOT_COMBOBOX and returns FALSE if the window handle isn't a combo box True. That might be accomplished by retrieving a window data pointer with GetWindowLongPtrW and testing some internal fields. That however only works for controls owned by a thread of the same process. 5. If the cbSize field of the COMBOBOXINFO structure doesn't match, it sets the last error code to ERROR_INVALID_PARAMETER and returns FALSE Poor Microsoft programmers even decided to fail if cbi.cbSize = sizeof(cbi) + 1, i.e. if it's enough space to store the result. That actually is common in the native api. Unless the buffer needed may vary depending on the content it returns, in most cases the size fields have to match. There are however a few exceptions I found by tests. One reason however might be to support different structure versions (.e.g. GetVersionEx()). So I don't think it's a bad thing(tm). Plus you might find bugs caused by using incorrect structure layouts. In Wine we can always send our custom WINE_GETCOMBOBOXINFO message if a window belongs to other process. Unless the window owner thread hangs, that then causes the caller to hang as well, which is not the case in windows. Sending a message with a timout would not work correctly if the system is too busy to process the request in time, even if the target thread doesn't hang. My test app shows that Windows correctly handles a superclassed window, so the thesis that it checks the class name is wrong. As I haven't tested that case, I guess you're right. Best Regards, Thomas
Re: combo - implement GetComboBoxInfo
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 a message, not even in the case it doesn't belong to the calling process 3. It sets the last error code to ERROR_WINDOW_NOT_COMBOBOX and returns FALSE if the window handle isn't a combo box 4. It sets the last error code to ERROR_INVALID_MENU_HANDLE and returns FALSE if the window handle is invalid 5. If the cbSize field of the COMBOBOXINFO structure doesn't match, it sets the last error code to ERROR_INVALID_PARAMETER and returns FALSE Because of 1. and 2. it's only possible to implement it in win32k unless one wants to determine the window owner, open a process handle and read the memory, a win32k implementation would be cleaner. Sure, win32k doesn't exist in wine so it's a task for wineserver. Just for the record: I wrote a very basic test application where I can enter a window handle, in combination with MS Spy++ it just takes 5 minutes to find out. A simple SetLastError(0) before the function call and a GetLastError() after it revealed the error codes. print everything to the screen and modify the cbSize parameter and you got all the information. If you insist I can attach the test application as a proof, but you have to enter window handles yourself and run MS Spy++. This information was gathered in less than 5 minutes by just testing, no reverse engineering or whatsoever was involved. However, since it might set the last error code to ERROR_WINDOW_NOT_COMBOBOX I expect it to check the window class name. Best Regards, Thomas
Re: combo - implement GetComboBoxInfo
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
Re: wine/dlls/comctl32 status.c
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
Re: comctl32 - SB_SETBORDERS
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 them. Even though Office tries to use them I oppose implementing it. Best Regards, Thomas
Re: comctl32 - SB_SETBORDERS
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 severe.
Re: get rid of unnecessary libunicode dependencies in some more places
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. That's actually how I did it, i wasn't aware that wine/unicode.h had this stuff for the ports. It works fine this way, anyways sorry for any inconvenience. Best Regards, Thomas
Re: get rid of unnecessary libunicode dependencies in some more places
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() than wcslen(), but that will be slow since it has an exception handler. Alexandre was talking about making an inline wine only version of lstrlenW() without the exception handler to solve that problem. Mike I'm sorry I don't know how these things are handled in wine. I basically made these patches so we don't depend on libunicode in reactos anymore as these things are supported by the native api. However, these functions should now basically either link to ntdll (or in the worst case to msvcrt). I can't even compile and link wine because I haven't managed to setup a build environment... it however works fine in reactos compiling with mingw. As I'm not familiar with libc and the other stuff wine depends on, I'd appreciate if someone who has better knowledge in this area to fix these patches. It'd however be great if these libraries can be built without libunicode because it's something obsolete for reactos (and libunicode has been bugging some of us devs). Best Regards, Thomas
Re: portability fixes (yet another attempt)
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 your own headers? Dmitry already pointed out that you can easily add some #define's or inline functions to achieve what you want. That seems like a better idea than submitting untested patches to wine-patches and hoping we're going to fix your problems for you. My attempt was to impove code sharing between both projects, and this is _exactly_ what Dmitry suggested. I'm not paid for doing this so if you don't even want to give it the slightest chance then I don't care at all, at least I would've helped out merging a not-101% perfect patch. Again, this doesn't fix reactos at all (not that it changed anything other than dependencies to libunicode), it rather fixes wine. If you trash it right now, I honestly don't care, then someone else can do it - or not... Best Regards, Thomas
Re: Support PBS_MARQUE for progress bars
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 - 1.36
+++ dlls/comctl32/progress.c25 Jul 2004 12:26:33 -
@@ -26,9 +26,6 @@
* Unless otherwise noted, we believe this code to be complete, as per
* the specification mentioned above.
* If you discover missing features, or bugs, please note them below.
- *
- * TODO
- * --support PBS_MARQUE
*
*/
@@ -59,7 +56,9 @@
/* Control configuration constants */
-#define LED_GAP2
+#define LED_GAP 2
+#define MARQUEE_LEDS 5
+#define ID_MARQUEE_TIMER 1
/***
* PROGRESS_Invalidate
@@ -156,51 +155,215 @@
{
if (dwStyle PBS_VERTICAL)
{
-INT old_top = rect.top;
-rect.top = rightBar;
-FillRect(hdc, rect, hbrBar);
-rect.bottom = rect.top;
-rect.top = old_top;
-FillRect(hdc, rect, hbrBk);
+if (dwStyle PBS_MARQUEE)
+{
+INT old_top, old_bottom;
+old_top = rect.top;
+old_bottom = rect.bottom;
+
+leds = rect.bottom - rect.top;
+ledMStart = (infoPtr-MarqueePos + MARQUEE_LEDS) - leds;
+
+if(ledMStart 0)
+{
+rect.top = max(rect.bottom - ledMStart, old_top);
+FillRect(hdc, rect, hbrBar);
+rect.bottom = rect.top;
+}
+if(infoPtr-MarqueePos 0)
+{
+rect.top = max(old_bottom - infoPtr-MarqueePos, old_top);
+FillRect(hdc, rect, hbrBk);
+rect.bottom = rect.top;
+}
+if(rect.top = old_top)
+{
+rect.top = max(rect.bottom - MARQUEE_LEDS, old_top);
+FillRect(hdc, rect, hbrBar);
+rect.bottom = rect.top;
+}
+if(rect.top = old_top)
+{
+rect.top = old_top;
+FillRect(hdc, rect, hbrBk);
+}
+}
+else
+{
+INT old_top = rect.top;
+rect.top = rightBar;
+FillRect(hdc, rect, hbrBar);
+rect.bottom = rect.top;
+rect.top = old_top;
+FillRect(hdc, rect, hbrBk);
+}
}
else
{
-INT old_right = rect.right;
-rect.right = rightBar;
-FillRect(hdc, rect, hbrBar);
-rect.left = rect.right;
-rect.right = old_right;
-FillRect(hdc, rect, hbrBk);
+if (dwStyle PBS_MARQUEE)
+{
+INT old_left, old_right;
+old_left = rect.left;
+old_right = rect.right;
+
+leds = rect.right - rect.left;
+ledMStart = (infoPtr-MarqueePos + MARQUEE_LEDS) - leds;
+rect.right = rect.left;
+
+if(ledMStart 0)
+{
+rect.right = min(rect.left + ledMStart, old_right);
+FillRect(hdc, rect, hbrBar);
+rect.left = rect.right;
+}
+if(infoPtr-MarqueePos 0)
+{
+rect.right = min(old_left + infoPtr-MarqueePos, old_right);
+FillRect(hdc, rect, hbrBk);
+rect.left = rect.right;
+}
+if(rect.right old_right)
+{
+rect.right = min(rect.left + MARQUEE_LEDS, old_right);
+FillRect(hdc, rect, hbrBar);
+rect.left = rect.right;
+}
+if(rect.right old_right)
+{
+rect.right = old_right;
+FillRect(hdc, rect, hbrBk);
+}
+}
+else
+{
+INT old_right = rect.right;
+rect.right = rightBar;
+FillRect(hdc, rect, hbrBar);
+rect.left = rect.right;
+rect.right = old_right;
+FillRect(hdc, rect, hbrBk);
+}
}
} else {
if (dwStyle PBS_VERTICAL) {
-while(rect.bottom rightBar) {
-rect.top = rect.bottom - ledWidth;
-if (rect.top rightMost)
-rect.top = rightMost;
-FillRect(hdc, rect, hbrBar);
-rect.bottom = rect.top;
-rect.top -= LED_GAP;
-if (rect.top =
