Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [jgardou] 58650: [CMICPL] - This is a C++ module
by Timo Kreuzer 04 Apr '13

04 Apr '13

What about integrating set_cpp() into set_module_type, since that already handles a bunch of other things like UNICODE etc? Am 02.04.2013 22:04, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Tue Apr 2 20:04:31 2013 > New Revision: 58650 > > URL: http://svn.reactos.org/svn/reactos?rev=58650&view=rev > Log: > [CMICPL] > - This is a C++ module > > Modified: > trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt > > Modified: trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/wdm/audio/drivers/… > ============================================================================== > --- trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt [iso-8859-1] Tue Apr 2 20:04:31 2013 > @@ -1,3 +1,5 @@ > + > +set_cpp() > > add_library(cmicpl SHARED > cmicpl.cpp > @@ -10,6 +12,6 @@ > shell32 > msvcrt > kernel32 > - ntdll) > +) > > add_cd_file(TARGET cmicpl DESTINATION reactos/system32/drivers FOR all) > > >

1 0

Re: [ros-dev] [ros-diffs] [spetreolle] 58631: [NTOSKRNL] Fix all MM regressions.
by Aleksey Bragin 01 Apr '13

01 Apr '13

Please branch ReactOS 1.0 release, it's nearly ready it seems. Regards, Aleksey Bragin On 01.04.2013 2:17, spetreolle(a)svn.reactos.org wrote: > Author: spetreolle > Date: Sun Mar 31 22:17:23 2013 > New Revision: 58631 > > URL: http://svn.reactos.org/svn/reactos?rev=58631&view=rev > Log: > [NTOSKRNL] > Fix all MM regressions. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Sun Mar 31 22:17:23 2013 > @@ -7,6 +7,7 @@ > */ > > /* INCLUDES *******************************************************************/ > +/* So long, and Thanks for All the Fish */ > > #include <ntoskrnl.h> > #define NDEBUG > >

4 4

Blacklisted Tests in Testman
by victor martinez 01 Apr '13

01 Apr '13

Hi guyz! I've been reviewing our current Blacklisted suites at Testman. A lot of those unstable testsuites now are reliable, maybe because ReactOS stability has increased or better Winetests. The following blacklisted suites in the past should go into whitelist: Gdi32:SetMapMode. Now scores: 51-0 Gdi32:SetSysColors. Now scores: 44-0 Gdiplus:graphicspath. Now scores: 434-32 Gdiplus:region. Now scores: 803-6 Kernel32:pipe. Now scores: 33895-124 user32:trackmouseevent. Now scores: 177-12 wininet:urlcache. Now scores: 186-16 The following suites look reliable but from time to time they score different.So they should be kept as Blacklisted: user32:msg user32:win In the other hand two new candidates should go into Blacklisted: msxml3:domdoc ntdll:info Not bad, 7 to whitelist, 2 almost reliable and just 2 into Blacklist. My proposal is to update the lists and check during the following days that these new changes are reliable. If testsuites are a sign of stability, I should say..ReactOS is really stable. Bugged as always.But stable. :)

3 3

[ros-diffs] [hbelusca] 58632: [KERNEL32-CONSRV] Implement (Get/Set)ConsoleDisplayMode. [PSDK] Reorganize wincon.h a little bit and add few new flags from MSDN / Wine's wincon.h (which was up-to-date compared t...
by James Tabor 01 Apr '13

01 Apr '13

Hi, Here is a patch for the missing WM_NCRBUTTONUP. It's wine code. Well it breaks the mouse pointer set position and activates the system menu at the left upper corner. Looks like to many hack being made to bypass unimplemented functions. So stop doing it and fix it. I know~ locating all of them is a big head ache but remember what I always type, don't build code on top of hacks on hacks! James Index: win32ss/user/user32/windows/defwnd.c =================================================================== --- win32ss/user/user32/windows/defwnd.c (revision 58633) +++ win32ss/user/user32/windows/defwnd.c (working copy) @@ -22,6 +22,7 @@ LRESULT DefWndNCHitTest(HWND hWnd, POINT Point); LRESULT DefWndNCLButtonDown(HWND hWnd, WPARAM wParam, LPARAM lParam); LRESULT DefWndNCLButtonDblClk(HWND hWnd, WPARAM wParam, LPARAM lParam); +LRESULT NC_HandleNCRButtonDown( HWND hwnd, WPARAM wParam, LPARAM lParam ); void FASTCALL MenuInitSysMenuPopup(HMENU Menu, DWORD Style, DWORD ClsStyle, LONG HitTest ); void MENU_EndMenu( HWND ); @@ -1101,14 +1102,7 @@ } case WM_NCRBUTTONDOWN: - { - /* in Windows, capture is taken when right-clicking on the caption bar */ - if (wParam == HTCAPTION) - { - SetCapture(hWnd); - } - break; - } + return NC_HandleNCRButtonDown( hWnd, wParam, lParam ); case WM_RBUTTONUP: { Index: win32ss/user/user32/windows/nonclient.c =================================================================== --- win32ss/user/user32/windows/nonclient.c (revision 58633) +++ win32ss/user/user32/windows/nonclient.c (working copy) @@ -1035,6 +1035,14 @@ case HTBOTTOMLEFT: case HTBOTTOMRIGHT: { + /* Old comment: + * "make sure hittest fits into 0xf and doesn't overlap with HTSYSMENU" + * This was previously done by setting wParam=SC_SIZE + wParam - 2 + */ + /* But that is not what WinNT does. Instead it sends this. This + * is easy to differentiate from HTSYSMENU, because HTSYSMENU adds + * SC_MOUSEMENU into wParam. + */ SendMessageW(hWnd, WM_SYSCOMMAND, SC_SIZE + wParam - (HTLEFT - WMSZ_LEFT), lParam); break; } @@ -1073,6 +1081,41 @@ return(0); } +/*********************************************************************** + * NC_HandleNCRButtonDown + * + * Handle a WM_NCRBUTTONDOWN message. Called from DefWindowProc(). + */ +LRESULT NC_HandleNCRButtonDown( HWND hwnd, WPARAM wParam, LPARAM lParam ) +{ + MSG msg; + INT hittest = wParam; + + switch (hittest) + { + case HTCAPTION: + case HTSYSMENU: + if (!GetSystemMenu( hwnd, FALSE )) break; + + SetCapture( hwnd ); + for (;;) + { + if (!GetMessageW( &msg, 0, WM_MOUSEFIRST, WM_MOUSELAST )) break; + if (CallMsgFilterW( &msg, MSGF_MAX )) continue; + if (msg.message == WM_RBUTTONUP) + { + hittest = DefWndNCHitTest( hwnd, msg.pt ); + break; + } + } + ReleaseCapture(); + if (hittest == HTCAPTION || hittest == HTSYSMENU) + SendMessageW( hwnd, WM_SYSCOMMAND, SC_MOUSEMENU + HTSYSMENU, msg.lParam ); + break; + } + return 0; +} + VOID DefWndTrackScrollBar(HWND hWnd, WPARAM wParam, POINT Point) {

2 1

Status Meeting (March 2013)
by Aleksey Bragin 28 Mar '13

28 Mar '13

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 28th of March, 19:00 UTC. And that's tomorrow! The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the channel #meeting, or as Pierre says. Note that the IRC service will only be started shortly before the meeting. Your participation passwords will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). Regards , Aleksey Bragin

2 1

Fwd: Do NOT attempt to translate Book pages
by Zachary Gorden 28 Mar '13

28 Mar '13

---------- Forwarded message ---------- From: Zachary Gorden <drakekaizer666(a)gmail.com> Date: Thu, Mar 28, 2013 at 9:47 AM Subject: Do NOT attempt to translate Book pages To: ReactOS General List <ros-general(a)reactos.org>, ReactOS Web List < ros-web(a)reactos.org> The development guide is using Drupal "Books" as a way of organizing content. Drupal's localization has a major hole wherein books cannot be translated. As such, do NOT attempt to translate the development guide or any other content that uses books.

1 0

dev.reactos.org downtime
by Pierre Schweitzer 20 Mar '13

20 Mar '13

Hi, due to a maintenance on the server running them, the following services, Jira & Fisheye, will be down on the 20th of March 2013, starting at 9h30 CET. This means that the URLs: http://jira.reactos.org & http://code.reactos.org will be unreachable during the meantime. The server (and its services) should be back online before midday. We are sorry for the caused inconvenience. With my best regards, -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

1 3

Website translation problem
by Hermès BÉLUSCA - MAÏTO 18 Mar '13

18 Mar '13

Hello everybody ! About two or three weeks ago I translated in French the "ReactOS Downloads" page of our new website, and I was very surprised (and very angry, too) yesterday to see that it was turned back into English. According to the history it was done 4 days ago. Do you know what happened there, and how can this be reverted, if possible ? Thanks in advance, Hermès BÉLUSCA - MAÏTO

3 4

Yet another case of required Viista APIs...
by Timo Kreuzer 18 Mar '13

18 Mar '13

Hey, Amine informed me about yet another case of Vista APIs being used in wine code. This problem is going to increase and we need a solution, the sooner the better. My plan to address this is to use lower layer DLLs that contain the actual implementations, while the upper layer DLLs (kernel32, advapi32, msvcrt*) are just forwarders to the lower layer DLLs. The lower layer DLLs can contain whatever we want and wine dlls can link to them, while applications continue to see version consistent exports of the standard winapi dlls. For the exports of kernel32 and advapi32, a possible way to organize this is to follow MS API reorganisation on Win7, where these APIs are separated into the API-MS-Win-core-* etc dlls. In fact on Windows the implementation still stays in either Kernel32 or kernelbase and the API-MS-* dlls are just "virtual" dlls. How these APIs are organized can be seen here: http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html While from a logical perspective it might make sense to organize our implementations physically into these API DLLs, it comes with an overhead, since a bunch of extra dlls would need to be loaded and initialized on every process creation. We can avoid that by organizing our code in static libraries and merge them all together to 2 core dlls. The division like on Windows 7: kernelbase + kernel32 + advapi32, doesn't work for us, since kernel32 and advapi32 would still need to contain Vista+ APIs. Therefore I suggest to divide it into kernelbase.dll and kernelsup.dll, the latter containing the code that remains in kernel32 and advapi32 on Windows. Additional advantage: For the various CRT modules this can be done as well and would provide the benefit of having a single full featured CRT, which we can use from our own code, while still providing a (limited) version specific MSVCRT. And all other MSVCR* can forward to that core DLL, so we only need to load CRT code once. We would have another benefit, when we decide to implement Windows-Version specific API layers. These can be implemented as different versions of kernel32.dll etc. which export whatever they do on a specific Windows Version and contain version specific hacks, if required. These Version specific DLLs would be placed into subfolders on system32, having the loader use them, whenever a link/pif/registry setting asks for a specific (non-default) version. If someone has doubts and fears this could cause compatibility issues: Yes it could, but those only apply to extremely special system tools, which wouldn't work on Windows 7 either. Since we simply cannot be 100% compatible (unless we copy the MS binaries and call them ours), we need to make a compromise at certain points. We really have other problems than some crazy XP/2003 only system tools not working. The benefits far outweight the problems. Otherwise MS would never have fiddled with their DLLs. If someone prefers a different system of organization, I'd be happy to hear about it. If there are no objections, I will create a branch and work on that together with Amine. Thanks, Timo

3 2

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Release: build failed
by Pierre Schweitzer 17 Mar '13

17 Mar '13

Fix from r58530 deployed on release build slave. Next build will use it. On 17/03/2013 00:31, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/384 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1B > > Build Reason: The web-page 'force build' button was pressed by 'spetreolle': > > Build Source Stamp: 58530 > Blamelist: > > BUILD FAILED: failed compile_3 > > sincerely, > -The Buildbot > > -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev