Ros-dev July 2008

ros-dev@reactos.org

24 participants
34 discussions

Haiku and ReactOS "Pair Up" at LinuxWorld Expo 08

by James Tabor

Hi! A show is coming up and we need to look good. Haiku looks good and it has networtking and draws objects very well. Please check our drawing with test apps and look at networking and see where we are on hardware support. I know there are bugs maybe by August 4th we can get back some basic networking with hardware. PCI n2k? or FET? KPANIC! James

16 years, 5 months

Re: [ros-dev] [ros-diffs] [cfinck] 34558: Commit my test suite I used for verifying the behaviours of wctomb, wcstombs and WideCharToMultiByte and writing the reimplementations for ReactOS on request of Stefan

by Aleksey Bragin

Maybe it's worth adding these tests to msvcrt test suite and submit to Wine? WBR, Aleksey Bragin. On Jul 17, 2008, at 2:08 AM, cfinck(a)svn.reactos.org wrote: > Author: cfinck > Date: Wed Jul 16 17:08:58 2008 > New Revision: 34558 > > URL: http://svn.reactos.org/svn/reactos?rev=34558&view=rev > Log: > Commit my test suite I used for verifying the behaviours of wctomb, > wcstombs and WideCharToMultiByte and writing the reimplementations > for ReactOS on request of Stefan

16 years, 5 months

Re: [ros-dev] [ros-diffs] [pschweitzer] 34524: Updated kernel exports to match with r34517

by Alex Ionescu

Please remember to fix exports for other architectures as well. We really need a spec file for the kernel... Best regards, Alex Ionescu On Tue, Jul 15, 2008 at 6:56 AM, <pschweitzer(a)svn.reactos.org> wrote: > Author: pschweitzer > Date: Tue Jul 15 08:56:54 2008 > New Revision: 34524 > > URL: http://svn.reactos.org/svn/reactos?rev=34524&view=rev > Log: > Updated kernel exports to match with r34517 > > Modified: > branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def > > Modified: branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def > URL: http://svn.reactos.org/svn/reactos/branches/pierre-fsd/ntoskrnl/ntoskrnl_i3… > ============================================================================== > --- branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def [iso-8859-1] (original) > +++ branches/pierre-fsd/ntoskrnl/ntoskrnl_i386.def [iso-8859-1] Tue Jul 15 08:56:54 2008 > @@ -182,7 +182,7 @@ > @ExiReleaseFastMutex@4=@ExReleaseFastMutex@4 > @ExiTryToAcquireFastMutex@4=@ExTryToAcquireFastMutex@4 > FsRtlAcquireFileExclusive > -;FsRtlAddBaseMcbEntry > +FsRtlAddBaseMcbEntry > FsRtlAddLargeMcbEntry > FsRtlAddMcbEntry > FsRtlAddToTunnelCache > @@ -216,7 +216,7 @@ > FsRtlFindInTunnelCache > FsRtlFreeFileLock > FsRtlGetFileSize > -;FsRtlGetNextBaseMcbEntry > +FsRtlGetNextBaseMcbEntry > FsRtlGetNextFileLock > FsRtlGetNextLargeMcbEntry > FsRtlGetNextMcbEntry > @@ -224,7 +224,7 @@ > FsRtlIncrementCcFastReadNotPossible > FsRtlIncrementCcFastReadResourceMiss > FsRtlIncrementCcFastReadWait > -;FsRtlInitializeBaseMcb > +FsRtlInitializeBaseMcb > FsRtlInitializeFileLock@12 > FsRtlInitializeLargeMcb > FsRtlInitializeMcb > @@ -240,10 +240,10 @@ > FsRtlIsPagingFile > FsRtlIsTotalDeviceFailure > FsRtlLegalAnsiCharacterArray=_FsRtlLegalAnsiCharacterArray > -;FsRtlLookupBaseMcbEntry > +FsRtlLookupBaseMcbEntry > FsRtlLookupLargeMcbEntry > -;FsRtlLookupLastBaseMcbEntry > -;FsRtlLookupLastBaseMcbEntryAndIndex > +FsRtlLookupLastBaseMcbEntry > +FsRtlLookupLastBaseMcbEntryAndIndex > FsRtlLookupLastLargeMcbEntry > FsRtlLookupLastLargeMcbEntryAndIndex > FsRtlLookupLastMcbEntry > @@ -267,7 +267,7 @@ > FsRtlNotifyReportChange > FsRtlNotifyUninitializeSync > FsRtlNotifyVolumeEvent > -;FsRtlNumberOfRunsInBaseMcb > +FsRtlNumberOfRunsInBaseMcb > FsRtlNumberOfRunsInLargeMcb > FsRtlNumberOfRunsInMcb > FsRtlOplockFsctrl > @@ -281,21 +281,21 @@ > FsRtlRegisterFileSystemFilterCallbacks > FsRtlRegisterUncProvider > FsRtlReleaseFile > -;FsRtlRemoveBaseMcbEntry > +FsRtlRemoveBaseMcbEntry > FsRtlRemoveLargeMcbEntry > FsRtlRemoveMcbEntry > FsRtlRemovePerFileObjectContext > FsRtlRemovePerStreamContext > -;FsRtlResetBaseMcb > +FsRtlResetBaseMcb > FsRtlResetLargeMcb > -;FsRtlSplitBaseMcb > +FsRtlSplitBaseMcb > FsRtlSplitLargeMcb > FsRtlSyncVolumes > FsRtlTeardownPerStreamContexts > -;FsRtlTruncateBaseMcb > +FsRtlTruncateBaseMcb > FsRtlTruncateLargeMcb > FsRtlTruncateMcb > -;FsRtlUninitializeBaseMcb > +FsRtlUninitializeBaseMcb > FsRtlUninitializeFileLock@4 > FsRtlUninitializeLargeMcb > FsRtlUninitializeMcb > >

16 years, 5 months

[ros-diffs] [mpiulachs] 34223: - hackfix unbootable image (part 1/2)

by James Tabor

Hi, Does "make install" work for you by any chance? I get this: bash-3.1# make install mingw32-make: *** No rule to make target `boot/bootdata/i386/hivecls.inf', needed by `reactos/system32/config/default'. Stop.

16 years, 5 months

Re: [ros-dev] when will I return Magnus Olsen aka GreatLord (gedmurphy)

by Cameron Gutman

I tested some of GreatLord's regressions and I can see how Aleksey would get angry about all the fixes he has to do to GreatLord's code, but GreatLord has fixed a whole lot more than he has broken and Fireball chasing around 'if (Foo == FALSE)' and changing it to 'if (!Foo)' seems pointless. We've got plenty of code formatted as 'if (Foo == FALSE)' in the kernel that works great. Aleksey is making more work for himself by making needless changes to GreatLord's code. All that is needed is someone with commit access that is willing to correct GreatLord's comments. I don't have a problem with finding a regression of GL's here or there. Sure he should test his code before committing but as far as breakages, but his code usually correct and all coders create breakages one time or another.

16 years, 5 months

The ABCs of DCEs

by James Tabor

Hi, I did some research and found something very interesting. I kept thinking about the last DCE commit (34289). I had a guess and modified the user32 test for wine. The results are very clear. Apparently windows does not care for which dc is returned if it is Cached or a bug since hWnd is the same. When DCX_NORESETATTRS is set when calling GetDCEx; "Does not reset the attributes of this DC to the default attributes when this DC is released." We do this correctly in ReleaseDC. So the next GetDCEx should keep the original DC data for the next set of tests. Wine test is completely incorrect. So all of our DCE attributes code is good to go. Windows did not pass the modified "Same hDC" check and we still fail the "ROP" check. See the windows results at the end of this message. //////// Changes to user32/tests/dce.c: ReleaseDC( hwnd_cache, hdc ); hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE | DCX_NORESETATTRS ); <------ DCX_NORESETATTRS rop = GetROP2( hdc ); ok( rop == def_rop || rop == R2_WHITE, "wrong ROP2 %d after release\n", rop ); ReleaseDC( hwnd_cache, hdc ); + old_hdc = hdc; hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE ); rop = GetROP2( hdc ); + ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc ); ok( rop == def_rop, "wrong ROP2 %d after release\n", rop ); ReleaseDC( hwnd_cache, hdc ); /* test own DC */ //////// //////// Results from XP: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. Z:\>e: E:\>user32_crosstest dce dce.c:79: Test failed: didn't get same DC F5010866/FC0107E0 dce: 77 tests executed (0 marked as todo, 1 failure), 0 skipped. E:\> /////////

16 years, 5 months

Re: [ros-dev] [ros-diffs] [jimtabor] 34276: GetLastActivePopup is still unimplemented, we return the current window handle if it is valid.

by Aleksey Bragin

It would make sense to add a WARN there or something like that, so it could be seen that it is halfplemented only. WBR, Aleksey. On Jul 3, 2008, at 11:17 AM, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Thu Jul 3 02:17:32 2008 > New Revision: 34276 > > URL: http://svn.reactos.org/svn/reactos?rev=34276&view=rev > Log: > GetLastActivePopup is still unimplemented, we return the current > window handle if it is valid. > > Modified: > trunk/reactos/dll/win32/user32/windows/window.c > > Modified: trunk/reactos/dll/win32/user32/windows/window.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ > user32/windows/window.c?rev=34276&r1=34275&r2=34276&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/win32/user32/windows/window.c [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/user32/windows/window.c [iso-8859-1] > Thu Jul 3 02:17:32 2008 > @@ -921,8 +921,24 @@ > HWND STDCALL > GetLastActivePopup(HWND hWnd) > { > - UNIMPLEMENTED; > - return 0; > + PWINDOW Wnd, WndParent; > + HWND Ret = NULL; > + > + Wnd = ValidateHwnd(hWnd); > + if (Wnd != NULL) > + { > + _SEH_TRY > + { > + WndParent = NULL; > + Ret = hWnd; > + } > + _SEH_HANDLE > + { > + /* Do nothing */ > + } > + _SEH_END; > + } > + return Ret; > } > > >

16 years, 5 months

Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll

by Heis Spiter

I also agree. About the last point, in Ged's mail, I'm afraid to say I've real difficulties to code with such build time. I'm obliged to work on outdated revisons, and on partial builds. That's really insane. P. Schweitzer -------------------------------------------------- From: "gedmurphy" <gedmurphy(a)gmail.com> Sent: Wednesday, July 02, 2008 5:49 PM To: "'ReactOS Development List'" <ros-dev(a)reactos.org> Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll > I completely agree, this needs to be clamped down on. Do we really need 78 > different keyboard layouts at this point? > It's fine for the people with mega fast systems and time on their hands, > but > most people don't fall into this category. > > I now try to avoid building as much as possible and I suspect more people > will be following suit if the build time continues to increase. > > Ged > >

16 years, 5 months

Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll

by Heis Spiter

Once again I agree, and I'd like to add my 2 cents, perhaps it will help. We need two solutions right now. A short term one, and a long term one. The short one, purposed by Ged seems, IMO, to be a nice alternative before more important work, and seems to be quite easy to realize. The long one could be a work on rbuild (and makefile) with the hierarchy purposed by Ged. And instead of typing make bootcd, we would have to type make bootcd X where X would be the additionnal components with hierarchy. P. Schweitzer -------------------------------------------------- From: "gedmurphy" <gedmurphy(a)gmail.com> Sent: Thursday, July 03, 2008 9:19 AM To: "'ReactOS Development List'" <ros-dev(a)reactos.org> Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll > I'm certainly not asking him to stop. But I do think we need a rethink of > our tree structure. > The rosapps thing has never been ideal either, so moving stuff into there > isn't a good solution. > > Perhaps we need a hierarchy of components listed for importance. Let's say > the list ranges from 1 to 10. 1 being core components required to boot the > OS, 2 being additional components to get to the GUI, etc, with 10 being > things like these keyboard dlls I used as an earlier example. > > However, such a solution isn't a 5 minute job so we do need a quick fix in > the meantime. Maybe something similar to how rosapps works, with an > addition > to the /modules rbuild file? > > Ged. > > -----Original Message----- > From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On > Behalf Of Aleksey Bragin > Sent: 02 July 2008 22:34 > To: ReactOS Development List > Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll > > Asking Dmitry to abstain from work would be considered "a hack", not > "a proper solution". > > WBR, > Aleksey. > > On Jul 3, 2008, at 12:45 AM, Heis Spiter wrote: > >> I also agree. >> About the last point, in Ged's mail, I'm afraid to say I've real >> difficulties to code with such build time. I'm obliged to work on >> outdated >> revisons, and on partial builds. That's really insane. >> >> P. Schweitzer > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

16 years, 5 months

Re: [ros-dev] Prevent boolean flags from being optimized away by compiler

by Dmitry Gorbachev

Hi, Something else: there are two FORCEINLINE functions in ntoskrnl/include/internal/ntoskrnl.h, DefaultSetInfoBufferCheck() and DefaultQueryInfoBufferCheck(), but they cannot be inlined because of SEH (i.e. setjmp/longjmp). Timo Kreuzer wrote: > What about wrapping the _SEH_TRY part in a local inline function? In my > tests this successfully prevented the variables from being optimized away. > At least under normal optimisation settings.

16 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev July 2008