- Ros-dev - ReactOS.org

examiner.com spam
by Aleksey Bragin 30 Mar '09

30 Mar '09

I unsubscribed email feedback(a)examiner.com, since it sends out everyone an email "thank you for your feedback". Sorry for inconvinience... People should think more when subscribing with such stupid autorepliers. WBR, Aleksey Bragin.

1 0

R40285
by Dmitry Gorbachev 30 Mar '09

30 Mar '09

Hi! Aleksey Bragin wrote: > Now each line of a debug log is printed synchronously DPRINT and DPRINT1 still call DbgPrint twice...

2 1

Re: [ros-dev] [ros-diffs] [jmorlan] 40280: Make command parsing in DoCommand/Execute more compatible with Windows
by Steven Edwards 29 Mar '09

29 Mar '09

Hi! On Sun, Mar 29, 2009 at 1:13 AM, <jmorlan(a)svn.reactos.org> wrote: > Author: jmorlan > Date: Sun Mar 29 09:13:35 2009 > New Revision: 40280 Would you mind taking a look at a cmd.exe bug Wax found? (I can't log in to bugzilla to file a bug report but I can quickly describe the issue) For some reason the CreateProcess call in in telnetd that spawns cmd.exe causes it to generate the error INVALID_HANDLE_VALUE. This issue does not happen with ReactOS telnetd on windows if you use Windows cmd.exe or if you use another console application on ReactOS such as ping.exe so we have isolated it to a cmd.exe problem. Telnetd is located in rosapps/sysutils/applications/telnetd Thanks! -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Where is MMVAD struct?
by Jun Koi 28 Mar '09

28 Mar '09

Hi, I searched for everywhere in the source code to see the definition of the MMVAD struct, but it is nowhere. So I suppose that we have something else (with different name) for that? If so, where is it? Thanks, Jun

4 4

rosapps
by Dmitry Chapyshev 27 Mar '09

27 Mar '09

Hi. I suggest to divide rosapps on two parts: 1) Components which are present in Windows (rosapps) 2) 3rd party components (3rdapps) In rosapps it is necessary to place all components without which the system can normally work (calc, hh, winhlp32, charmap, games and etc) In 3rdapps components which are not present in Windows (downloader, imagesoft and etc) will take places Such placing of components will allow to reduce compilation time as you can not compile not the modules necessary to you (rosapps and/or 3rdapps) Please tell your opinion on my proposition. -- WBR, Dmitry Chapyshev

15 32

Re : Re : Where is MMVAD struct?
by Sylvain Petreolle 27 Mar '09

27 Mar '09

Are you all receiving this automated reply when sending mail to ros-dev ML ? Kind regards, Sylvain Petreolle ________________________________ De : feedback(a)teamexaminer.com À : spetreolle(a)yahoo.fr Envoyé le : Vendredi, 27 Mars 2009, 11h20mn 09s Objet : RE: [ros-dev] Re : Where is MMVAD struct? Thank you for your feedback. Your email will be reviewed and processed accordingly. Sincerely, Examiner.com

1 0

Recent changes
by Colin Finck 26 Mar '09

26 Mar '09

Hello everybody, As you might have noticed, I recently did some changes to our Website stuff and Regression Testing System. Finally, it's time to show some results now: == BuildBot upgrade == Christoph reinstalled the latest version of BuildBot on our Swedish server today, since the previous server system was way too old for such an upgrade. This also had the uncomfortable side-effect of the BuildBot URL changing from http://reactos.org:8010 to http://build.reactos.org:8010, which most of you already seem to have noticed ;-) Sorry for not giving a note about this before. I thought I could just finish my stuff and then write this E-Mail explaining all changes, but as always, it took longer than expected :-/ == Crash Recovery in rosautotest and sysreg2 == In the recent days, I rewrote rosautotest in C++ for getting a more maintainable code. This update also added a Crash Recovery feature. Together with my updated version of sysreg2, we can now resume the testing process with the next test in case a specific test made ReactOS crash. == Web Test Interface == As we recently set up a new VM, which will eventually replace our current outdated www.reactos.org server, I finally had a playground for my third component of our testing system: The "testman" Web Interface. It is available at http://79.99.5.181/testman/ Features include finding specific test results through a getbuilds-like interface and comparing them. The Comparison feature can compare up to 5 results side-by-side and show the differences. Clicking on "Show only changed results" will only show the lines that have differences. You can also use Drag & Drop to move the column headers with all associated results to get the table to look like you want it. Clicking a test result will show details, including a log of this specific test. Just play around with it a bit and you should easily get to know about all features. Regarding Lone_Rifle's interface at http://reactos.nxserve.net: From what he told me, this one was only meant as a decentral alternative as long as we don't have "testman" on an official server. I'm saying this, so nobody gets the impression that I just wanted to extinguish his work with my implementation. If some people prefer Lone_Rifle's version over mine, it would just need to be adjusted to the new BuildBot URL and those people could still use it. Comments and suggestions are welcome of course. Not everything works perfect yet (e.g. the Debug Buildslave needs quite some time now as all tests are run), but it should be ready for you to try now. Best regards, Colin

5 8

Buildbot page moved..
by Timo Kreuzer 25 Mar '09

25 Mar '09

Hi, Since today, I cannot access the old buildbot page (http://reactos.org:8010/) anymore. I found the new URL (http://build.reactos.org:8010) in Colin's commit message. Was this an intentional change? I am asking because noone announced this change and some people might now wonder where the buildbot page is... Or am I the only one accessing it via my favourites? Is there even a link from the website (I couldn't find one)? Ah... and the old page had an icon, the new one doesn't. Timo PS: The nice regtest pages at http://reactos.nxserve.net also don't work anymore. They were very useful and I'd like to see them up again. So a) do we have something like that for our website (or in work)? Or b) can this one be fixed? (I forgot who owns it.)

5 5

Re: [ros-dev] [ros-diffs] [dgorbachev] 40181: Add "REACTOS Mm Hack of Doom" again (removed in r39723). Bug #4296.
by Matthieu Suiche 24 Mar '09

24 Mar '09

In a previous message you said: >Alex Ionescu wrote: >> This new hack directly slows down every context switch instead of every >> page fault -- the latter is a less important perf hit. > >This slowdown is very small, especially when comparing with other >"Hack of Doom". >I just want to see, is it the only raison d'être of that old hack or not. Could you explain the reason you add Mm Hack of Doom again if the slowdown is very small? Regards, -- Matthieu Suiche On Mon, Mar 23, 2009 at 1:56 AM, <dgorbachev(a)svn.reactos.org> wrote: > Author: dgorbachev > Date: Mon Mar 23 03:56:01 2009 > New Revision: 40181 > > URL: http://svn.reactos.org/svn/reactos?rev=40181&view=rev > Log: > Add "REACTOS Mm Hack of Doom" again (removed in r39723). Bug #4296. > > Modified: > trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S > trunk/reactos/ntoskrnl/ke/i386/trap.s > > Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/ctxswitch… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S [iso-8859-1] Mon Mar 23 03:56:01 2009 > @@ -389,9 +389,6 @@ > > /* Checking NPX, disable interrupts now */ > mov eax, [esi+KTHREAD_INITIAL_STACK] > - > - /* HACK */ > - mov ecx, [eax - 4] > cli > > /* Get the NPX State */ > > Modified: trunk/reactos/ntoskrnl/ke/i386/trap.s > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/trap.s?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/trap.s [iso-8859-1] Mon Mar 23 03:56:01 2009 > @@ -1924,10 +1924,14 @@ > NoFixUp: > mov edi, cr2 > > + /* REACTOS Mm Hack of Doom */ > + test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK > + je HandlePf > + > /* Enable interrupts and check if we got here with interrupts disabled */ > sti > - test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK > - jz IllegalState > + /* test dword ptr [ebp+KTRAP_FRAME_EFLAGS], EFLAGS_INTERRUPT_MASK > + jz IllegalState */ > > HandlePf: > /* Send trap frame and check if this is kernel-mode or usermode */ > >

2 1

Guidance
by മഹേഷ് മുകുന്ദന് | Mahesh M 24 Mar '09

24 Mar '09

Hi, I am doing a project on implementing VFS. Can anyone help me as a mentor? Since I'm more used to in Linux than in ROS code, it would be a great help if someone can help me through. I have gone through the ntos folder and read some documents and also the winvfs project that someone here suggested. I'm aware this is not a prime target in the ROS team, but once I complete this, I might be able to contribute to areas of higher priority. Hoping for a positive reply, Thank you. -- Mahesh M Happy hacking... , , / \ ((__-^^-,-^^-__)) `-_---' `---_-' `--|o` 'o|--' \ ` / ): :( :o_o: "-"

1 0

Re: [ros-dev] [ros-diffs] [mkupfer] 40173: - Disable "Back" in last page of syssetup, because it doesn't make any sense.
by Gabriel ilardi 22 Mar '09

22 Mar '09

This hides bug 2675. > Date: Sun, 22 Mar 2009 16:36:17 +0000 > To: ros-diffs(a)reactos.org > From: mkupfer(a)svn.reactos.org > Subject: [ros-diffs] [mkupfer] 40173: - Disable "Back" in last page of syssetup, because it doesn't make any sense. > > Author: mkupfer > Date: Sun Mar 22 19:36:16 2009 > New Revision: 40173 > > URL: http://svn.reactos.org/svn/reactos?rev=40173&view=rev > Log: > - Disable "Back" in last page of syssetup, because it doesn't make any sense. > > Modified: > trunk/reactos/dll/win32/syssetup/wizard.c > > Modified: trunk/reactos/dll/win32/syssetup/wizard.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/syssetup/wizard.… > ============================================================================== > --- trunk/reactos/dll/win32/syssetup/wizard.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/syssetup/wizard.c [iso-8859-1] Sun Mar 22 19:36:16 2009 > @@ -1990,22 +1990,13 @@ > { > case PSN_SETACTIVE: > /* Enable the correct buttons on for the active page */ > - PropSheet_SetWizButtons(GetParent(hwndDlg), PSWIZB_BACK | PSWIZB_FINISH); > + PropSheet_SetWizButtons(GetParent(hwndDlg), PSWIZB_FINISH); > > SendDlgItemMessage(hwndDlg, IDC_RESTART_PROGRESS, PBM_SETRANGE, 0, > MAKELPARAM(0, 300)); > SendDlgItemMessage(hwndDlg, IDC_RESTART_PROGRESS, PBM_SETPOS, 0, 0); > SetTimer(hwndDlg, 1, 50, NULL); > break; > - > - case PSN_WIZBACK: > - /* Handle a Back button click, if necessary */ > - KillTimer(hwndDlg, 1); > - > - /* Skip the progress page */ > - SetWindowLong(hwndDlg, DWL_MSGRESULT, IDD_DATETIMEPAGE); > - SetupData.UnattendSetup = FALSE; > - return TRUE; > > case PSN_WIZFINISH: > /* Handle a Finish button click, if necessary */ > _________________________________________________________________ Scopri le keyword più cercate della settimana! http://clk.atdmt.com/GBL/go/136430524/direct/01/

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 40142: - Reorganize NDIS code
by Aleksey Bragin 21 Mar '09

21 Mar '09

What was wrong with a previous naming convention? x0gone.c were supposed to contain implementation of functions, which became legacy in that major version of NDIS. Now you substituted it with x0stubs.c, which means it's going to contain stubs only. Was that intentionally? On Mar 21, 2009, at 12:29 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sat Mar 21 00:29:53 2009 > New Revision: 40142 > > URL: http://svn.reactos.org/svn/reactos?rev=40142&view=rev > Log: > - Reorganize NDIS code > > Added: > trunk/reactos/drivers/network/ndis/ndis/30stubs.c > - copied, changed from r40140, trunk/reactos/drivers/network/ > ndis/ndis/40gone.c > trunk/reactos/drivers/network/ndis/ndis/40stubs.c > - copied, changed from r40141, trunk/reactos/drivers/network/ > ndis/ndis/50gone.c > trunk/reactos/drivers/network/ndis/ndis/50stubs.c > - copied, changed from r40113, trunk/reactos/drivers/network/ > ndis/ndis/stubs.c > trunk/reactos/drivers/network/ndis/ndis/misc.c (with props) > Removed: > trunk/reactos/drivers/network/ndis/ndis/40gone.c > trunk/reactos/drivers/network/ndis/ndis/50gone.c > trunk/reactos/drivers/network/ndis/ndis/stubs.c

2 1

advapi self forwarding and kernel32 self imports
by Timo Kreuzer 21 Mar '09

21 Mar '09

Hi, 1.) Is there a reason, why some exports of advapi32 are forwarded instead of just set to the proper function? Forwarding is more work for the loader. 2.) kernel32 imports from itself. Which will probably lead to the same result as bug 4292. This is because the mingw lib imports from kernel32 and requires kernel32 library to be added afterwards. But rbuild likes to add mingw lib at the very end of the library list which requires adding kernel32 as a library to mingw_common to resolve imports. This should be fixed and mingw added as the very first library. I wonder if those 2 are even allowed on Windows, as both don't make sense. Timo

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 40115: rename DCs pDc_Attr to pdcattr, like in gdikdx. Make pdcattr alsways point to a DC_ATTR, either the user mode struct or the local part. Get rid of all the If (!pdcattr) pdcattr = &dc->Dc_Attr; That are not
by James Tabor 20 Mar '09

20 Mar '09

Hi All! Good to see it go, I had it in as a safeguard, and now we moved on to the next phase of the rewrite! Thanks Timo! James 8^D On Fri, Mar 20, 2009 at 4:47 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: > Oh, finally! ;) > > On Mar 20, 2009, at 7:51 AM, tkreuzer(a)svn.reactos.org wrote: > >> Author: tkreuzer >> Date: Fri Mar 20 07:51:26 2009 >> New Revision: 40115 >> >> URL: http://svn.reactos.org/svn/reactos?rev=40115&view=rev >> Log: >> rename DCs pDc_Attr to pdcattr, like in gdikdx. >> Make pdcattr alsways point to a DC_ATTR, either the user mode >> struct or the local part. Get rid of all the If (!pdcattr) pdcattr >> = &dc->Dc_Attr; That are not required anymore. >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 40115: rename DCs pDc_Attr to pdcattr, like in gdikdx. Make pdcattr alsways point to a DC_ATTR, either the user mode struct or the local part. Get rid of all the If (!pdcattr) pdcattr = &dc->Dc_Attr; That are not required anymore.
by Aleksey Bragin 20 Mar '09

20 Mar '09

Oh, finally! ;) On Mar 20, 2009, at 7:51 AM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Fri Mar 20 07:51:26 2009 > New Revision: 40115 > > URL: http://svn.reactos.org/svn/reactos?rev=40115&view=rev > Log: > rename DCs pDc_Attr to pdcattr, like in gdikdx. > Make pdcattr alsways point to a DC_ATTR, either the user mode > struct or the local part. Get rid of all the If (!pdcattr) pdcattr > = &dc->Dc_Attr; That are not required anymore.

1 0

[ros-diffs] [fireball] 40106: - Don't try to be smarter than Windows and don't copy background/foreground color from the original DC.
by James Tabor 20 Mar '09

20 Mar '09

Introduced in revision 6042. Over think was a norm back then.

1 0

header hack.... eeh workaround ;)
by Timo Kreuzer 17 Mar '09

17 Mar '09

Hi, I's like to suggest a workaround to the problem that we have to deal with both RECT and RECTL structures in win32k and as they are incompatible need to typecast in a lot of places. RECTL is what the DDI interface uses (almost) exclusively. While the NtGdi Interface and a lot of User structures also use RECT. Both structures are equal, but not compatible when it comes to assigning one to another, So we need to do all these nasty typecasts. My suggestion is adding some defines after the inclusion of windef.h: #define RECT RECTL #define PRECT PRECTL #define LPRECT LPRECTL #define LPCRECT LPCRECTL same for POINT and POINTL I'd like to hear your opinion on that. Thanks, Timo

2 2

Re: [ros-dev] [ros-diffs] [dgorbachev] 40014: Trying to fix boot breakage.
by Timo Kreuzer 14 Mar '09

14 Mar '09

dgorbachev(a)svn.reactos.org schrieb: > Author: dgorbachev > Date: Sat Mar 14 21:13:32 2009 > New Revision: 40014 > > URL: http://svn.reactos.org/svn/reactos?rev=40014&view=rev > Log: > Trying to fix boot breakage. > Try harder, please ;-P http://reactos.org:8010/builders/ReactOS_%28Debug%29/builds/13888/steps/tes… > Modified: > trunk/reactos/ntoskrnl/mm/freelist.c > trunk/reactos/ntoskrnl/mm/kmap.c > > Modified: trunk/reactos/ntoskrnl/mm/freelist.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/freelist.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/freelist.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/freelist.c [iso-8859-1] Sat Mar 14 21:13:32 2009 > @@ -942,6 +942,21 @@ > return NumberOfPagesFound; > } > > +static > +NTSTATUS > +MiZeroPageInternal(PFN_TYPE Page) > +{ > + PVOID TempAddress; > + > + TempAddress = MiMapPageToZeroInHyperSpace(Page); > + if (TempAddress == NULL) > + { > + return(STATUS_NO_MEMORY); > + } > + memset(TempAddress, 0, PAGE_SIZE); > + return(STATUS_SUCCESS); > +} > + > NTSTATUS > NTAPI > MmZeroPageThreadMain(PVOID Ignored) > @@ -989,7 +1004,7 @@ > PageDescriptor->Flags.Type = MM_PHYSICAL_PAGE_USED; > KeReleaseQueuedSpinLock(LockQueuePfnLock, oldIrql); > Pfn = PageDescriptor - MmPageArray; > - Status = MiZeroPage(Pfn); > + Status = MiZeroPageInternal(Pfn); > > oldIrql = KeAcquireQueuedSpinLock(LockQueuePfnLock); > if (PageDescriptor->MapCount != 0) > > Modified: trunk/reactos/ntoskrnl/mm/kmap.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/kmap.c?rev=400… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/kmap.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/kmap.c [iso-8859-1] Sat Mar 14 21:13:32 2009 > @@ -16,18 +16,23 @@ > /* GLOBALS *****************************************************************/ > > /* FUNCTIONS ***************************************************************/ > + > NTSTATUS > NTAPI > MiZeroPage(PFN_TYPE Page) > { > + PEPROCESS Process; > + KIRQL Irql; > PVOID TempAddress; > > - TempAddress = MiMapPageToZeroInHyperSpace(Page); > + Process = (PEPROCESS)KeGetCurrentThread()->ApcState.Process; > + TempAddress = MiMapPageInHyperSpace(Process, Page, &Irql); > if (TempAddress == NULL) > { > return(STATUS_NO_MEMORY); > } > memset(TempAddress, 0, PAGE_SIZE); > + MiUnmapPageInHyperSpace(Process, TempAddress, Irql); > return(STATUS_SUCCESS); > } > > > >

1 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 40008: Return to an old idea of MiMapPageToZeroInHyperSpace(), "fix" bug #4267.
by Timo Kreuzer 14 Mar '09

14 Mar '09

This breaks boot. http://reactos.org:8010/builders/ReactOS_%28Debug%29/builds/13880/steps/tes… dgorbachev(a)svn.reactos.org schrieb: > Author: dgorbachev > Date: Sat Mar 14 04:20:18 2009 > New Revision: 40008 > > URL: http://svn.reactos.org/svn/reactos?rev=40008&view=rev > Log: > Return to an old idea of MiMapPageToZeroInHyperSpace(), "fix" bug #4267. > > Modified: > trunk/reactos/ntoskrnl/mm/hypermap.c > > Modified: trunk/reactos/ntoskrnl/mm/hypermap.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/hypermap.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/hypermap.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/hypermap.c [iso-8859-1] Sat Mar 14 04:20:18 2009 > @@ -14,8 +14,11 @@ > > /* GLOBALS ********************************************************************/ > > +#define MI_ZEROING_PTES 255 > + > PMMPTE MmFirstReservedMappingPte; > PMMPTE MmLastReservedMappingPte; > +PMMPTE MmFirstReservedZeroingPte; > MMPTE HyperTemplatePte; > PEPROCESS HyperProcess; > KIRQL HyperIrql; > @@ -40,6 +43,8 @@ > MmFirstReservedMappingPte = MiAddressToPte(MI_MAPPING_RANGE_START); > MmLastReservedMappingPte = MiAddressToPte(MI_MAPPING_RANGE_END); > MmFirstReservedMappingPte->u.Hard.PageFrameNumber = MI_HYPERSPACE_PTES; > + MmFirstReservedZeroingPte = MiAddressToPte(MI_ZERO_PTE); > + MmFirstReservedZeroingPte->u.Hard.PageFrameNumber = MI_ZEROING_PTES; > } > > PVOID > @@ -134,38 +139,62 @@ > { > MMPTE TempPte; > PMMPTE PointerPte; > + PFN_NUMBER Offset; > PVOID Address; > - > + > // > // Never accept page 0 > // > ASSERT(Page != 0); > - > + > // > // Build the PTE > // > TempPte = HyperTemplatePte; > TempPte.u.Hard.PageFrameNumber = Page; > - > - // > - // Get the Zero PTE and its address > - // > - PointerPte = MiAddressToPte(MI_ZERO_PTE); > + > + // > + // Pick the first zeroing PTE > + // > + PointerPte = MmFirstReservedZeroingPte; > + > + // > + // Now get the first free PTE > + // > + Offset = PFN_FROM_PTE(PointerPte); > + if (!Offset) > + { > + // > + // Reset the PTEs > + // > + Offset = MI_ZEROING_PTES; > + KeFlushProcessTb(); > + } > + > + // > + // Prepare the next PTE > + // > + PointerPte->u.Hard.PageFrameNumber = Offset - 1; > + > + // > + // Write the current PTE > + // > + PointerPte += Offset; > + *PointerPte = TempPte; > + > + // > + // Return the address > + // > Address = (PVOID)((ULONG_PTR)PointerPte << 10); > - > - // > - // Invalidate the old address > - // > - __invlpg(Address); > - > - // > - // Write the current PTE > - // > - TempPte.u.Hard.PageFrameNumber = Page; > - *PointerPte = TempPte; > - > - // > - // Return the address > - // > return Address; > } > + > +VOID > +NTAPI > +MiUnmapPageInZeroSpace(IN PVOID Address) > +{ > + // > + // Blow away the mapping > + // > + MiAddressToPte(Address)->u.Long = 0; > +} > > >

1 0

Re: [ros-dev] [ros-diffs] [mkupfer] 39871: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details.
by Ged 13 Mar '09

13 Mar '09

Looking at the patch only this looks wrong to me. Assuming this is radio button it should use the marlett font. Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 04 March 2009 16:30 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39871: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details. Author: mkupfer Date: Wed Mar 4 19:29:57 2009 New Revision: 39871 URL: http://svn.reactos.org/svn/reactos?rev=39871&view=rev Log: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details. Modified: trunk/reactos/dll/win32/user32/windows/draw.c Modified: trunk/reactos/dll/win32/user32/windows/draw.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/d… ============================================================================== --- trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] Wed Mar 4 19:29:57 2009 @@ -1276,11 +1276,12 @@ yc = myr.top + SmallDiam - SmallDiam/2; i = 234*SmallDiam/750; i = i < 1 ? 1 : i; - myr.left = xc - i+i/2; + myr.left = xc - i/2; myr.right = xc + i/2; - myr.top = yc - i+i/2; + myr.top = yc - i/2; myr.bottom = yc + i/2; - Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye, xe, ye); + // if the start and the end point are equal, Pie() only draws a single line, so start one pixel lower + Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye+1, xe, ye); break; case DFCS_MENUCHECK:

4 3

Re: [ros-dev] [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests.
by Ged 13 Mar '09

13 Mar '09

It's not UserDrawIconEx which is hacky, it's just the code you added for detecting alpha pixels Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 13 March 2009 00:21 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests. Author: mkupfer Date: Fri Mar 13 03:20:48 2009 New Revision: 39997 URL: http://svn.reactos.org/svn/reactos?rev=39997&view=rev Log: - Add a hackfix comment for issue #4243 due to several requests. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 03:20:48 2009 @@ -1389,6 +1389,7 @@ } +/* FIXME: ReactOS specific hack */ BOOL UserDrawIconEx( HDC hDc,

1 0

Re: [ros-dev] [ros-diffs] [mkupfer] 39989: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details.
by Ged 13 Mar '09

13 Mar '09

This looks hacky -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org Sent: 12 March 2009 21:26 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [mkupfer] 39989: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details. Author: mkupfer Date: Fri Mar 13 00:25:49 2009 New Revision: 39989 URL: http://svn.reactos.org/svn/reactos?rev=39989&view=rev Log: Evgeniy Boltik <bstsoft AT narod DOT ru> - Fix draw icon with alpha in 32 bit. - See issue #4243 for details. Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… ============================================================================== --- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original) +++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 00:25:49 2009 @@ -1389,82 +1389,6 @@ } -#define STRETCH_CAN_SRCCOPY_ONLY - -#ifdef STRETCH_CAN_SRCCOPY_ONLY -void -FASTCALL -DoStretchBlt(HDC DcDest, int XDest, int YDest, int WidthDest, int HeightDest, - HDC DcSrc, int XSrc, int YSrc, int WidthSrc, int HeightSrc, - DWORD Rop3, BOOL Color) -{ - HDC DcStretched; - HBITMAP BitmapStretched; - HBITMAP OldBitmap; - - if (WidthDest == WidthSrc && HeightDest == HeightSrc) - { - NtGdiBitBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, Rop3, 0, 0); - } - else if (SRCCOPY == Rop3) - { - NtGdiStretchBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, - Rop3, 0); - } - else - { - DcStretched = NtGdiCreateCompatibleDC(DcSrc); - if (NULL == DcStretched) - { - DPRINT1("Failed to create compatible DC\n"); - return; - } - if (Color) - { - BitmapStretched = NtGdiCreateCompatibleBitmap(DcDest, WidthDest, - HeightDest); - } - else - { - BitmapStretched = IntGdiCreateBitmap(WidthDest, HeightDest, 1, 1, NULL); - } - if (NULL == BitmapStretched) - { - NtGdiDeleteObjectApp(DcStretched); - DPRINT1("Failed to create temporary bitmap\n"); - return; - } - OldBitmap = NtGdiSelectBitmap(DcStretched, BitmapStretched); - if (NULL == OldBitmap) - { - NtGdiDeleteObject(BitmapStretched); - NtGdiDeleteObjectApp(DcStretched); - DPRINT1("Failed to create temporary bitmap\n"); - return; - } - if (! NtGdiStretchBlt(DcStretched, 0, 0, WidthDest, HeightDest, - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, - SRCCOPY, 0) || - ! NtGdiBitBlt(DcDest, XDest, YDest, WidthDest, HeightDest, - DcStretched, 0, 0, Rop3, 0, 0)) - { - DPRINT1("Failed to blt\n"); - } - NtGdiSelectBitmap(DcStretched, OldBitmap); - NtGdiDeleteObject(BitmapStretched); - NtGdiDeleteObjectApp(DcStretched); - } -} -#else -#define DoStretchBlt(DcDest, XDest, YDest, WidthDest, HeightDest, \ - DcSrc, XSrc, YSrc, WidthSrc, HeightSrc, Rop3, Color) \ - NtGdiStretchBlt((DcDest), (XDest), (YDest), (WidthDest), (HeightDest), \ - (DcSrc), (XSrc), (YSrc), (WidthSrc), (HeightSrc), \ - (Rop3), 0) -#endif /* STRETCH_CAN_SRCCOPY_ONLY */ - BOOL UserDrawIconEx( HDC hDc, @@ -1482,7 +1406,6 @@ BITMAP bmpMask, bmpColor; COLORREF oldFg, oldBg; BOOL DoFlickerFree; - INT nStretchMode; SIZE IconSize; HDC hdcOff; @@ -1524,7 +1447,31 @@ when cxWidth or cyHeight is 0 */ if ((bmpColor.bmBitsPixel == 32) && (cxWidth != 0) && (cyHeight != 0)) { - bAlpha = TRUE; + SURFACE *psurfOff = NULL; + PFN_DIB_GetPixel fnSource_GetPixel = NULL; + INT x, y; + + //Find alpha into icon + psurfOff = SURFACE_LockSurface(hbmColor ? hbmColor : hbmMask); + if (psurfOff) + { + fnSource_GetPixel = DibFunctionsForBitmapFormat[psurfOff->SurfObj.iBitmapFormat].DIB_GetPixel; + if (fnSource_GetPixel) + { + for (x = 0; x < psurfOff->SurfObj.sizlBitmap.cx; x++) + { + for (y = 0; y < psurfOff->SurfObj.sizlBitmap.cy; y++) + { + bAlpha = ((BYTE)(fnSource_GetPixel(&psurfOff->SurfObj, x, y) >> 24) & 0xff); + if (bAlpha) + break; + } + if (bAlpha) + break; + } + } + SURFACE_UnlockSurface(psurfOff); + } } if (!diFlags) @@ -1608,8 +1555,6 @@ goto cleanup; } - nStretchMode = IntGdiSetStretchBltMode(hdcOff, STRETCH_DELETESCANS); - oldFg = IntGdiSetTextColor(hdcOff, RGB(0, 0, 0)); oldBg = IntGdiSetBkColor(hdcOff, RGB(255, 255, 255)); @@ -1622,7 +1567,7 @@ goto cleanup; } - DoStretchBlt(hdcOff, + NtGdiStretchBlt(hdcOff, (DoFlickerFree || bAlpha ? 0 : xLeft), (DoFlickerFree || bAlpha ? 0 : yTop), cxWidth, @@ -1633,7 +1578,7 @@ IconSize.cx, IconSize.cy, ((diFlags & DI_IMAGE) ? SRCAND : SRCCOPY), - FALSE); + 0); NtGdiSelectBitmap(hdcMem, hOldMem); } @@ -1642,7 +1587,7 @@ { hOldMem = NtGdiSelectBitmap(hdcMem, (hbmColor ? hbmColor : hbmMask)); - DoStretchBlt(hdcOff, + NtGdiStretchBlt(hdcOff, (DoFlickerFree || bAlpha ? 0 : xLeft), (DoFlickerFree || bAlpha ? 0 : yTop), cxWidth, @@ -1653,7 +1598,7 @@ IconSize.cx, IconSize.cy, ((diFlags & DI_MASK) ? SRCINVERT : SRCCOPY), - NULL != hbmColor); + 0); NtGdiSelectBitmap(hdcMem, hOldMem); } @@ -1729,7 +1674,6 @@ IntGdiSetTextColor(hdcOff, oldFg); IntGdiSetBkColor(hdcOff, oldBg); - IntGdiSetStretchBltMode(hdcOff, nStretchMode); Ret = TRUE;

2 1

Re: [ros-dev] rosapps
by WaxDragon 12 Mar '09

12 Mar '09

The only things I have habitually used in rosapps are ctm, ncftp, and download. I'd hate to see these go away. OTOH, there are quite a few things that l would consider "tests" in rosapps that could be moved. I think the argument that rosapps to long to build is crap. If you want to reduce the build time, ditch explorer. On Mar 12, 2009 11:02 AM, "Ged" <gedmurphy(a)gmail.com> wrote: I prefer this idea. I'd like to see rosapps removed completely and have all non essential stuff in trunk built via an rbuild variable (turned off by default) Ged. -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto: ros-dev-bounces(a)reactos.org] ... Behalf Of Thomas Bluemel Sent: 12 March 2009 14:17 To: ReactOS Development List Subject: Re: [ros-de...

2 1

Restructuring ReactOS
by Richard Campbell 10 Mar '09

10 Mar '09

Hi Guys, One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email. First Issue: Moving Target Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development. I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this. Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time. The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time. Second Issue: ROS Hacks I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it. Third Issue: Unit Tests While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically. Final Issue: Stop mixing user and kernel mode code. On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue. I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative! Thanks, Richard Campbell

6 7

Restructuring ReactOS...
by Richard Campbell 10 Mar '09

10 Mar '09

Restructuring ReactOS Hi Guys, One of the big issues I'm seeing with regards to ReactOS is the lack of overall structure. Currently ReactOS is loosely compatible with NT, 2000, XP, and even Vista. However, I believe that in order to achieve true stability and compatibility some changes should be implemented. I'm offering my opinion as a suggestion of how to structure things. While I believe that everyone should be allowed to have fun developing a great project, I believe that we can still do this, while maintaining a little more structure. Please feel free to comment on this email. First Issue: Moving Target Every since I first started watching ReactOS in 2001, I've noticed that ROS is suffering from moving target syndrome. Microsoft continually releases new versions of Windows each year, and ROS struggles to keep up. driver compatibility, app compatibility, etc. are all affected by this. Development is all over the place. If someone knows how to implement a vista API call, they do it. XP? Same, etc. The problem is this can cause compatibility issues with drivers and apps that do DLL hooking, as well as other oddball scenarios. In order to have truely 100% compatibility, we need to find a way to deal with this type of development. I propose picking a single target, Either Windows XP or Windows 2003, to serve as the trunk (I currently recommend Windows XP since it is compatible with nearly everything out there.) All core development will be based around this. Our releases will be based around this. Branches will be created for Windows 7, Windows Server 2008, and Windows Vista specific code. Any platform specific code will go into this branch. Any code that is no longer valid will be removed from this branch. This allows multiple versions of Windows to be targetted at the same time. The trunk will continue on it's path until a) It is 90-100% compatible with most apps/drivers or b) XP/2003 become so old and out of date they aren't used by anyone anymore, similar to the way 98/NT4/2000 are now. If either of those scenarios happen, we vote to switch to a different branch. We should avoid switching to the most cutting edge version of windows, however, and instead focus on the most widely used version at the time. Second Issue: ROS Hacks I've noticed that a lot of times, people implement app specific hacks in ROS, or worse, they implement ROS specific hacks in different apps. Both of these are very bad practices. Instead of doing either of these, I'd recommend discussing the problems you find with the other developers over the mailing list. For instance, if app XYZ is working, rather than submitting a hackish patch to get it to work, find the root cause of the issue, and solve it there or ask for help to solve it. Third Issue: Unit Tests While there are winetests as well as other small tests, ReactOS (That i know of, unless it's in a seperate repo) does not have an official testing framework. Each developer here should take some time out and write a test for every api currently supported by windows, make it pass on Windows, and then commit it to SVN. If we all write tests, This will help identify bugs in ROS vs Windows. Low level tests are ESPECIALLY needed. Our driver compatibility currently sucks, and it's getting worse every day. Unit testing for driver specific APIs and the HAL would help improve ROS dramatically. Final Issue: Stop mixing user and kernel mode code. On occasion i see developers use ReactOS specific kernel mode code in userland. This process should be avoided. All ROS apps should work on both Windows and ROS, and should not contain any ROS specific checks,etc. This goes back to the second issue. I look forward to hearing your responses to my opinion, and I hope that we can work on getting at least some of these opinions implemented so that we may build a truly great Microsoft Windows Compatible Alternative! Thanks, Richard Campbell

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev