- Ros-dev - ReactOS.org

Networking problems with windows slaves
by caemyr＠myopera.com 07 Jun '11

07 Jun '11

Hiya The today's failure of my slaves can be explained two-way. First, buildslaves (windows ones especially, but not only) seem to be very vulnerable to ping dropouts. A single icmp drop is resulting in build interruption. Second, the hetzner.de hosting is dropping packets from my provider (atman.pl) all the way from teleport to reactos host, at a rate of one every few minutes or even more. Combined those two, any build started at the moment is dropped after 2-3 minutes of runtime. I have no idea if the network issue is temporary or not, thus no chance to predict when we will continue with runtime, Any ideas? With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 52114: [CMAKE] * Fix several modules to compile with the recent gcc versions. * ReactOS now compiles with mingw-w64 gcc 4.6.0 and boots to shell. * Dedicated to dreimer.
by Alex Ionescu 06 Jun '11

06 Jun '11

Hello, With the move to 4.6.0, please consider building with -flto=<number of cores that the build script detects> Timo: This will enable Link Time Optimizations :D -- Best regards, Alex Ionescu On 2011-06-06, at 7:44 AM, akhaldi(a)svn.reactos.org wrote: > Author: akhaldi > Date: Mon Jun 6 11:44:58 2011 > New Revision: 52114 > > URL: http://svn.reactos.org/svn/reactos?rev=52114&view=rev > Log: > [CMAKE] > * Fix several modules to compile with the recent gcc versions. > * ReactOS now compiles with mingw-w64 gcc 4.6.0 and boots to shell. > * Dedicated to dreimer. > > Modified: > trunk/reactos/dll/win32/actxprxy/CMakeLists.txt > trunk/reactos/dll/win32/kernel32/CMakeLists.txt > trunk/reactos/dll/win32/lsasrv/CMakeLists.txt > trunk/reactos/dll/win32/msports/CMakeLists.txt > trunk/reactos/dll/win32/sti/CMakeLists.txt > trunk/reactos/dll/win32/ufatx/CMakeLists.txt > trunk/reactos/dll/win32/wlanapi/CMakeLists.txt > trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt > trunk/reactos/lib/pseh/CMakeLists.txt > > Modified: trunk/reactos/dll/win32/actxprxy/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/actxprxy/CMakeLi… > ============================================================================== > --- trunk/reactos/dll/win32/actxprxy/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/actxprxy/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -44,6 +44,7 @@ > rpcrt4 > ole32 > oleaut32 > + msvcrt > kernel32 > ntdll) > > > Modified: trunk/reactos/dll/win32/kernel32/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/CMakeLi… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -114,7 +114,7 @@ > set_entrypoint(kernel32 DllMain@12) > set_image_base(kernel32 ${baseaddress_kernel32}) > > -target_link_libraries(kernel32 ${PSEH_LIB}) > +target_link_libraries(kernel32 chkstk ${PSEH_LIB}) > > add_importlibs(kernel32 ntdll) > add_pch(kernel32 k32.h) > > Modified: trunk/reactos/dll/win32/lsasrv/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/lsasrv/CMakeList… > ============================================================================== > --- trunk/reactos/dll/win32/lsasrv/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/lsasrv/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -28,7 +28,7 @@ > wine > ${PSEH_LIB}) > > -add_importlibs(lsasrv rpcrt4 kernel32 ntdll) > +add_importlibs(lsasrv rpcrt4 msvcrt kernel32 ntdll) > add_dependencies(lsasrv psdk) > add_cd_file(TARGET lsasrv DESTINATION reactos/system32 FOR all) > add_importlib_target(lsasrv.spec) > > Modified: trunk/reactos/dll/win32/msports/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -18,7 +18,7 @@ > > target_link_libraries(msports wine) > > -add_importlibs(msports setupapi comctl32 user32 advapi32 kernel32 ntdll) > +add_importlibs(msports setupapi comctl32 user32 advapi32 msvcrt kernel32 ntdll) > > add_cd_file(TARGET msports DESTINATION reactos/system32 FOR all) > add_importlib_target(msports.spec) > > Modified: trunk/reactos/dll/win32/sti/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/sti/CMakeLists.t… > ============================================================================== > --- trunk/reactos/dll/win32/sti/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/sti/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -36,6 +36,7 @@ > oleaut32 > rpcrt4 > advapi32 > + msvcrt > kernel32 > ntdll) > > > Modified: trunk/reactos/dll/win32/ufatx/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ufatx/CMakeLists… > ============================================================================== > --- trunk/reactos/dll/win32/ufatx/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/ufatx/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -9,8 +9,8 @@ > > set_entrypoint(ufatx 0) > > -target_link_libraries(ufatx vfatxlib -lgcc) > -add_importlibs(ufatx kernel32 ntdll) > +target_link_libraries(ufatx vfatxlib) > +add_importlibs(ufatx msvcrt kernel32 ntdll) > add_importlib_target(ufatx.spec) > add_dependencies(ufatx psdk) > add_cd_file(TARGET ufatx DESTINATION reactos/system32 FOR all) > > Modified: trunk/reactos/dll/win32/wlanapi/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/wlanapi/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/wlanapi/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/wlanapi/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -17,7 +17,7 @@ > wine > ${PSEH_LIB}) > > -add_importlibs(wlanapi rpcrt4 kernel32 ntdll) > +add_importlibs(wlanapi rpcrt4 msvcrt kernel32 ntdll) > add_importlib_target(wlanapi.spec) > > add_dependencies(wlanapi psdk) > > Modified: trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fslib/vfatxlib/CMakeLi… > ============================================================================== > --- trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -1,4 +1,8 @@ > > add_library(vfatxlib fatx.c vfatxlib.c) > + > +if(NOT MSVC) > + target_link_libraries(vfatxlib -lgcc) > +endif() > + > add_dependencies(vfatxlib psdk) > - > > Modified: trunk/reactos/lib/pseh/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/pseh/CMakeLists.txt?re… > ============================================================================== > --- trunk/reactos/lib/pseh/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/pseh/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -14,6 +14,7 @@ > endif() > > add_library(pseh ${SOURCE}) > + target_link_libraries(pseh chkstk) > add_dependencies(pseh psdk) > > else() > >

3 8

Re: [ros-dev] [ros-diffs] [akhaldi] 52114: [CMAKE] * Fix several modules to compile with the recent gcc versions. * ReactOS now compiles with mingw-w64 gcc 4.6.0 and boots to shell. * Dedicated to dreimer.
by Alex Ionescu 06 Jun '11

06 Jun '11

Hello, With the move to GCC 4.6.0, please consider using ms_hook_prologue. You will especially need this when synching with Wine, as they have moved to 4.6.0. This will add support for /hotpatch, which is a compatibility requirement. For example, Steam games use this feature. See http://www.mail-archive.com/wine-devel@winehq.org/msg58308.html. -- Best regards, Alex Ionescu On 2011-06-06, at 7:44 AM, akhaldi(a)svn.reactos.org wrote: > Author: akhaldi > Date: Mon Jun 6 11:44:58 2011 > New Revision: 52114 > > URL: http://svn.reactos.org/svn/reactos?rev=52114&view=rev > Log: > [CMAKE] > * Fix several modules to compile with the recent gcc versions. > * ReactOS now compiles with mingw-w64 gcc 4.6.0 and boots to shell. > * Dedicated to dreimer. > > Modified: > trunk/reactos/dll/win32/actxprxy/CMakeLists.txt > trunk/reactos/dll/win32/kernel32/CMakeLists.txt > trunk/reactos/dll/win32/lsasrv/CMakeLists.txt > trunk/reactos/dll/win32/msports/CMakeLists.txt > trunk/reactos/dll/win32/sti/CMakeLists.txt > trunk/reactos/dll/win32/ufatx/CMakeLists.txt > trunk/reactos/dll/win32/wlanapi/CMakeLists.txt > trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt > trunk/reactos/lib/pseh/CMakeLists.txt > > Modified: trunk/reactos/dll/win32/actxprxy/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/actxprxy/CMakeLi… > ============================================================================== > --- trunk/reactos/dll/win32/actxprxy/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/actxprxy/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -44,6 +44,7 @@ > rpcrt4 > ole32 > oleaut32 > + msvcrt > kernel32 > ntdll) > > > Modified: trunk/reactos/dll/win32/kernel32/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/CMakeLi… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -114,7 +114,7 @@ > set_entrypoint(kernel32 DllMain@12) > set_image_base(kernel32 ${baseaddress_kernel32}) > > -target_link_libraries(kernel32 ${PSEH_LIB}) > +target_link_libraries(kernel32 chkstk ${PSEH_LIB}) > > add_importlibs(kernel32 ntdll) > add_pch(kernel32 k32.h) > > Modified: trunk/reactos/dll/win32/lsasrv/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/lsasrv/CMakeList… > ============================================================================== > --- trunk/reactos/dll/win32/lsasrv/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/lsasrv/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -28,7 +28,7 @@ > wine > ${PSEH_LIB}) > > -add_importlibs(lsasrv rpcrt4 kernel32 ntdll) > +add_importlibs(lsasrv rpcrt4 msvcrt kernel32 ntdll) > add_dependencies(lsasrv psdk) > add_cd_file(TARGET lsasrv DESTINATION reactos/system32 FOR all) > add_importlib_target(lsasrv.spec) > > Modified: trunk/reactos/dll/win32/msports/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -18,7 +18,7 @@ > > target_link_libraries(msports wine) > > -add_importlibs(msports setupapi comctl32 user32 advapi32 kernel32 ntdll) > +add_importlibs(msports setupapi comctl32 user32 advapi32 msvcrt kernel32 ntdll) > > add_cd_file(TARGET msports DESTINATION reactos/system32 FOR all) > add_importlib_target(msports.spec) > > Modified: trunk/reactos/dll/win32/sti/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/sti/CMakeLists.t… > ============================================================================== > --- trunk/reactos/dll/win32/sti/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/sti/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -36,6 +36,7 @@ > oleaut32 > rpcrt4 > advapi32 > + msvcrt > kernel32 > ntdll) > > > Modified: trunk/reactos/dll/win32/ufatx/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ufatx/CMakeLists… > ============================================================================== > --- trunk/reactos/dll/win32/ufatx/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/ufatx/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -9,8 +9,8 @@ > > set_entrypoint(ufatx 0) > > -target_link_libraries(ufatx vfatxlib -lgcc) > -add_importlibs(ufatx kernel32 ntdll) > +target_link_libraries(ufatx vfatxlib) > +add_importlibs(ufatx msvcrt kernel32 ntdll) > add_importlib_target(ufatx.spec) > add_dependencies(ufatx psdk) > add_cd_file(TARGET ufatx DESTINATION reactos/system32 FOR all) > > Modified: trunk/reactos/dll/win32/wlanapi/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/wlanapi/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/wlanapi/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/wlanapi/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -17,7 +17,7 @@ > wine > ${PSEH_LIB}) > > -add_importlibs(wlanapi rpcrt4 kernel32 ntdll) > +add_importlibs(wlanapi rpcrt4 msvcrt kernel32 ntdll) > add_importlib_target(wlanapi.spec) > > add_dependencies(wlanapi psdk) > > Modified: trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fslib/vfatxlib/CMakeLi… > ============================================================================== > --- trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -1,4 +1,8 @@ > > add_library(vfatxlib fatx.c vfatxlib.c) > + > +if(NOT MSVC) > + target_link_libraries(vfatxlib -lgcc) > +endif() > + > add_dependencies(vfatxlib psdk) > - > > Modified: trunk/reactos/lib/pseh/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/pseh/CMakeLists.txt?re… > ============================================================================== > --- trunk/reactos/lib/pseh/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/pseh/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -14,6 +14,7 @@ > endif() > > add_library(pseh ${SOURCE}) > + target_link_libraries(pseh chkstk) > add_dependencies(pseh psdk) > > else() > >

2 1

Re: [ros-dev] [ros-diffs] [sir_richard] 52098: [FREELDR]: Some ARM architectures do not necessarily have CS0_BASE at 0x00000000, for example, most Ti OMAP Platforms have DDR at 0x80000000. The current FreeLDR algorithms wou...
by Cameron Gutman 06 Jun '11

06 Jun '11

> ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arcemul/mm.c [iso-8859-1] Sun Jun 5 20:48:34 2011 > @@ -30,7 +30,6 @@ > { { MemoryFirmwareTemporary, 0x80, 0x10 }, 4, }, // File system read buffer. FILESYSBUFFER > { { MemoryFirmwareTemporary, 0x90, 0x10 }, 5, }, // Disk read buffer for int 13h. DISKREADBUFFER > { { MemoryFirmwarePermanent, 0xA0, 0x60 }, 6, }, // ROM / Video > - { { MemorySpecialMemory, 0xFFF, 1 }, 7, }, // unusable memory > #elif __arm__ // This needs to be done per-platform specific way > > #endif This part breaks boot with AC97. > Modified: trunk/reactos/boot/freeldr/freeldr/mm/meminit.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/mm/me… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/mm/meminit.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/mm/meminit.c [iso-8859-1] Sun Jun 5 20:48:34 2011 > @@ -307,9 +322,9 @@ > case MemorySpecialMemory: > { > // > - // Special reserved memory > - // > - MemoryMapPageAllocated = LoaderSpecialMemory; > + // OS Loader Stack > + // > + MemoryMapPageAllocated = LoaderOsloaderStack; > break; > } > default: I assume this is also related. Cameron Gutman

2 1

Re: [ros-dev] [ros-diffs] [akhaldi] 52114: [CMAKE] * Fix several modules to compile with the recent gcc versions. * ReactOS now compiles with mingw-w64 gcc 4.6.0 and boots to shell. * Dedicated to dreimer.
by Alex Ionescu 06 Jun '11

06 Jun '11

Hello, With the move to 4.6.0, please look into building with -Ofast. -- Best regards, Alex Ionescu On 2011-06-06, at 7:44 AM, akhaldi(a)svn.reactos.org wrote: > Author: akhaldi > Date: Mon Jun 6 11:44:58 2011 > New Revision: 52114 > > URL: http://svn.reactos.org/svn/reactos?rev=52114&view=rev > Log: > [CMAKE] > * Fix several modules to compile with the recent gcc versions. > * ReactOS now compiles with mingw-w64 gcc 4.6.0 and boots to shell. > * Dedicated to dreimer. > > Modified: > trunk/reactos/dll/win32/actxprxy/CMakeLists.txt > trunk/reactos/dll/win32/kernel32/CMakeLists.txt > trunk/reactos/dll/win32/lsasrv/CMakeLists.txt > trunk/reactos/dll/win32/msports/CMakeLists.txt > trunk/reactos/dll/win32/sti/CMakeLists.txt > trunk/reactos/dll/win32/ufatx/CMakeLists.txt > trunk/reactos/dll/win32/wlanapi/CMakeLists.txt > trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt > trunk/reactos/lib/pseh/CMakeLists.txt > > Modified: trunk/reactos/dll/win32/actxprxy/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/actxprxy/CMakeLi… > ============================================================================== > --- trunk/reactos/dll/win32/actxprxy/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/actxprxy/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -44,6 +44,7 @@ > rpcrt4 > ole32 > oleaut32 > + msvcrt > kernel32 > ntdll) > > > Modified: trunk/reactos/dll/win32/kernel32/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/CMakeLi… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -114,7 +114,7 @@ > set_entrypoint(kernel32 DllMain@12) > set_image_base(kernel32 ${baseaddress_kernel32}) > > -target_link_libraries(kernel32 ${PSEH_LIB}) > +target_link_libraries(kernel32 chkstk ${PSEH_LIB}) > > add_importlibs(kernel32 ntdll) > add_pch(kernel32 k32.h) > > Modified: trunk/reactos/dll/win32/lsasrv/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/lsasrv/CMakeList… > ============================================================================== > --- trunk/reactos/dll/win32/lsasrv/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/lsasrv/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -28,7 +28,7 @@ > wine > ${PSEH_LIB}) > > -add_importlibs(lsasrv rpcrt4 kernel32 ntdll) > +add_importlibs(lsasrv rpcrt4 msvcrt kernel32 ntdll) > add_dependencies(lsasrv psdk) > add_cd_file(TARGET lsasrv DESTINATION reactos/system32 FOR all) > add_importlib_target(lsasrv.spec) > > Modified: trunk/reactos/dll/win32/msports/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -18,7 +18,7 @@ > > target_link_libraries(msports wine) > > -add_importlibs(msports setupapi comctl32 user32 advapi32 kernel32 ntdll) > +add_importlibs(msports setupapi comctl32 user32 advapi32 msvcrt kernel32 ntdll) > > add_cd_file(TARGET msports DESTINATION reactos/system32 FOR all) > add_importlib_target(msports.spec) > > Modified: trunk/reactos/dll/win32/sti/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/sti/CMakeLists.t… > ============================================================================== > --- trunk/reactos/dll/win32/sti/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/sti/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -36,6 +36,7 @@ > oleaut32 > rpcrt4 > advapi32 > + msvcrt > kernel32 > ntdll) > > > Modified: trunk/reactos/dll/win32/ufatx/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ufatx/CMakeLists… > ============================================================================== > --- trunk/reactos/dll/win32/ufatx/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/ufatx/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -9,8 +9,8 @@ > > set_entrypoint(ufatx 0) > > -target_link_libraries(ufatx vfatxlib -lgcc) > -add_importlibs(ufatx kernel32 ntdll) > +target_link_libraries(ufatx vfatxlib) > +add_importlibs(ufatx msvcrt kernel32 ntdll) > add_importlib_target(ufatx.spec) > add_dependencies(ufatx psdk) > add_cd_file(TARGET ufatx DESTINATION reactos/system32 FOR all) > > Modified: trunk/reactos/dll/win32/wlanapi/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/wlanapi/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/wlanapi/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/wlanapi/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -17,7 +17,7 @@ > wine > ${PSEH_LIB}) > > -add_importlibs(wlanapi rpcrt4 kernel32 ntdll) > +add_importlibs(wlanapi rpcrt4 msvcrt kernel32 ntdll) > add_importlib_target(wlanapi.spec) > > add_dependencies(wlanapi psdk) > > Modified: trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fslib/vfatxlib/CMakeLi… > ============================================================================== > --- trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/fslib/vfatxlib/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -1,4 +1,8 @@ > > add_library(vfatxlib fatx.c vfatxlib.c) > + > +if(NOT MSVC) > + target_link_libraries(vfatxlib -lgcc) > +endif() > + > add_dependencies(vfatxlib psdk) > - > > Modified: trunk/reactos/lib/pseh/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/pseh/CMakeLists.txt?re… > ============================================================================== > --- trunk/reactos/lib/pseh/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/lib/pseh/CMakeLists.txt [iso-8859-1] Mon Jun 6 11:44:58 2011 > @@ -14,6 +14,7 @@ > endif() > > add_library(pseh ${SOURCE}) > + target_link_libraries(pseh chkstk) > add_dependencies(pseh psdk) > > else() > >

1 0

Problems with unhidden quotes... final
by Olaf Siejka 06 Jun '11

06 Jun '11

Yes. You are not, sorry for the outburst. It occurs that my problem was due to GMail scripts targetting Opera specifically. Got an addon for it to pose as Firefox and guess what? Problem's gone. Thank you gmail, i`m moving away. Regards 2011/6/5 Riccardo Bestetti <riccardo.kyogre(a)live.it> > Yes, I probably missed his previous email, but this isn’t a good reason > to say that I am deficient. > Now please, let’s stop to discuss [image: Sorriso] > > *From:* Ameen Ross <a.ross(a)amdev.eu> > *Sent:* Sunday, June 05, 2011 4:04 PM > *To:* ros-dev(a)reactos.org > *Subject:* Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... > > You missed his previous mail ;) > He said that he emails with lots of replies were almost unreadable and > requested to remove what's not needed. > > On 06/05/2011 03:58 PM, Riccardo Bestetti wrote: > > I wasn’t talking to you, we was talking about browsers and I told what IE > does on my PC. > Here the deficient is you. > > *From:* Olaf Siejka <caemyr(a)gmail.com> > *Sent:* Sunday, June 05, 2011 3:07 PM > *To:* ReactOS Development List <ros-dev(a)reactos.org> > *Subject:* Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ... > > Are you being a person intellectually deficient? Or just provoking me on > any purpose? > > 2011/6/5 Riccardo Bestetti <riccardo.kyogre(a)live.it> > >> I can’t start IE on a Turion X2 @2GHz, 4GB ram (win 7), because it >> literally eats my CPU. >> It crashes my PC. It is terrible. >> Firefox works fine. >> > [whole bunch of trash deleted] > ------------------------------ > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev > > ------------------------------ > _______________________________________________ > 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 >

6 10

Sign driver for 64 Bit Build of Virtual Floppy Drive for Windows?
by Carsten Krüger 05 Jun '11

05 Jun '11

Hi, I know that for some open source projects React OS sign's windows drivers. Could you please sign the driver for virtual floppy drive? Motivation: Virtual Floppy drive is very helpfull, for example take freedos floppy image, include Samsung SpinPoint F4 EcoGreen HD204UI firmware update into the image and put it with unetbootin on usb stick. Problem: virtual floppy drive didn't run on windows 7 x64 because the need of driver signing. Homepage: http://vfd.sourceforge.net/ Description: >This is a virtual floppy drive for Windows NT / 2000 / XP developed by Ken Kato >(Reported to work also on 2003 Server and Vista). <-- and windows 7 x86, too. > >You can mount a floppy image file as a virtual floppy drive and directly access the contents -- >view, edit, rename, delete or create files on a virtual floppy, format a virtual floppy, >launch a program on a virtual floppy... almost anything you can do with a real floppy. vfdwin x64 driver build (unsigned) from "critical0" http://sourceforge.net/projects/vfd/files/2.1%20(February%2006%2C%202008)/v… vfdwin x64 driver build (unsigned) from "Igor Levicki" http://levicki.net/downloads/sendfile.php?path=vfd_x64/vfd_x64.zip Discussion about the different versions: http://levicki.net/articles/stories/2007/08/17/The_story_of_the_vfdwin_21_6… greetings Carsten

3 6

Re: [ros-dev] 1294 [dreimer] Fix clean for cmake trees. ...
by Colin Finck 05 Jun '11

05 Jun '11

dreimer(a)svn.reactos.org wrote: > if not exist "CMakeLists.txt" ( Can we decide on dropping support for rbuild stuff in RosBE 2.0? Reasons: - RosBE 2.0 will certainly come with an updated set of build tools. (GCC 4.6 with mingw-w64 target is planned, maybe even a multilib version) The target change already makes older builds uncompilable with RosBE 2.0. Even if this would be fixed, nobody would guarantee you that a revision built with RosBE 2.0 behaves the same as one compiled with 1.5.x. - Several versions of RosBE can be installed parallely, especially if you're also moving to a Windows Installer for RosBE 2.0, which doesn't care about Uninstall entries of NSIS. So everybody has the option to build older rbuild-powered revisions at any time. - It could make all scripts cleaner again :-) Regards, Colin

13 50

Re: [ros-dev] 1296 [dreimer] Get the cmake path from a system variable called _ROSBE_CMAKEPATH. Hard coding is eeevul!
by Colin Finck 05 Jun '11

05 Jun '11

dreimer(a)svn.reactos.org wrote: > Get the cmake path from a system variable called _ROSBE_CMAKEPATH. I hope we're not thinking about requiring the user to install RosBE and CMake separately. This would pretty much kill the point of RosBE if people are forced to get random versions of their build tools from multiple sources again.. - Colin

10 18

Re: [ros-dev] [ros-diffs] [nyadav] 52076: [AUDSRV] finish upto actual mixing functions
by Ged Murphy 04 Jun '11

04 Jun '11

Can you use the reactos / ansi coding standard. This code is almost unreadable, which makes it very difficult to review On 3 June 2011 22:41, <nyadav(a)svn.reactos.org> wrote: > Author: nyadav > Date: Fri Jun 3 21:41:26 2011 > New Revision: 52076 > > URL: http://svn.reactos.org/svn/reactos?rev=52076&view=rev > Log: > [AUDSRV] finish upto actual mixing functions > > Added: > branches/nyadav-audio-branch/base/services/audsrv/mixer.c (with props) > Modified: > branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt > branches/nyadav-audio-branch/base/services/audsrv/audsrv.c > branches/nyadav-audio-branch/base/services/audsrv/audsrv.h > branches/nyadav-audio-branch/base/services/audsrv/rpc.c > branches/nyadav-audio-branch/base/services/audsrv/stream.c > branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.c > branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.spec > branches/nyadav-audio-branch/drivers/wdm/audio/backpln/audclient/audclient.c > branches/nyadav-audio-branch/include/reactos/idl/audsrvrpc.idl > branches/nyadav-audio-branch/include/reactos/libs/audsrv/audsrvapi.h > > Modified: branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/servic… > ============================================================================== > --- branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/base/services/audsrv/CMakeLists.txt [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -7,6 +7,7 @@ > audsrv.c > audsrv.rc > rpc.c > + mixer.c > stream.c) > > add_executable(audsrv ${SOURCE}) > > Modified: branches/nyadav-audio-branch/base/services/audsrv/audsrv.c > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/servic… > ============================================================================== > --- branches/nyadav-audio-branch/base/services/audsrv/audsrv.c [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/base/services/audsrv/audsrv.c [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -41,6 +41,7 @@ > const GUID KSMEDIUMSETID_Standard = {0x4747B320L, 0x62CE, 0x11CF, {0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00}}; > const GUID KSDATAFORMAT_TYPE_AUDIO = {0x73647561L, 0x0000, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}}; > const GUID KSDATAFORMAT_SUBTYPE_PCM = {0x00000001L, 0x0000, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}}; > +const GUID KSDATAFORMAT_SUBTYPE_IEEE_FLOAT = {0x00000003L, 0x0000, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}}; > const GUID KSDATAFORMAT_SPECIFIER_WAVEFORMATEX = {0x05589f81L, 0xc356, 0x11ce, {0xbf, 0x01, 0x00, 0xaa, 0x00, 0x55, 0x59, 0x5a}}; > > MixerEngine engine,*pengine; > @@ -152,24 +153,31 @@ > > > > - > -void fill(MixerEngine * mixer,int buffer) > -{ > - DWORD Length; > - UINT i = 0; > -Sleep(100); > - Length = mixer->masterfreq * mixer->masterchannels * mixer->masterbitspersample / 8; > - mixer->masterbuf[buffer] = (PSHORT)HeapAlloc(GetProcessHeap(), 0, Length); > - while (i < Length / 2) > - { > - mixer->masterbuf[buffer][i] = 0x7FFF * sin(0.5 * (i - 1) * 500 * _2pi / 48000); > - i++; > - mixer->masterbuf[buffer][i] = 0x7FFF * sin(0.5 * (i - 2) * 500 * _2pi / 48000); > - i++; > - } > - mixer->bytes_to_play = Length; > -} > - > +void mixandfill(MixerEngine * mixer,int buffer) > +{ > + while(WaitForSingleObject(mixer->streampresent,100)!=0){if(mixer->dead) return;} /*Check if there is at least one stream present.*/ > + if(mixer->masterdatatype == 0)/*signed int*/ > + { > + if(mixer->masterbitspersample == 8)mixs8(mixer,buffer);else if(mixer->masterbitspersample == 16) mixs16(mixer,buffer);else if(mixer->masterbitspersample == 32) mixs32(mixer,buffer);else if(mixer->masterbitspersample == 64) mixs64(mixer,buffer); > + } > + else if (mixer->masterdatatype == 1)/*unsigned int*/ > + { > + if(mixer->masterbitspersample == 8)mixu8(mixer,buffer);else if(mixer->masterbitspersample == 16) mixu16(mixer,buffer);else if(mixer->masterbitspersample == 32) mixu32(mixer,buffer);else if(mixer->masterbitspersample == 64) mixu64(mixer,buffer); > + } > + else if(mixer->masterdatatype == 2)/*Float*/ > + { > + if(mixer->masterbitspersample == 32)mixfl32(mixer,buffer);else if(mixer->masterbitspersample == 64) mixfl64(mixer,buffer); > + } > + > + mixer->masterbuf[buffer] = HeapAlloc(GetProcessHeap(), 0, mixer->serverstreamlist->length_filtered); > + CopyMemory(mixer->masterbuf[buffer],mixer->serverstreamlist->filteredbuf,mixer->serverstreamlist->length_filtered); > + mixer->bytes_to_play = mixer->serverstreamlist->length_filtered; > +} > +void freebuffer() > +{ > + HeapFree(GetProcessHeap(), 0, pengine->masterbuf[pengine->playcurrent]); > + pengine->masterbuf[pengine->playcurrent] = NULL; > +} > void playbuffer(MixerEngine * mixer,int buffer) > { > SP_DEVICE_INTERFACE_DATA InterfaceData; > @@ -276,7 +284,10 @@ > DataFormat->Flags = 0; > DataFormat->Reserved = 0; > DataFormat->MajorFormat = KSDATAFORMAT_TYPE_AUDIO; > - DataFormat->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > + if(mixer->masterdatatype == 0 || mixer->masterdatatype == 1) > + DataFormat->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > + else > + DataFormat->SubFormat = KSDATAFORMAT_SUBTYPE_IEEE_FLOAT; > DataFormat->Specifier = KSDATAFORMAT_SPECIFIER_WAVEFORMATEX; > DataFormat->SampleSize = mixer->masterchannels * mixer->masterbitspersample / 8; > DataFormat->FormatSize = sizeof(KSDATAFORMAT) + sizeof(WAVEFORMATEXTENSIBLE); > @@ -290,9 +301,11 @@ > WaveFormat->Format.cbSize = sizeof(WAVEFORMATEXTENSIBLE) - sizeof(WAVEFORMATEX); > WaveFormat->dwChannelMask = mixer->masterchannelmask; > WaveFormat->Samples.wValidBitsPerSample = mixer->masterbitspersample; > - WaveFormat->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > - > - //printf("Creating pin\n"); > + if(mixer->masterdatatype == 0 || mixer->masterdatatype == 1) > + WaveFormat->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > + else > + WaveFormat->SubFormat = KSDATAFORMAT_SUBTYPE_IEEE_FLOAT; > + > > // > // Create the pin > @@ -367,12 +380,9 @@ > SetEvent(mixer->played); > while(1) > { > - while(WaitForSingleObject(mixer->streampresent,100)!=0){if(mixer->dead)goto DEAD;} /*Check if there is at least one stream present.*/ > - > while(WaitForSingleObject(mixer->played,100)!=0){if(mixer->dead)goto DEAD;} > - fill(mixer,1-mixer->playcurrent); > + mixandfill(mixer,1-mixer->playcurrent); > SetEvent(mixer->filled); > - > } > DEAD: > printf("\nMixer Thread Ended\n"); > @@ -386,7 +396,7 @@ > while(WaitForSingleObject(mixer->filled,100)!=0){if(mixer->dead)goto DEAD;} > SetEvent(mixer->played); > playbuffer(mixer,mixer->playcurrent); > - > + freebuffer(); > mixer->playcurrent=1-mixer->playcurrent; > } > > @@ -468,6 +478,7 @@ > pengine->mute=FALSE; > > pengine->dead=0; > + pengine->streamidpool=0; > pengine->playcurrent=1; > pengine->masterbuf[0] = NULL; > pengine->masterbuf[1] = NULL; > @@ -501,6 +512,7 @@ > pengine->mute=FALSE; > > pengine->dead=0; > + pengine->streamidpool=0; > pengine->playcurrent=1; > pengine->masterbuf[0] = NULL; > pengine->masterbuf[1] = NULL; > > Modified: branches/nyadav-audio-branch/base/services/audsrv/audsrv.h > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/servic… > ============================================================================== > --- branches/nyadav-audio-branch/base/services/audsrv/audsrv.h [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/base/services/audsrv/audsrv.h [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -29,15 +29,24 @@ > > typedef struct ServerStream > { > + long streamid; > int volume; > LONG freq; > int bitspersample; > + int datatype; /*0=signed int,1=unsigned int,2=float*/ > int channels; > ULONG channelmask; > HANDLE played; > - HANDLE streamready; > + HANDLE threadready; > HANDLE thread; > float balance; > + BOOL ready; > + PVOID genuinebuf; > + int length_genuine; > + PVOID filteredbuf; > + int length_filtered; > + PVOID minsamplevalue; > + PVOID maxsamplevalue; > struct ServerStream * next; > } ServerStream; > > @@ -45,6 +54,7 @@ > { > /*Should be Initialized at Server Start*/ > char dead; > + long streamidpool; > HANDLE played; > HANDLE filled; > HANDLE streampresent; > @@ -60,7 +70,8 @@ > int masterchannels; > unsigned long masterchannelmask; > int masterbitspersample; > - PSHORT masterbuf[2]; > + int masterdatatype; > + PVOID masterbuf[2]; > /*Currently don't know the future of following variables*/ > long bytes_to_play; > HANDLE FilterHandle; > @@ -75,10 +86,22 @@ > /* rpc.c */ > DWORD WINAPI RunRPCThread(LPVOID lpParameter); > /* audsrv.c*/ > -void fill(MixerEngine * mixer,int buffer); > +void mixandfill(MixerEngine * mixer,int buffer); > void playbuffer(MixerEngine * mixer,int buffer); > /*stream.c*/ > -HANDLE addstream(LONG frequency,int channels,int bitspersample, ULONG channelmask,int volume,int mute,float balance); > +long getnewstreamid(); > +long addstream(LONG frequency,int channels,int bitspersample,int datatype, ULONG channelmask,int volume,int mute,float balance); > +/*mixer.c*/ > +void * mixs8(MixerEngine * mixer,int buffer); > +void * mixs16(MixerEngine * mixer,int buffer); > +void * mixs32(MixerEngine * mixer,int buffer); > +void * mixs64(MixerEngine * mixer,int buffer); > +void * mixu8(MixerEngine * mixer,int buffer); > +void * mixu16(MixerEngine * mixer,int buffer); > +void * mixu32(MixerEngine * mixer,int buffer); > +void * mixu64(MixerEngine * mixer,int buffer); > +void * mixfl32(MixerEngine * mixer,int buffer); > +void * mixfl64(MixerEngine * mixer,int buffer); > /********************************/ > > #endif /* __AUDSRV_H__ */ > > Added: branches/nyadav-audio-branch/base/services/audsrv/mixer.c > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/servic… > ============================================================================== > --- branches/nyadav-audio-branch/base/services/audsrv/mixer.c (added) > +++ branches/nyadav-audio-branch/base/services/audsrv/mixer.c [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -1,0 +1,35 @@ > + > +#include "audsrv.h" > +void * mixs8(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixs16(MixerEngine * mixer,int buffer) > +{ > + mixer->masterbuf[buffer] = HeapAlloc(GetProcessHeap(), 0, mixer->serverstreamlist->length_filtered); > + CopyMemory(mixer->masterbuf[buffer],mixer->serverstreamlist->filteredbuf,mixer->serverstreamlist->length_filtered); > + mixer->bytes_to_play = mixer->serverstreamlist->length_filtered; > +} > +void * mixs32(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixs64(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixu8(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixu16(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixu32(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixu64(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixfl32(MixerEngine * mixer,int buffer) > +{ > +} > +void * mixfl64(MixerEngine * mixer,int buffer) > +{ > +} > > Propchange: branches/nyadav-audio-branch/base/services/audsrv/mixer.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: branches/nyadav-audio-branch/base/services/audsrv/mixer.c > ------------------------------------------------------------------------------ > svn:mime-type = text/plain > > Modified: branches/nyadav-audio-branch/base/services/audsrv/rpc.c > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/servic… > ============================================================================== > --- branches/nyadav-audio-branch/base/services/audsrv/rpc.c [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/base/services/audsrv/rpc.c [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -45,13 +45,13 @@ > > /*************************RPC Functions**********************************/ > > -int AUDInitStream( IN RPC_BINDING_HANDLE hBinding,LONG frequency,int channels,int bitspersample, ULONG channelmask,int volume,int mute,float balance) > +long AUDInitStream( IN RPC_BINDING_HANDLE hBinding,LONG frequency,int channels,int bitspersample,int datatype, ULONG channelmask,int volume,int mute,float balance) > { > - HANDLE stream; > - printf("Client Connected and Initiated Stream Freq: %ld,Channle: %d,Bitspersample: %d,Mask: %ld,Volume: %d,Mute: %d,Balance: %f\n",frequency,channels,bitspersample,channelmask,volume,mute,balance); > - stream = addstream(frequency,channels,bitspersample,channelmask,volume,mute,balance); > - if( stream == NULL ){return 0;}else{printf("Stream added\n");} > - return (int)stream; > + long stream; > + printf("Client Connected and Initiated Stream Freq: %ld,Channle: %d,Bitspersample: %d,Datatype: %d,Mask: %ld,Volume: %d,Mute: %d,Balance: %f\n",frequency,channels,bitspersample,datatype,channelmask,volume,mute,balance); > + stream = addstream(frequency,channels,bitspersample,datatype,channelmask,volume,mute,balance); > + if( stream != 0 ){printf("Stream added\n");} > + return stream; > } > /*************************************************************************/ > void __RPC_FAR *__RPC_USER midl_user_allocate(SIZE_T len) > > Modified: branches/nyadav-audio-branch/base/services/audsrv/stream.c > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/base/servic… > ============================================================================== > --- branches/nyadav-audio-branch/base/services/audsrv/stream.c [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/base/services/audsrv/stream.c [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -1,17 +1,40 @@ > #include "audsrv.h" > > +long getnewstreamid() > +{ > + long streamid= pengine->streamidpool; > + pengine->streamidpool+=1; > + return streamid; > +} > DWORD WINAPI RunStreamThread(LPVOID param) > { > + UINT i = 0; > ServerStream * localstream = (ServerStream *) param; > > - SetEvent(localstream->streamready); > + > printf("Signaling Mixer Thread For First Stream\n"); > - SetEvent(pengine->streampresent); > +/*HACK fill filtered buffer (1 second duration in the master stream format) directly until we are in a condition to get buffer directly from the client*/ > +/******************************************************/ > +PSHORT tempbuf; > +localstream->ready =TRUE; > +localstream->length_filtered = localstream->freq * localstream->channels * localstream->bitspersample / 8; > +tempbuf = (PSHORT)HeapAlloc(GetProcessHeap(), 0, localstream->length_filtered); > + while (i < localstream->length_filtered / 2) > + { > + tempbuf[i] = 0x7FFF * sin(0.5 * (i - 1) * 500 * 6.28 / 48000); > + i++; > + tempbuf[i] = 0x7FFF * sin(0.5 * (i - 2) * 500 * 6.28 / 48000); > + i++; > + } > +localstream->filteredbuf = tempbuf; > +/******************************************************/ > + SetEvent(localstream->threadready); > + > while (1){OutputDebugStringA("Stream Thread Running.");Sleep(100);}; > /*Clean Stream's data*/ > } > > -HANDLE addstream(LONG frequency,int channels,int bitspersample, ULONG channelmask,int volume,int mute,float balance) > +long addstream(LONG frequency,int channels,int bitspersample,int datatype, ULONG channelmask,int volume,int mute,float balance) > { > ServerStream * newstream,*localstream; > DWORD dwID; > @@ -23,37 +46,56 @@ > if(volume < 0) {newstream->volume = 0;}else if (volume > 1000) {newstream->volume = 1000;}else {newstream->volume = volume;} > if(volume < -1.0) {newstream->volume = -1.0;}else if (volume > 1.0) {newstream->volume = 1.0;}else {newstream->volume = volume;} > newstream->freq = frequency; /*TODO frequency validation required*/ > + if(datatype==0 || datatype==1 || datatype==2){newstream->datatype=datatype;}else goto error; > + if ((datatype==0 && (bitspersample == 8 || bitspersample == 16 || bitspersample == 32 || bitspersample == 64 )) || > + (datatype==1 && (bitspersample == 8 || bitspersample == 16 || bitspersample == 32 || bitspersample == 64)) || > + (datatype==2 && (bitspersample == 32 || bitspersample == 64)) ) > newstream->bitspersample = bitspersample; /*TODO bitspersample validation*/ > + else goto error; > + > newstream->channels = channels; /*TODO validation*/ > newstream->channelmask = channelmask; /*TODO validation*/ > > + newstream->ready = FALSE; > + newstream->length_genuine = 0; > + newstream->genuinebuf = NULL; > + newstream->length_filtered = 0; > + newstream->filteredbuf = NULL; > + newstream->minsamplevalue = NULL; > + newstream->maxsamplevalue = NULL; > + > newstream->next = NULL; > newstream->played = CreateEvent(NULL,FALSE,FALSE,NULL); > - newstream->streamready = CreateEvent(NULL,FALSE,FALSE,NULL); > + newstream->threadready = CreateEvent(NULL,FALSE,FALSE,NULL); > > - if(newstream->played == NULL || newstream->streamready == NULL) {goto error;} > + if(newstream->played == NULL || newstream->threadready == NULL) {goto error;} > newstream->thread=CreateThread(NULL,0,RunStreamThread,newstream,0,&dwID); > if(newstream->thread == NULL) {goto error;} > > - WaitForSingleObject(newstream->streamready,INFINITE); > > + WaitForSingleObject(newstream->threadready,INFINITE); > + > + newstream->streamid=getnewstreamid(); > if(localstream == NULL) > { > - pengine->serverstreamlist = localstream; > + pengine->serverstreamlist = newstream; > > pengine->masterfreq=frequency; > pengine->masterchannels=channels; > pengine->masterchannelmask=channelmask; > pengine->masterbitspersample=bitspersample; > + pengine->masterdatatype = datatype; > } > else > { > while(localstream->next != NULL){localstream = localstream->next;} > localstream->next = newstream; > } > - return newstream->thread; > + SetEvent(pengine->streampresent); > + return newstream->streamid; > > error: > + printf("Stream Rejected \n"); > HeapFree(GetProcessHeap(), 0, newstream); > - return NULL; > + return 0; > } > > Modified: branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.c > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/dll/win32/a… > ============================================================================== > --- branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.c [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.c [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -5,9 +5,9 @@ > /*Initialize an audio stream > *Return -1 if callbacks are NULL pointers > */ > -WINAPI int initstream (ClientStream * clientstream,LONG frequency,int channels,int bitspersample, ULONG channelmask,int volume,int mute,float balance) > +WINAPI int initstream (ClientStream * clientstream,LONG frequency,int channels,int bitspersample,int datatype, ULONG channelmask,int volume,int mute,float balance) > { > - int streamid; > + long streamid; > if (clientstream == NULL ) return -1; > if (clientstream->callbacks.OpenComplete == NULL || clientstream->callbacks.BufferCopied == NULL || clientstream->callbacks.PlayComplete == NULL) return -2; > /*Validity of all other data will be checked at server*/ > @@ -16,8 +16,9 @@ > > RpcTryExcept > { > - streamid = AUDInitStream (audsrv_v0_0_c_ifspec,frequency,channels,bitspersample,channelmask,volume,mute,balance); > - printf("AUDInitStream Returned %d",streamid); > + streamid = AUDInitStream (audsrv_v0_0_c_ifspec,frequency,channels,bitspersample,datatype,channelmask,volume,mute,balance); > + printf("AUDInitStream Returned %ld",streamid); > + if(streamid != 0) {clientstream->stream = streamid;} > } > RpcExcept(1) > { > @@ -28,8 +29,6 @@ > > /*Analyse the return by the function*/ > /*Currently Suppose the return is 0 and a valid streamid is returned*/ > - clientstream->stream = &status; > - > clientstream->ClientEventPool[0]=CreateEvent(NULL,FALSE,FALSE,NULL); > clientstream->dead = 0; > > > Modified: branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.spec > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/dll/win32/a… > ============================================================================== > --- branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.spec [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/dll/win32/audsrvapi/audsrvapi.spec [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -1,4 +1,4 @@ > -@ stdcall initstream (ptr long long long long long long long) > +@ stdcall initstream (ptr long long long long long long long long) > @ stdcall playaudio ( ptr); > @ stdcall stopaudio (ptr ); > @ stdcall Volume(ptr ptr ); > > Modified: branches/nyadav-audio-branch/drivers/wdm/audio/backpln/audclient/audclient.c > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/drivers/wdm… > ============================================================================== > --- branches/nyadav-audio-branch/drivers/wdm/audio/backpln/audclient/audclient.c [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/drivers/wdm/audio/backpln/audclient/audclient.c [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -8,7 +8,7 @@ > void buffercopied (int error ); > void playcomplete (int error ); > > -ClientStream clientstream = {NULL,0,{NULL},{opencomplete,buffercopied,playcomplete}};/*This initialization should not be necessary for a typical client*/ > +ClientStream clientstream = {0,0,{NULL},{opencomplete,buffercopied,playcomplete}};/*This initialization should not be necessary for a typical client*/ > > DWORD WINAPI RunAudioThread(LPVOID param) > { > @@ -39,12 +39,12 @@ > char input='\0'; > printf("ReactOS Audio Mixer Sample Client.Enter 'a' to Stop.\n"); > //if (clientstream->callbacks.OpenComplete == NULL || clientstream->callbacks.BufferCopied == NULL || clientstream->callbacks.PlayComplete == NULL) printf(""); > - error = initstream ( &clientstream , 44100 , 2 , 16 , KSAUDIO_SPEAKER_STEREO , 1000 , 0, 0.0 ); /*[out]HANDLE * streamhandle,[in] long frequency,[in] int number of channels,[in] int bitspersample,[in]ULONG channelmask,[in] int volume,[in] int mute,[in] float balance*/ > + error = initstream ( &clientstream , 44100 , 2 , 16 ,0, KSAUDIO_SPEAKER_STEREO , 1000 , 0, 0.0 ); /*[out]HANDLE * streamhandle,[in] long frequency,[in] int number of channels,[in] int bitspersample,[in]ULONG channelmask,[in] int volume,[in] int mute,[in] float balance*/ > if ( error ) > printf("Failed to Initialize Stream.Error %d\n", error); > else > { > - printf("StreamID : %d\n",*((int *)clientstream.stream)); > + printf("StreamID : %ld\n",clientstream.stream); > audiothread = CreateThread(NULL,0,RunAudioThread,&clientstream,0,&dwID); > } > while ( input != 'a' ) > > Modified: branches/nyadav-audio-branch/include/reactos/idl/audsrvrpc.idl > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/include/rea… > ============================================================================== > --- branches/nyadav-audio-branch/include/reactos/idl/audsrvrpc.idl [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/include/reactos/idl/audsrvrpc.idl [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -39,6 +39,6 @@ > interface audsrv > { > > - int AUDInitStream([in] handle_t h1,[in]LONG frequency,[in]int channels,[in]int bitspersample,[in] ULONG channelmask,[in]int volume,[in]int mute,[in]float balance); > + long AUDInitStream([in] handle_t h1,[in]LONG frequency,[in]int channels,[in]int bitspersample,[in]int datatype,[in] ULONG channelmask,[in]int volume,[in]int mute,[in]float balance); > > } > > Modified: branches/nyadav-audio-branch/include/reactos/libs/audsrv/audsrvapi.h > URL: http://svn.reactos.org/svn/reactos/branches/nyadav-audio-branch/include/rea… > ============================================================================== > --- branches/nyadav-audio-branch/include/reactos/libs/audsrv/audsrvapi.h [iso-8859-1] (original) > +++ branches/nyadav-audio-branch/include/reactos/libs/audsrv/audsrvapi.h [iso-8859-1] Fri Jun 3 21:41:26 2011 > @@ -17,14 +17,14 @@ > > typedef struct ClientStream > { > -HANDLE stream; > +long stream; > int dead; > HANDLE ClientEventPool[1]; //0]th event is for Activescheduler > struct CallBacks callbacks; > } ClientStream; > > /********************API Functions******************/ > -WINAPI int initstream (ClientStream * clientstream,LONG frequency,int channels,int bitspersample, ULONG channelmask,int volume,int mute,float balance); > +WINAPI int initstream (ClientStream * clientstream,LONG frequency,int channels,int bitspersample,int datatype, ULONG channelmask,int volume,int mute,float balance); > WINAPI int playaudio ( ClientStream * clientstream); > WINAPI int stopaudio (ClientStream * clientstream ); > WINAPI int Volume(ClientStream * clientstream, int * volume ); > > >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 52078: [NTOSKRNL/HAL] - Add explicit memory barriers to KxAcquireSpinLock, KxReleaseSpinLock inline functions and KeTryToAcquireQueuedSpinLock, KeTryToAcquireQueuedSpinLockRaiseToSynch i...
by Alex Ionescu 04 Jun '11

04 Jun '11

Excellent, thank you! Small nit, KeMemoryBarrierWithoutFence() is the "more correct" way of doing this in kernel code -- it expands to _ReadWriteBarrier(), but it's the "kernel-friendly" macro the WDK suggests. -- Best regards, Alex Ionescu On 2011-06-04, at 8:33 AM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sat Jun 4 12:33:54 2011 > New Revision: 52078 > > URL: http://svn.reactos.org/svn/reactos?rev=52078&view=rev > Log: > [NTOSKRNL/HAL] > - Add explicit memory barriers to KxAcquireSpinLock, KxReleaseSpinLock inline functions and KeTryToAcquireQueuedSpinLock, KeTryToAcquireQueuedSpinLockRaiseToSynch in the UP case. This will prevent the compiler from reordering memory access instructions across the boundaries of these functions, even when being inlined. > - Use the inline functions in x64 spinlock functions, too > > Modified: > trunk/reactos/hal/halx86/generic/spinlock.c > trunk/reactos/ntoskrnl/include/internal/spinlock.h > trunk/reactos/ntoskrnl/ke/amd64/spinlock.c > > Modified: trunk/reactos/hal/halx86/generic/spinlock.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/generic/spinloc… > ============================================================================== > --- trunk/reactos/hal/halx86/generic/spinlock.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/generic/spinlock.c [iso-8859-1] Sat Jun 4 12:33:54 2011 > @@ -188,6 +188,10 @@ > /* Simply raise to synch */ > KeRaiseIrql(SYNCH_LEVEL, OldIrql); > > + /* Add an explicit memory barrier to prevent the compiler from reordering > + memory accesses across the borders of spinlocks */ > + _ReadWriteBarrier(); > + > /* Always return true on UP Machines */ > return TRUE; > } > @@ -208,6 +212,10 @@ > /* Simply raise to dispatch */ > KeRaiseIrql(DISPATCH_LEVEL, OldIrql); > > + /* Add an explicit memory barrier to prevent the compiler from reordering > + memory accesses across the borders of spinlocks */ > + _ReadWriteBarrier(); > + > /* Always return true on UP Machines */ > return TRUE; > } > > Modified: trunk/reactos/ntoskrnl/include/internal/spinlock.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/spinlock.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/spinlock.h [iso-8859-1] Sat Jun 4 12:33:54 2011 > @@ -21,6 +21,10 @@ > { > /* On UP builds, spinlocks don't exist at IRQL >= DISPATCH */ > UNREFERENCED_PARAMETER(SpinLock); > + > + /* Add an explicit memory barrier to prevent the compiler from reordering > + memory accesses across the borders of spinlocks */ > + _ReadWriteBarrier(); > } > > // > @@ -32,6 +36,10 @@ > { > /* On UP builds, spinlocks don't exist at IRQL >= DISPATCH */ > UNREFERENCED_PARAMETER(SpinLock); > + > + /* Add an explicit memory barrier to prevent the compiler from reordering > + memory accesses across the borders of spinlocks */ > + _ReadWriteBarrier(); > } > > #else > > Modified: trunk/reactos/ntoskrnl/ke/amd64/spinlock.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/amd64/spinlock… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/amd64/spinlock.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/amd64/spinlock.c [iso-8859-1] Sat Jun 4 12:33:54 2011 > @@ -23,14 +23,14 @@ > KIRQL > KeAcquireSpinLockRaiseToSynch(PKSPIN_LOCK SpinLock) > { > -#ifndef CONFIG_SMP > - KIRQL OldIrql; > - /* Simply raise to dispatch */ > - KeRaiseIrql(DISPATCH_LEVEL, &OldIrql); > - return OldIrql; > -#else > - UNIMPLEMENTED; > -#endif > + KIRQL OldIrql; > + > + /* Raise to sync */ > + KeRaiseIrql(SYNCH_LEVEL, &OldIrql); > + > + /* Acquire the lock and return */ > + KxAcquireSpinLock(SpinLock); > + return OldIrql; > } > > /* > @@ -40,14 +40,14 @@ > NTAPI > KeAcquireSpinLockRaiseToDpc(PKSPIN_LOCK SpinLock) > { > -#ifndef CONFIG_SMP > - KIRQL OldIrql; > - /* Simply raise to dispatch */ > + KIRQL OldIrql; > + > + /* Raise to dispatch */ > KeRaiseIrql(DISPATCH_LEVEL, &OldIrql); > - return OldIrql; > -#else > - UNIMPLEMENTED; > -#endif > + > + /* Acquire the lock and return */ > + KxAcquireSpinLock(SpinLock); > + return OldIrql; > } > > /* > @@ -58,12 +58,9 @@ > KeReleaseSpinLock(PKSPIN_LOCK SpinLock, > KIRQL OldIrql) > { > -#ifndef CONFIG_SMP > - /* Simply lower IRQL back */ > + /* Release the lock and lower IRQL back */ > + KxReleaseSpinLock(SpinLock); > KeLowerIrql(OldIrql); > -#else > - UNIMPLEMENTED; > -#endif > } > > /* > @@ -72,14 +69,14 @@ > KIRQL > KeAcquireQueuedSpinLock(IN KSPIN_LOCK_QUEUE_NUMBER LockNumber) > { > -#ifndef CONFIG_SMP > - KIRQL OldIrql; > - /* Simply raise to dispatch */ > + KIRQL OldIrql; > + > + /* Raise to dispatch */ > KeRaiseIrql(DISPATCH_LEVEL, &OldIrql); > - return OldIrql; > -#else > - UNIMPLEMENTED; > -#endif > + > + /* Acquire the lock */ > + KxAcquireSpinLock(KeGetCurrentPrcb()->LockQueue[LockNumber].Lock); // HACK > + return OldIrql; > } > > /* > @@ -88,14 +85,14 @@ > KIRQL > KeAcquireQueuedSpinLockRaiseToSynch(IN KSPIN_LOCK_QUEUE_NUMBER LockNumber) > { > -#ifndef CONFIG_SMP > - KIRQL OldIrql; > - /* Simply raise to dispatch */ > - KeRaiseIrql(DISPATCH_LEVEL, &OldIrql); > - return OldIrql; > -#else > - UNIMPLEMENTED; > -#endif > + KIRQL OldIrql; > + > + /* Raise to synch */ > + KeRaiseIrql(SYNCH_LEVEL, &OldIrql); > + > + /* Acquire the lock */ > + KxAcquireSpinLock(KeGetCurrentPrcb()->LockQueue[LockNumber].Lock); // HACK > + return OldIrql; > } > > /* > @@ -105,13 +102,17 @@ > KeAcquireInStackQueuedSpinLock(IN PKSPIN_LOCK SpinLock, > IN PKLOCK_QUEUE_HANDLE LockHandle) > { > -#ifndef CONFIG_SMP > - /* Simply raise to dispatch */ > + /* Set up the lock */ > + LockHandle->LockQueue.Next = NULL; > + LockHandle->LockQueue.Lock = SpinLock; > + > + /* Raise to dispatch */ > KeRaiseIrql(DISPATCH_LEVEL, &LockHandle->OldIrql); > -#else > - UNIMPLEMENTED; > -#endif > -} > + > + /* Acquire the lock */ > + KxAcquireSpinLock(LockHandle->LockQueue.Lock); // HACK > +} > + > > /* > * @implemented > @@ -120,13 +121,17 @@ > KeAcquireInStackQueuedSpinLockRaiseToSynch(IN PKSPIN_LOCK SpinLock, > IN PKLOCK_QUEUE_HANDLE LockHandle) > { > -#ifndef CONFIG_SMP > - /* Simply raise to synch */ > + /* Set up the lock */ > + LockHandle->LockQueue.Next = NULL; > + LockHandle->LockQueue.Lock = SpinLock; > + > + /* Raise to synch */ > KeRaiseIrql(SYNCH_LEVEL, &LockHandle->OldIrql); > -#else > - UNIMPLEMENTED; > -#endif > -} > + > + /* Acquire the lock */ > + KxAcquireSpinLock(LockHandle->LockQueue.Lock); // HACK > +} > + > > /* > * @implemented > @@ -135,27 +140,25 @@ > KeReleaseQueuedSpinLock(IN KSPIN_LOCK_QUEUE_NUMBER LockNumber, > IN KIRQL OldIrql) > { > -#ifndef CONFIG_SMP > + /* Release the lock */ > + KxReleaseSpinLock(KeGetCurrentPrcb()->LockQueue[LockNumber].Lock); // HACK > + > + /* Lower IRQL back */ > + KeLowerIrql(OldIrql); > +} > + > + > +/* > + * @implemented > + */ > +VOID > +KeReleaseInStackQueuedSpinLock(IN PKLOCK_QUEUE_HANDLE LockHandle) > +{ > /* Simply lower IRQL back */ > - KeLowerIrql(OldIrql); > -#else > - UNIMPLEMENTED; > -#endif > -} > - > -/* > - * @implemented > - */ > -VOID > -KeReleaseInStackQueuedSpinLock(IN PKLOCK_QUEUE_HANDLE LockHandle) > -{ > -#ifndef CONFIG_SMP > - /* Simply lower IRQL back */ > + KxReleaseSpinLock(LockHandle->LockQueue.Lock); // HACK > KeLowerIrql(LockHandle->OldIrql); > -#else > - UNIMPLEMENTED; > -#endif > -} > +} > + > > /* > * @implemented > @@ -167,11 +170,16 @@ > #ifndef CONFIG_SMP > /* Simply raise to dispatch */ > KeRaiseIrql(DISPATCH_LEVEL, OldIrql); > + > + /* Add an explicit memory barrier to prevent the compiler from reordering > + memory accesses across the borders of spinlocks */ > + _ReadWriteBarrier(); > > /* Always return true on UP Machines */ > return TRUE; > #else > UNIMPLEMENTED; > + ASSERT(FALSE); > #endif > } > > @@ -185,11 +193,16 @@ > #ifndef CONFIG_SMP > /* Simply raise to dispatch */ > KeRaiseIrql(DISPATCH_LEVEL, OldIrql); > + > + /* Add an explicit memory barrier to prevent the compiler from reordering > + memory accesses across the borders of spinlocks */ > + _ReadWriteBarrier(); > > /* Always return true on UP Machines */ > return TRUE; > #else > UNIMPLEMENTED; > + ASSERT(FALSE); > #endif > } > > >

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...
by Alex Ionescu 03 Jun '11

03 Jun '11

Same comment as before, resources MUST be acquired within a critical region (as the old code did). -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote: > /* Acquire the FS lock */ > - KeEnterCriticalRegion(); > - ExAcquireResourceExclusiveLite(&FileSystemListLock, TRUE); > + ExAcquireResourceExclusiveLite(&IopDatabaseResource, TRUE);

4 3

Re: [ros-dev] 52061 [jgardou] [CMAKE], "According to gcc doc, if header.h is precompiled, the output should be named "header.h.gch" and not anything else.", Knowing it was the first step before actually doing it :-/
by Colin Finck 02 Jun '11

02 Jun '11

jgardou(a)svn.reactos.org wrote: > - set(_gch_filename "${_target_name}_${_FILE}.gch") > + set(_gch_filename "${_FILE}.gch") Looks like we're going through the same mess of GNU precompiled headers, which we already had in rbuild: 1) Giving the GCH file a custom name. Problem: It is simply ignored in the build process. 2) Just renaming it to the name of the header file. Problem: If two modules use the same header file with different build options (like #defines), the compiler can only choose one precompiled header and we have a corrupted build. The solution now is to give every GCH file an individual directory whose name contains the module name (like ".gch_smlib", this is what we currently have in rbuild). Concluding from what I see in rbuild, please also note that the GCH file needs to be named "header.h.gch", not "header.gch". Your ${basename} variable sounds like this is not done either in the CMake branch. - Colin

3 2

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...
by Alex Ionescu 02 Jun '11

02 Jun '11

You are rebrowsing the *whole* list, yet the caller gave you an argument (DriverObjectListSize) that indicated to you how large his array is. You should browse the minimum of the whole list while making sure that "Index" does not grow larger than DriverObjectListSize / sizeof(pointer). Right now the function is overwriting memory possibly. This is because + /* Then, check if given buffer is big enough to contain list */ + if (ListSize > DriverObjectListSize / sizeof(PDRIVER_OBJECT)) + { + Status = STATUS_BUFFER_TOO_SMALL; + } + else is incorrect. The function attempts to write as many entries as possible instead of failing. As per the docs: " Note that if the array at DriverObjectList is too small, the number of driver object pointers that are copied into the array will be less than ActualNumberDriverObjects." -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote: > + /* Rebrowse the whole list */ > + ListEntry = IopFsNotifyChangeQueueHead.Flink; > + while (ListEntry != &IopFsNotifyChangeQueueHead) > + {

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...
by Alex Ionescu 02 Jun '11

02 Jun '11

As per elementary Windows Driver Development basics, resources should ALWAYS be acquired within a critical or guarded region. -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote: > + /* Acquire the FS lock */ > + ExAcquireResourceExclusiveLite(&IopDatabaseResource, TRUE);

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...
by Alex Ionescu 02 Jun '11

02 Jun '11

You misunderstand the meaning of the parameter. The last entry is the RAW file system. This parameter influences if RAWFS should be notified or not. -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote: > + /* Check if we reached end and if we have to skip it */ > + if (ListEntry->Flink == ListHead && SkipLast) > + {

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 52065: [NTOSKRNL] - renamed Io volumes global to match Windows names (in case of debug) - renamed IopDereferenceVpb() to IopDereferenceVpbAndFree(), IopReferenceVpbForVerify() to IopR...
by Alex Ionescu 02 Jun '11

02 Jun '11

You need to cast to volatile. (Same for Increment). There's also no need to return the old value. -- Best regards, Alex Ionescu On 2011-06-02, at 1:43 PM, pschweitzer(a)svn.reactos.org wrote: > + OldValue = (*Ulong)--;

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 52055: [FDC] - Implement fdc.sys (still needs work but fairly complete) [TXTSETUP.SIF] - Load fdc.sys for floppy controllers [FDC.INF] - Install fdc.sys for floppy controllers
by Aleksey Bragin 02 Jun '11

02 Jun '11

With all my respect to the hard work put into this, I want to express my concerns: Why is there a need to develop a half-done fdc, if there is a full, working, tested by millions driver available even in old DDKs, which we can use without violating its license? Why waste time writing that driver from scratch now when we could just import DDK's one and spend time fixing our PnP manager instead, and other involved components so that DDK's driver actually works? Again, with all my respect to Cameron, he does a great job, but when he disappears next time for a year or two, who is going to finish FDC? Or any other of his half-finished branches? (each being really a pearl if it's done). I would really suggest using all available resources first and only then spend time developing our own stuff instead of already existing. Thanks for understanding, Aleksey. On Jun 2, 2011, at 10:24 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Thu Jun 2 06:24:25 2011 > New Revision: 52055 > > URL: http://svn.reactos.org/svn/reactos?rev=52055&view=rev > Log: > [FDC] > - Implement fdc.sys (still needs work but fairly complete) > [TXTSETUP.SIF] > - Load fdc.sys for floppy controllers > [FDC.INF] > - Install fdc.sys for floppy controllers > > Added: > trunk/reactos/drivers/storage/fdc/CMakeLists.txt (with props) > trunk/reactos/drivers/storage/fdc/directory.rbuild (with props) > trunk/reactos/drivers/storage/fdc/fdc/CMakeLists.txt (with > props) > trunk/reactos/drivers/storage/fdc/fdc/SOURCES (with props) > trunk/reactos/drivers/storage/fdc/fdc/fdc.c (with props) > trunk/reactos/drivers/storage/fdc/fdc/fdc.h (with props) > trunk/reactos/drivers/storage/fdc/fdc/fdc.rbuild (with props) > trunk/reactos/drivers/storage/fdc/fdc/fdc.rc (with props) > trunk/reactos/drivers/storage/fdc/fdc/fdo.c (with props) > trunk/reactos/drivers/storage/fdc/fdc/pdo.c (with props) > Modified: > trunk/reactos/boot/bootdata/txtsetup.sif > trunk/reactos/drivers/storage/CMakeLists.txt > trunk/reactos/drivers/storage/directory.rbuild > trunk/reactos/media/inf/fdc.inf >

5 5

About ReactOS hive files and end_pages in header being possibly wrong
by Richard W.M. Jones 31 May '11

31 May '11

Hi, I'm one of the authors of hivex, a program for reading Windows registry hive files: http://libguestfs.org/hivex.3.html The library can't currently read ReactOS hive files. I'm *very* hestitant to say anyone is "wrong" here since the documentation for hive files is obviously non-existent, but it appears that ReactOS doesn't fill in the end_pages field in the header, and instead relies on the size of the file itself. For example, a hive downloaded from a fresh ReactOS install: hivex_open: header fields: file version 1.3 sequence nos 3 3 (sequences nos should match if hive was synched at shutdown) original file name (only 32 chars are stored, name is probably truncated) root offset 0x70 + 0x1000 ** end of last page 0x1000 + 0x1000 (total file size 0x22000) checksum 0x8dc38fdf (calculated 0x8dc38fdf) Notice that "end of last page" field is 0x1000, versus a completely different file size. hivex currently refuses to read past the end_pages limit, and we are able to read every Windows hive that has ever been thrown at us. If I hack hivex so that it ignores end_pages and simply uses the size of the file as a guide, then hivex can successfully read the whole of the file. However I'm a bit unwilling to make this change to hivex just for ReactOS, since it works fine with real Windows already. So I wonder if this could just be a mistake in ReactOS or if there's some deeper reason that I'm missing. TIA, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

4 5

May Meeting Minutes
by Colin Finck 27 May '11

27 May '11

May Meeting Minutes 2011-05-26 20:05 UTC Freenode, #reactos-meeting Participants ============= - Aleksey Bragin - Art Yerkes - Cameron Gutman - Claudiu Mihail - Colin Finck - Gabriel Ilardi - Ged Murphy - Giannis Adamopoulos - James Tabor - Jan Blomqvist Kinander - Javier Agustìn Fernàndez Arroyo - Johannes Anderwald - Kamil Hornicek - Maciej Bialas - Matthias Kupfer - Neeraj Yadav - Olaf Siejka - Pierre Schweitzer - Rafal Harabien - Samuel Serapion - Sylvain Petreolle - Thomas Faber - Timo Kreuzer - Victor Martinez - Ziliang Guo Proceedings ============ ○ Meeting called to order at 20:05 UTC by Aleksey Bragin. ○ Point 1: Status of our GSoC participation -------------------------------------------- ■ ReactOS' GSoC administrator Ged Murphy gave a quick update about individual participants: - Timo Kreuzer is way ahead of the timeline and already has his font driver working under Windows. He later showed these screenshots: * http://imageshack.us/photo/my-images/156/ftfd.png/ * http://imageshack.us/photo/my-images/5/roxxc.png/ * http://imageshack.us/photo/my-images/220/wtfishappening.png/ * http://imageshack.us/photo/my-images/199/ie1d.png/ The major remaining work is implementing the appropriate interface to make the font driver usable under ReactOS. - Giannis Adamopoulos is also progressing well and has already committed a lot of code regarding theming. He later showed these screenshots: * http://img846.imageshack.us/img846/8500/theme2.png * http://img88.imageshack.us/img88/9660/theme3v.png * http://img691.imageshack.us/img691/7425/theme1c.jpg - Thomas Faber, who works on the kernel-mode test suite, has been pretty quiet so far, but is considered a trustworthy person who knows what he is doing and does not need much help from the community. - Claudiu Mihail is considered a great student who is always available on IRC and often asking questions. His lwIP driver is progressing well, although he agrees that there is still much work left. - Andrew Green has taken the task to complete our new Explorer, but there were a few issues with what he thought he was doing and what we wanted from him. He assumed he had to work on the explorer_new application itself while we actually need work done on related components like shell32 and browseui. Ged thinks he might have underestimated the workload a little, so some help from the community might be required. This is also why Ged has begun to work on shell32 himself and merge the latest changes with the C++ code by Andrew Hill. Ged explicitly asks for more developers to join these efforts. It would be great if these people had experiences with COM, although this could also be a nice task for developers who want to learn a bit about COM. ○ Point 2 (added): Neeraj Yadav's participation in GSoC -------------------------------------------------------- ■ Ged Murphy gave a quick background on what happened regarding Neeraj Yadav, who was meant to work on the Audio Mixer project: - After Google announced the project, Neeraj Yadav disappeared for 4 weeks and was not reachable by E-Mail or IRC. - Ged has spoken to Carol Smith from Google afterwards, who mentioned that some students waited for the first payment and then fled. - After a lot of discussion, it was necessary to inform Google that we had lost a student. - Ged has written some very apologetic mails to Google afterwards, and they were pretty understanding. - He has especially emphasized that this was a very bad time for us and made the project looking incompetent. Apart from him, Amine Khaldi and Johannes Anderwald (his mentor) were very angry about this as well. - Two days after these mails, Neeraj Yadav reappeared on IRC. ■ Neeraj Yadav said he was really sorry about his mistake, but also explained his actions: - He mentioned that his case was actually the opposite of what Google might assume: While some students keep in contact with the organisation until they get their first payment, he actually disappeared during the community bonding period, but was available again on the first day when coding started. - His sudden absence occurred, because he needed to move to his brother who lives in a remote place with no internet connectivity. ■ Ged again emphasized that a wrong decision on this can affect our further participation in Google's Summer of Code project. ■ After a long discussion, it was decided that this matter requires a private conversation between Johannes Anderwald and Ged Murphy and a final decision needs to be taken by them. Please note that this is a very shortened version of the discussion and you should not build an opinion about the issue just from this information. ○ Point 3 (added): Changes in the meeting organisation ------------------------------------------------------- ■ Victor Martinez proposed to create a list of E-Mail addresses of ReactOS Members, who are then informed one week before the meeting takes place. - This idea was immediately rejected by Aleksey Bragin and Samuel Serapion, because we have the ros-dev mailing list for this. - Victor Martinez then proposed that someone at least sends a mail to ros-dev one week in advance. Colin Finck, Gabriel Ilardi, Jan Blomqvist Kinander and Pierre Schweitzer agreed to this. - Colin Finck proposed that Aleksey Bragin could take this job. Aleksey Bragin agreed. ■ Jan Blomqvist Kinander asked whether we could already begin at 19:00 UTC. This required a voting between all participants (excluding the people who only came to us through GSoC). As Colin Finck has not fixed the IRC server with voting capabilities yet, the voters were publicly asked about their opinion. Result: - 17 positive votes - 1 abstention - 0 negative votes The remaining participants were not available and did not vote. Even without them, this result shows that we have a clear simple majority, so further meetings will begin at 19:00 UTC. ○ Point 4: Current ReactOS work, Developers reporting their status ------------------------------------------------------------------- ■ Aleksey Bragin had a busy month, which began by giving a technical lecture about ReactOS at Prague's technical university in the faculty of informatics. It was received quite well with enough of interesting questions. Afterwards, he moved to Berlin to join Matthias at our LinuxTag booth. He describes the event as a very crowded and well advertised one. On top of this, the ReactOS booth was located quite close to the entrance, so we received a lot of visitors. Despite LinuxTag being Europe's biggest Open-Source event, 99% of the incoming people were German, so Matthias had to handle most of them. Regarding ReactOS development, Aleksey is still working on his LDR rewrite and fixed a few of the blocker bugs. There is still one serious problem left until he can commit the rewrite to Trunk and gradually improve it there, which should be done much faster. When this is done and there are no new regressions left, he wants to perform a full Wine sync. ■ Art Yerkes has spent most time working on DWARF symbols. He made slow progress towards reading the arguments off the stack as described by the DWARF debug information. After Colin Finck asked, he also reported about NewCC being in the same state as before, namely still requiring performance improvements and regression testing until it can be merged back to Trunk. ■ Cameron Gutman has been doing work on the PnP manager involving hot swapping devices (like implementing device ejection, surprise removal, etc.). He is almost done with his implementation of IoRequestDeviceEject. The code is currently unused, but the USB work might be a good testcase for it. ■ Colin Finck has returned to Germany two weeks ago and has been busy with (mostly routine) foundation and server work. He is also relocating in August, so he might be missing time for ReactOS work afterwards. For now, his list basically inclues three ReactOS-related points: - Fixing the bug in the IRC server we used for the March meeting - Starting work on "RosBE 2.0" (certainly together with dreimer), which also includes establishing fixed build tool versions for the big CMake rollout - Helping with the big website revamp ■ Gabriel Ilardi is quite busy lately, so he is mainly following the forum and contributed some bitmaps for logonui. ■ Giannis Adamopoulos is exclusively working on the Theming task for GSoC. ■ Ged Murphy as our GSoC administrator has been pretty busy with related work. However, he has recently started to work on the conversion of shell32 to C++ and just finished merging back all changes from the C version. He especially wants to thank Andrew Hill for his first work on the C++ version and in particular his ATL headers, which give us a true OO COM implementation. Additionally, he has started work on a logonui module, but this is just a fun project for now. Finally, he has a partially working NTFS driver, but this project is currently put on hold. ■ James Tabor is researching bug reports and building a list of related issues and problems in the server-side window procedures. As we currently do not have a functional screensaver, he is also trying to fix this. ■ Jan Blomqvist Kinander is planning a new burglar-proof server bunker fire cell at his workplace and will move our Fezile server (currently hosting Doxygen and ISO Storage) there. He is also planning to make room for a LAN behind the Fezile server, which we could use for automatic tests on real hardware. ■ Johannes Anderwald is teaming with Michael Martin to develop the USB stack. The current goal is to bring a working USB mass storage stack to ReactOS. From this perspective, the goal is already reached for USB 2.0. Today, he also got OHCI 1.1 mass storage support working and added some fixes for keyboard/mice support in the USBOHCI driver. This still requires proper HID support in a higher class driver though. The next goals probably include UHCI support and synchronizing the work with Cameron's PnP fixes and Pierre's Mount Manager work. ■ Kamil Hornicek has been arranging Aleksey's speech in Prague, but did not have time for other ReactOS-related work. If anybody has an interesting side project, he is willing to find some spare time for it though. ■ Maciej Bialas hopes to get back to working on our new website in the next one or two weeks. He has lately been setting up a local Bugzilla and evaluated its authentication capabilities when combined with Drupal CMS. ■ Matthias Kupfer has been attending our LinuxTag booth for all three days and is now working on a lot of "end-user-visible" parts in his spare time. Since LinuxTag, he has started with the internationalization of registry entries and small changes like adding the progress bar back to FreeLdr. Besides, he also does routine work for the German ReactOS foundation. ■ Olaf Siejka has been working on testing and pushing patches (as reported by Gabriel Ilardi). He also reported that the CMake/MSVC builds are now compiled from Trunk, but he needs to reinstall his Buildslave with Windows 7 SP1 and thinks about buying a fast SSD for it. Finally, he is in the middle of converting Polish resources to UTF-8 and perform some cleanup and style corrections in the process. ■ Rafal Harabien has been busy with real life issues lately, but plans to fix our cursors implementation in Win32k soon and clipboards afterwards. ■ Samuel Serapion is writing code for NTLM authentication stuff and will move to the MSV1_0 and LSA modules afterwards. He referred to http://msdn.microsoft.com/en-us/library/aa378753%28v=vs.85%29.aspx for explanations about what these modules are used for. ■ Timo Kreuzer is exclusively working on the FreeType font driver for GSoC. ■ Victor Martinez has been presenting ReactOS at small Spanish conferences about Open-Source in Seville and Huelva (again) before he joined Aleksey and Matthias at LinuxTag in Berlin. Lately, he has been modifying the Testing Central Wiki page, where the GoldenApps now point to the Compatibility Database. Finally, he plans to establish a real Testing Team (mainly from Forum users) together with Olaf. ■ Ziliang Guo has been working on several things like building and verifying the drivers which are going to be signed with the ReactOS Foundation certificate. He is also testing out a new MSI installer for RosBE-Windows. His work towards the website overhaul is currently on hold, because he first needs to install some more modules. ○ Meeting closed at 22:36 UTC by Colin Finck on behalf of Aleksey Bragin. ○ Minutes written by Colin Finck.

2 1

Regarding Meeting
by Neeraj Yadav 27 May '11

27 May '11

Hi, I am a GSoC student working on Audio Mixer Project.Unfortunately, I was not able to contact my mentor/administrator during community bonding period.I have disappointed whole of the community and you have every right to be angry and I am really sorry for my act.But I request you all to reconsider the following points : 1. Firstly, Why would one disappear during community bonding period without any reason ? It is the easiest part of the whole program for a student in which they have to just talk to the community, which I think they have already been doing for not less than a month, then what is the problem in being in contact for another month. In my opinion a smart student who just wanted his initial payment would have disappeared after the community bonding period.Instead of coming back at the time of actual work. 2. Some of you think that I was waiting for initial payment and then reappeared when i did not get it, I would like to say that I appeared without even knowing that my project has been discontinued, neither had anyone got his welcome package upto that time.Nothing regarding my project discontinuation had been reported in Melange.How could i get even a slightest idea about my project's termination. 3. Some of you think that it is going to hurt the reputation of organisation for next year's selection at GSoC, I would like to admit that terminating my project will straightaway decrease project completion rate of ReactOS organisation to 80% and it may further reduce if some students actually do not complete the project which is considered too bad for an organisation.And believe me next year's sole criterion for organisation selection will be this success rate. 4.Problems occur to every organisation and Google understands it very well and it doesn't affect the organisation's reputation that much.All that matters is the success rate. 5. I talked to Google and they just want an email of consent from my mentor and its not too late.I have filled all my forms in due time. 6. My project would have automatically been discontinued if I failed for Mid-term Evaluation.But no one gets benefit if my project is discontinued earlier.Take a chance guys, If I complete my project it will be good for both me and community if not terminating my project at both 7. In case above explanations do not satisfy you and if you think this is only money I am after, I am ready to deposit $500 as security which is equal to the initial payment.[or whatever amount you say] This issue can be discussed in today's meeting.I am ready to answer all of your questions.I hope you will think about it with a cool mind keeping the anger/ego apart. -- Regards Neeraj Yadav Undergraduate Student Indian Institute of Technology, Delhi

3 3

Thomas Krenn Support
by Matthias Kupfer 26 May '11

26 May '11

HI folks, the German company Thomas Krenn AG (Server Hardware) announced on LinuxTag an open source support programme for open source projectes, that register during LinuxTag. So I've use this chance and made the first step and registered ReactOS. Now we need some arguments what kind of hardware do we need and why resp. for what purpose. Devs please take a look at thomas-krenn.com and select a usefull set of hardware and describe what is usefull for. I think we should define specific tasks, not "upgrade exisiting hardware", but e.g. "New continuous integration server". Please send the description and the ID of the basket to me. The prices are: 1st: hardware for 2500 € (excluding VAT) 2nd: hardware for 1500 € (excluding VAT) 3rd: hardware for 1000 € (excluding VAT) 4th: hardware for 800 € (excluding VAT) 5th: hardware for 700 € (excluding VAT) They told me at the booth the chances increase with the detailed description of the intended use of the selected hardware (maybe combined with neediness). Best regards Matthias -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

5 5

Fezile Server planned shut-down.
by Jan Blomqvist Kinander 26 May '11

26 May '11

Hi, I will have to take down the Fezile server for a short period of time in about 2 weeks due to a move of the server room to a fireproof, fairly burglarproof security room (brickswork with steeldoor, no windows). However, it is beeing remodelled right now, and then the aircondition, ethernet lines and power is going to be installed, so I guess two weeks. I have some computers to move so the power down may take some time, but I will try to make the move as fast as possible. During this time I will try to prepare for a ReactOS LAN behind the Fezile server on the second and third LAN adapter, for example for build testing on real hardware or another build bot. Yours sincerely, Jaix Bly (Jan Blomqvist Kinander)

1 0

Status meeting
by Aleksey Bragin 26 May '11

26 May '11

Hello, I want to remind you of the monthly status meeting taking place today, Thursday the 26th of May at 20:00 UTC at freenode #reactos-meeting. The suggested (subject to change and addition before meeting starts) meeting agenda is: - Status of our GSoC participation - Current ReactOS work. Developers reporting their status. Those who don’t attend will be able to read up the meeting minutes later. See you at the meeting today! WBR, Aleksey Bragin.

3 3

Getbuilds not functioning
by Olaf Siejka 25 May '11

25 May '11

Hiya Our nightly builds repository is not working and people cannot download anything from it. Is it a known issue? Any idea when it might be fixed? Best regards

3 2

Reminder to GSoC students (and everyone else) about commit format
by Zachary Gorden 24 May '11

24 May '11

Commit messages should include the component name that your commit changes. Messages like the following: [nyadav] 51882: Fix a Deadlock (nyadav(a)svn.reactos.org) will result in me coming after you when I need to do the changelog for the next release. Messages should be formatted like this: [tkreuzer] 51885: [WIN32K] - Fix the bitmap alignment issue that caused broken scrollbar pattern (tkreuzer(a)svn.reactos.org) Z98

1 0

Buildbot issue
by Pierre Schweitzer 24 May '11

24 May '11

Hi, it appears that Linux buildbot is running a bad issue and is looping on building. If anyone can have a look? To prevent flood on IRC, I silent bot and removed voice. Thanks in advance

3 4

Re: [ros-dev] [ros-diffs] [osiejka] 51874: [RPCSS] Addenum. This change slipped past in commit 51873. Fix name of irot header include, which should be irot.h and not irot_s.h. Fixes rpcss build in MSVC.
by Ged Murphy 24 May '11

24 May '11

That was very confusing :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of osiejka(a)svn.reactos.org Sent: 23 May 2011 22:49 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [osiejka] 51874: [RPCSS] Addenum. This change slipped past in commit 51873. Fix name of irot header include, which should be irot.h and not irot_s.h. Fixes rpcss build in MSVC. Author: osiejka Date: Mon May 23 21:49:12 2011 New Revision: 51874 URL: http://svn.reactos.org/svn/reactos?rev=51874&view=rev Log: [RPCSS] Addenum. This change slipped past in commit 51873. Fix name of irot header include, which should be irot.h and not irot_s.h. Fixes rpcss build in MSVC. Modified: trunk/reactos/base/services/rpcss/irotp.c Modified: trunk/reactos/base/services/rpcss/irotp.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/rpcss/irotp.… ============================================================================== --- trunk/reactos/base/services/rpcss/irotp.c [iso-8859-1] (original) +++ trunk/reactos/base/services/rpcss/irotp.c [iso-8859-1] Mon May 23 21:49:12 2011 @@ -1,5 +1,5 @@ /* - * Running Object Table + * Running Object Table * * Copyright 2007 Robert Shearman *

2 1

Missing header in rpcss
by Olaf Siejka 22 May '11

22 May '11

It was spotted by MSVC build: P:\Trunk_slave\MSVC-trunk\build\base\services\rpcss\irotp.c(28) : fatal error C1083: Cannot open include file: 'irot_s.h': No such file or directory LINK : fatal error LNK1104: cannot open file 'CMakeFiles/rpcss.dir/irotp.c.obj' In base\services\rpcss\irotp.c:28 we see: #include "irot_s.h" This file is not present in ReactOS trunk. In WINE's RPCSS http://source.winehq.org/git/wine.git/blob/HEAD:/programs/rpcss/irotp.c :28 we have: #include "irot.h" which is also missing, and listed in .gitignore: http://source.winehq.org/git/wine.git/blob?f=.gitignore 260 programs/rpcss/irot.h 261 programs/rpcss/irot_s.c I think we can safely clean it up, perhaps adding proper line to ros-diff, but i would like to ask you guys for confirmation. Regards

2 3

Re: [ros-dev] [ros-diffs] [jimtabor] 51835: [Win32k|User32] - Move creation of the scrollbar Gray brush from user32 to win32k. - Noticed a color and pattern (patchy white pattern) difference when using GreCreateBitmap and i...
by Timo Kreuzer 22 May '11

22 May '11

Hi, I suspect its an alignment issue, since GreCreateBitmap requires 32bit alignment, while CreateBitmap uses 16 bit alignment. So changing + static const WORD wPattern55AA[] = { 0x5555, 0xaaaa, 0x5555, 0xaaaa, 0x5555, 0xaaaa, 0x5555, 0xaaaa }; to + static const DWORD wPattern55AA[] = { 0x5555, 0xaaaa, 0x5555, 0xaaaa, 0x5555, 0xaaaa, 0x5555, 0xaaaa }; Should do the trick. Am 21.05.2011 08:34, schrieb jimtabor(a)svn.reactos.org: > Author: jimtabor > Date: Sat May 21 06:34:02 2011 > New Revision: 51835 > > URL: http://svn.reactos.org/svn/reactos?rev=51835&view=rev > Log: > [Win32k|User32] > - Move creation of the scrollbar Gray brush from user32 to win32k. > - Noticed a color and pattern (patchy white pattern) difference when using GreCreateBitmap and it did not work the same as the main function. Correcting this fixed the Gray brush. Someone from YAROTOWS needs to look into this. > > Modified: > trunk/reactos/dll/win32/user32/windows/defwnd.c > trunk/reactos/subsystems/win32/win32k/include/brush.h > trunk/reactos/subsystems/win32/win32k/ntuser/ntuser.c > trunk/reactos/subsystems/win32/win32k/objects/bitmaps.c > trunk/reactos/subsystems/win32/win32k/objects/brush.c > > Modified: trunk/reactos/dll/win32/user32/windows/defwnd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/d… > ============================================================================== > --- trunk/reactos/dll/win32/user32/windows/defwnd.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/user32/windows/defwnd.c [iso-8859-1] Sat May 21 06:34:02 2011 > @@ -927,8 +927,8 @@ > HBRUSH > DefWndControlColor(HDC hDC, UINT ctlType) > { > - if (CTLCOLOR_SCROLLBAR == ctlType) > - { > + if (ctlType == CTLCOLOR_SCROLLBAR) > + { > HBRUSH hb = GetSysColorBrush(COLOR_SCROLLBAR); > COLORREF bk = GetSysColor(COLOR_3DHILIGHT); > SetTextColor(hDC, GetSysColor(COLOR_3DFACE)); > @@ -938,37 +938,24 @@ > * we better use 0x55aa bitmap brush to make scrollbar's background > * look different from the window background. > */ > - if (bk == GetSysColor(COLOR_WINDOW)) > - { > - static const WORD wPattern55AA[] = > - { > - 0x5555, 0xaaaa, 0x5555, 0xaaaa, > - 0x5555, 0xaaaa, 0x5555, 0xaaaa > - }; > - static HBITMAP hPattern55AABitmap = NULL; > - static HBRUSH hPattern55AABrush = NULL; > - if (hPattern55AABrush == NULL) > - { > - hPattern55AABitmap = CreateBitmap(8, 8, 1, 1, wPattern55AA); > - hPattern55AABrush = CreatePatternBrush(hPattern55AABitmap); > - } > - return hPattern55AABrush; > - } > - UnrealizeObject(hb); > + if ( bk == GetSysColor(COLOR_WINDOW)) > + return gpsi->hbrGray; > + > + UnrealizeObject( hb ); > return hb; > - } > + } > > SetTextColor(hDC, GetSysColor(COLOR_WINDOWTEXT)); > > - if ((CTLCOLOR_EDIT == ctlType) || (CTLCOLOR_LISTBOX == ctlType)) > - { > + if ((ctlType == CTLCOLOR_EDIT) || (ctlType == CTLCOLOR_LISTBOX)) > + { > SetBkColor(hDC, GetSysColor(COLOR_WINDOW)); > - } > + } > else > - { > + { > SetBkColor(hDC, GetSysColor(COLOR_3DFACE)); > return GetSysColorBrush(COLOR_3DFACE); > - } > + } > > return GetSysColorBrush(COLOR_WINDOW); > } > > Modified: trunk/reactos/subsystems/win32/win32k/include/brush.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/brush.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/brush.h [iso-8859-1] Sat May 21 06:34:02 2011 > @@ -129,3 +129,5 @@ > VOID FASTCALL FreeObjectAttr(PVOID); > > BOOL FASTCALL IntGdiSetBrushOwner(PBRUSH,DWORD); > +BOOL FASTCALL GreSetBrushOwner(HBRUSH,DWORD); > + > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/ntuser.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/ntuser.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/ntuser.c [iso-8859-1] Sat May 21 06:34:02 2011 > @@ -92,6 +92,8 @@ > HANDLE hPowerRequestEvent, > HANDLE hMediaRequestEvent) > { > + static const WORD wPattern55AA[] = { 0x5555, 0xaaaa, 0x5555, 0xaaaa, 0x5555, 0xaaaa, 0x5555, 0xaaaa }; > + HBITMAP hPattern55AABitmap = NULL; > NTSTATUS Status; > > // Set W32PF_Flags |= (W32PF_READSCREENACCESSGRANTED | W32PF_IOWINSTA) > @@ -125,6 +127,14 @@ > > CsrInit(); > > + if (gpsi->hbrGray == NULL) > + { > + hPattern55AABitmap = GreCreateBitmap(8, 8, 1, 1, (LPBYTE)wPattern55AA); > + gpsi->hbrGray = IntGdiCreatePatternBrush(hPattern55AABitmap); > + GreDeleteObject(hPattern55AABitmap); > + GreSetBrushOwner(gpsi->hbrGray, GDI_OBJ_HMGR_PUBLIC); > + } > + > return STATUS_SUCCESS; > } > > > Modified: trunk/reactos/subsystems/win32/win32k/objects/bitmaps.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/bitmaps.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/bitmaps.c [iso-8859-1] Sat May 21 06:34:02 2011 > @@ -154,15 +154,23 @@ > IN UINT cBitsPixel, > IN OPTIONAL PVOID pvBits) > { > + HBITMAP hbmp; > /* Call the extended function */ > - return GreCreateBitmapEx(nWidth, > + hbmp = GreCreateBitmapEx(nWidth, > nHeight, > 0, /* auto width */ > BitmapFormat(cBitsPixel * cPlanes, BI_RGB), > 0, /* no bitmap flags */ > 0, /* auto size */ > - pvBits, > - DDB_SURFACE /* DDB */); > + NULL, > + DDB_SURFACE /* DDB */); > + if (pvBits&& hbmp) > + { > + PSURFACE psurf = SURFACE_ShareLockSurface(hbmp); > + UnsafeSetBitmapBits(psurf, 0, pvBits); > + SURFACE_ShareUnlockSurface(psurf); > + } > + return hbmp; > } > > HBITMAP > > Modified: trunk/reactos/subsystems/win32/win32k/objects/brush.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/brush.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/brush.c [iso-8859-1] Sat May 21 06:34:02 2011 > @@ -59,6 +59,19 @@ > GDIOBJ_vSetObjectOwner(&pbr->BaseObject, ulOwner); > > return TRUE; > +} > + > +BOOL > +FASTCALL > +GreSetBrushOwner(HBRUSH hBrush, ULONG ulOwner) > +{ > + BOOL Ret; > + PBRUSH pbrush; > + > + pbrush = BRUSH_ShareLockBrush(hBrush); > + Ret = IntGdiSetBrushOwner(pbrush, ulOwner); > + BRUSH_ShareUnlockBrush(pbrush); > + return Ret; > } > > BOOL > > >

5 7

unsubscribe
by He Junyan 21 May '11

21 May '11

2 1

shell32 vs. shell32_new
by Gregor Schneider 19 May '11

19 May '11

Hi ros-dev, I've seen shell32_new being added into trunk by r51768, but haven't heard of anything else about it. From what I can see it changes shell32 from C to C++, which looks like a good move. Problematic seems to me that it is completely out of sync with trunk's shell32 (judging from the translations alone). It might also be annoying for merging future patches, since the C to C++ move changes the code substantially. So are there any plans concering shell32_new? Do I have to merge all code changes in C and C++ or is shell32(_old) going to be dumped anytime soon? Best regards, Gregor

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 51813: [MSPORTS] - Implement a simple class installer that assigns the friendly name "Serial Port (COMx)" to all serial ports. - Enable the class installer in ports.inf. - Add parallel port...
by Alex Ionescu 18 May '11

18 May '11

The source code for msports is already available in the DDK. -- Best regards, Alex Ionescu On 2011-05-17, at 3:24 PM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Tue May 17 19:24:19 2011 > New Revision: 51813 > > URL: http://svn.reactos.org/svn/reactos?rev=51813&view=rev > Log: > [MSPORTS] > - Implement a simple class installer that assigns the friendly name "Serial Port (COMx)" to all serial ports. > - Enable the class installer in ports.inf. > - Add parallel port installer configuration to ports.inf (disabled). > > Added: > trunk/reactos/dll/win32/msports/ (with props) > trunk/reactos/dll/win32/msports/CMakeLists.txt (with props) > trunk/reactos/dll/win32/msports/classinst.c (with props) > trunk/reactos/dll/win32/msports/msports.c (with props) > trunk/reactos/dll/win32/msports/msports.rbuild (with props) > trunk/reactos/dll/win32/msports/msports.rc (with props) > trunk/reactos/dll/win32/msports/msports.spec (with props) > Modified: > trunk/reactos/baseaddress.cmake > trunk/reactos/baseaddress.rbuild > trunk/reactos/boot/bootdata/packages/reactos.dff > trunk/reactos/dll/win32/CMakeLists.txt > trunk/reactos/dll/win32/win32.rbuild > trunk/reactos/media/inf/ports.inf > > Modified: trunk/reactos/baseaddress.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/baseaddress.cmake?rev=5181… > ============================================================================== > --- trunk/reactos/baseaddress.cmake [iso-8859-1] (original) > +++ trunk/reactos/baseaddress.cmake [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -49,6 +49,7 @@ > set(baseaddress_netid 0x5f660000) > set(baseaddress_ntprint 0x5f6a0000) > set(baseaddress_mssip32 0x60430000) > +set(baseaddress_msports 0x60450000) > set(baseaddress_msisip 0x60b10000) > set(baseaddress_inseng 0x61000000) > set(baseaddress_qedit 0x611c0000) > > Modified: trunk/reactos/baseaddress.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/baseaddress.rbuild?rev=518… > ============================================================================== > --- trunk/reactos/baseaddress.rbuild [iso-8859-1] (original) > +++ trunk/reactos/baseaddress.rbuild [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -52,6 +52,7 @@ > <property name="BASEADDRESS_NETID" value="0x5f660000" /> > <property name="BASEADDRESS_NTPRINT" value="0x5f6a0000" /> > <property name="BASEADDRESS_MSSIP32" value="0x60430000" /> > + <property name="BASEADDRESS_MSPORTS" value="0x60450000" /> > <property name="BASEADDRESS_MSISIP" value="0x60b10000" /> > <property name="BASEADDRESS_INSENG" value="0x61000000" /> > <property name="BASEADDRESS_QEDIT" value="0x611c0000" /> > > Modified: trunk/reactos/boot/bootdata/packages/reactos.dff > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/packages/rea… > ============================================================================== > --- trunk/reactos/boot/bootdata/packages/reactos.dff [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/packages/reactos.dff [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -357,6 +357,7 @@ > dll\win32\msisip\msisip.dll 1 > dll\win32\msisys.ocx\msisys.ocx 1 > dll\win32\msnet32\msnet32.dll 1 > +dll\win32\msports\msports.dll 1 > dll\win32\msrle32\msrle32.dll 1 > dll\win32\mssign32\mssign32.dll 1 > dll\win32\mssip32\mssip32.dll 1 > > Modified: trunk/reactos/dll/win32/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/CMakeLists.txt?r… > ============================================================================== > --- trunk/reactos/dll/win32/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/CMakeLists.txt [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -99,6 +99,7 @@ > add_subdirectory(msisip) > add_subdirectory(msisys.ocx) > #add_subdirectory(msnet32) #to be deleted in trunk. > +add_subdirectory(msports) > add_subdirectory(msrle32) > add_subdirectory(mssign32) > add_subdirectory(mssip32) > > Propchange: trunk/reactos/dll/win32/msports/ > ------------------------------------------------------------------------------ > --- bugtraq:logregex (added) > +++ bugtraq:logregex Tue May 17 19:24:19 2011 > @@ -1,0 +1,2 @@ > +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? > +(\d+) > > Propchange: trunk/reactos/dll/win32/msports/ > ------------------------------------------------------------------------------ > bugtraq:message = See issue #%BUGID% for more details. > > Propchange: trunk/reactos/dll/win32/msports/ > ------------------------------------------------------------------------------ > bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID% > > Propchange: trunk/reactos/dll/win32/msports/ > ------------------------------------------------------------------------------ > tsvn:logminsize = 10 > > Added: trunk/reactos/dll/win32/msports/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/CMakeLis… > ============================================================================== > --- trunk/reactos/dll/win32/msports/CMakeLists.txt (added) > +++ trunk/reactos/dll/win32/msports/CMakeLists.txt [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -1,0 +1,24 @@ > + > +set_unicode() > + > +spec2def(msports.dll msports.spec) > + > +list(APPEND SOURCE > + classinst.c > + msports.c > + parallel.c > + serial.c > + msports.rc > + ${CMAKE_CURRENT_BINARY_DIR}/msports_stubs.c > + ${CMAKE_CURRENT_BINARY_DIR}/msports.def) > + > +add_library(msports SHARED ${SOURCE}) > + > +set_module_type(msports win32dll) > + > +target_link_libraries(msports wine) > + > +add_importlibs(msports comctl32 setupapi advapi32 user32 kernel32 ntdll) > + > +add_cd_file(TARGET msports DESTINATION reactos/system32 FOR all) > +add_importlib_target(msports.spec) > > Propchange: trunk/reactos/dll/win32/msports/CMakeLists.txt > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: trunk/reactos/dll/win32/msports/CMakeLists.txt > ------------------------------------------------------------------------------ > svn:keywords = author date id revision > > Added: trunk/reactos/dll/win32/msports/classinst.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/classins… > ============================================================================== > --- trunk/reactos/dll/win32/msports/classinst.c (added) > +++ trunk/reactos/dll/win32/msports/classinst.c [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -1,0 +1,250 @@ > +/* > + * PROJECT: ReactOS system libraries > + * LICENSE: GPL - See COPYING in the top level directory > + * FILE: dlls\win32\msports\classinst.c > + * PURPOSE: Ports class installer > + * PROGRAMMERS: Copyright 2011 Eric Kohl > + */ > + > +#include <windows.h> > +#include <setupapi.h> > +#include <wine/debug.h> > + > +WINE_DEFAULT_DEBUG_CHANNEL(msports); > + > + > +typedef enum _PORT_TYPE > +{ > + UnknownPort, > + ParallelPort, > + SerialPort > +} PORT_TYPE; > + > + > +static DWORD > +InstallSerialPort(IN HDEVINFO DeviceInfoSet, > + IN PSP_DEVINFO_DATA DeviceInfoData) > +{ > + LPWSTR pszFriendlyName = L"Serial Port (COMx)"; > + > + TRACE("InstallSerialPort(%p, %p)\n", > + DeviceInfoSet, DeviceInfoData); > + > + /* Install the device */ > + if (!SetupDiInstallDevice(DeviceInfoSet, > + DeviceInfoData)) > + { > + return GetLastError(); > + } > + > + /* Set the friendly name for the device */ > + SetupDiSetDeviceRegistryPropertyW(DeviceInfoSet, > + DeviceInfoData, > + SPDRP_FRIENDLYNAME, > + (LPBYTE)pszFriendlyName, > + (wcslen(pszFriendlyName) + 1) * sizeof(WCHAR)); > + > + return ERROR_SUCCESS; > +} > + > + > +static DWORD > +InstallParallelPort(IN HDEVINFO DeviceInfoSet, > + IN PSP_DEVINFO_DATA DeviceInfoData) > +{ > + FIXME("InstallParallelPort(%p, %p)\n", > + DeviceInfoSet, DeviceInfoData); > + return ERROR_DI_DO_DEFAULT; > +} > + > + > +VOID > +InstallDeviceData(IN HDEVINFO DeviceInfoSet, > + IN PSP_DEVINFO_DATA DeviceInfoData OPTIONAL) > +{ > + HKEY hKey = NULL; > + HINF hInf = INVALID_HANDLE_VALUE; > + SP_DRVINFO_DATA DriverInfoData; > + PSP_DRVINFO_DETAIL_DATA DriverInfoDetailData; > + WCHAR InfSectionWithExt[256]; > + BYTE buffer[2048]; > + DWORD dwRequired; > + > + TRACE("InstallDeviceData()\n"); > + > + hKey = SetupDiCreateDevRegKeyW(DeviceInfoSet, > + DeviceInfoData, > + DICS_FLAG_GLOBAL, > + 0, > + DIREG_DRV, > + NULL, > + NULL); > + if (hKey == NULL) > + goto done; > + > + DriverInfoData.cbSize = sizeof(SP_DRVINFO_DATA); > + if (!SetupDiGetSelectedDriverW(DeviceInfoSet, > + DeviceInfoData, > + &DriverInfoData)) > + { > + goto done; > + } > + > + DriverInfoDetailData = (PSP_DRVINFO_DETAIL_DATA)buffer; > + DriverInfoDetailData->cbSize = sizeof(SP_DRVINFO_DETAIL_DATA); > + if (!SetupDiGetDriverInfoDetailW(DeviceInfoSet, > + DeviceInfoData, > + &DriverInfoData, > + DriverInfoDetailData, > + 2048, > + &dwRequired)) > + { > + if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) > + goto done; > + } > + > + TRACE("Inf file name: %S\n", DriverInfoDetailData->InfFileName); > + > + hInf = SetupOpenInfFileW(DriverInfoDetailData->InfFileName, > + NULL, > + INF_STYLE_WIN4, > + NULL); > + if (hInf == INVALID_HANDLE_VALUE) > + goto done; > + > + TRACE("Section name: %S\n", DriverInfoDetailData->SectionName); > + > + SetupDiGetActualSectionToInstallW(hInf, > + DriverInfoDetailData->SectionName, > + InfSectionWithExt, > + 256, > + NULL, > + NULL); > + > + TRACE("InfSectionWithExt: %S\n", InfSectionWithExt); > + > + SetupInstallFromInfSectionW(NULL, > + hInf, > + InfSectionWithExt, > + SPINST_REGISTRY, > + hKey, > + NULL, > + 0, > + NULL, > + NULL, > + NULL, > + NULL); > + > + TRACE("Done\n"); > + > +done:; > + if (hKey != NULL) > + RegCloseKey(hKey); > + > + if (hInf != INVALID_HANDLE_VALUE) > + SetupCloseInfFile(hInf); > +} > + > + > + > +PORT_TYPE > +GetPortType(IN HDEVINFO DeviceInfoSet, > + IN PSP_DEVINFO_DATA DeviceInfoData) > +{ > + HKEY hKey = NULL; > + DWORD dwSize; > + DWORD dwType = 0; > + BYTE bData = 0; > + PORT_TYPE PortType = UnknownPort; > + LONG lError; > + > + TRACE("GetPortType()\n"); > + > + hKey = SetupDiCreateDevRegKeyW(DeviceInfoSet, > + DeviceInfoData, > + DICS_FLAG_GLOBAL, > + 0, > + DIREG_DRV, > + NULL, > + NULL); > + if (hKey == NULL) > + { > + goto done; > + } > + > + dwSize = sizeof(BYTE); > + lError = RegQueryValueExW(hKey, > + L"PortSubClass", > + NULL, > + &dwType, > + &bData, > + &dwSize); > + > + TRACE("lError: %ld\n", lError); > + TRACE("dwSize: %lu\n", dwSize); > + TRACE("dwType: %lu\n", dwType); > + > + if (lError == ERROR_SUCCESS && > + dwSize == sizeof(BYTE) && > + dwType == REG_BINARY) > + { > + if (bData == 0) > + PortType = ParallelPort; > + else > + PortType = SerialPort; > + } > + > +done:; > + if (hKey != NULL) > + RegCloseKey(hKey); > + > + TRACE("GetPortType() returns %u \n", PortType); > + > + return PortType; > +} > + > + > +static DWORD > +InstallPort(IN HDEVINFO DeviceInfoSet, > + IN PSP_DEVINFO_DATA DeviceInfoData) > +{ > + PORT_TYPE PortType; > + > + InstallDeviceData(DeviceInfoSet, DeviceInfoData); > + > + PortType = GetPortType(DeviceInfoSet, DeviceInfoData); > + switch (PortType) > + { > + case ParallelPort: > + return InstallParallelPort(DeviceInfoSet, DeviceInfoData); > + > + case SerialPort: > + return InstallSerialPort(DeviceInfoSet, DeviceInfoData); > + > + default: > + return ERROR_DI_DO_DEFAULT; > + } > +} > + > + > +DWORD > +WINAPI > +PortsClassInstaller(IN DI_FUNCTION InstallFunction, > + IN HDEVINFO DeviceInfoSet, > + IN PSP_DEVINFO_DATA DeviceInfoData OPTIONAL) > +{ > + TRACE("PortsClassInstaller(%lu, %p, %p)\n", > + InstallFunction, DeviceInfoSet, DeviceInfoData); > + > + switch (InstallFunction) > + { > + case DIF_INSTALLDEVICE: > + return InstallPort(DeviceInfoSet, DeviceInfoData); > + > + default: > + TRACE("Install function %u ignored\n", InstallFunction); > + return ERROR_DI_DO_DEFAULT; > + } > +} > + > +/* EOF */ > > Propchange: trunk/reactos/dll/win32/msports/classinst.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: trunk/reactos/dll/win32/msports/classinst.c > ------------------------------------------------------------------------------ > svn:keywords = author date id revision > > Added: trunk/reactos/dll/win32/msports/msports.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/msports.… > ============================================================================== > --- trunk/reactos/dll/win32/msports/msports.c (added) > +++ trunk/reactos/dll/win32/msports/msports.c [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -1,0 +1,33 @@ > +/* > + * PROJECT: Ports installer library > + * LICENSE: GPL - See COPYING in the top level directory > + * FILE: dll/win32/msports/msports.c > + * PURPOSE: Library main function > + * COPYRIGHT: Copyright 2011 Eric Kohl > + */ > + > +#include <windows.h> > +#include <wine/debug.h> > + > + > +WINE_DEFAULT_DEBUG_CHANNEL(msports); > + > + > +BOOL > +WINAPI > +DllMain(HINSTANCE hinstDll, > + DWORD dwReason, > + LPVOID reserved) > +{ > + switch (dwReason) > + { > + case DLL_PROCESS_ATTACH: > + TRACE("DLL_PROCESS_ATTACH\n"); > + DisableThreadLibraryCalls(hinstDll); > + break; > + } > + > + return TRUE; > +} > + > +/* EOF */ > > Propchange: trunk/reactos/dll/win32/msports/msports.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: trunk/reactos/dll/win32/msports/msports.c > ------------------------------------------------------------------------------ > svn:keywords = author date id revision > > Added: trunk/reactos/dll/win32/msports/msports.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/msports.… > ============================================================================== > --- trunk/reactos/dll/win32/msports/msports.rbuild (added) > +++ trunk/reactos/dll/win32/msports/msports.rbuild [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -1,0 +1,11 @@ > +<module name="msports" type="win32dll" baseaddress="${BASEADDRESS_MSPORTS}" installbase="system32" installname="msports.dll" unicode="yes"> > + <include base="msports">.</include> > + <importlibrary definition="msports.spec" /> > + <library>wine</library> > + <library>kernel32</library> > + <library>advapi32</library> > + <library>setupapi</library> > + <file>classinst.c</file> > + <file>msports.c</file> > + <file>msports.rc</file> > +</module> > > Propchange: trunk/reactos/dll/win32/msports/msports.rbuild > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: trunk/reactos/dll/win32/msports/msports.rbuild > ------------------------------------------------------------------------------ > svn:keywords = author date id revision > > Added: trunk/reactos/dll/win32/msports/msports.rc > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/msports.… > ============================================================================== > --- trunk/reactos/dll/win32/msports/msports.rc (added) > +++ trunk/reactos/dll/win32/msports/msports.rc [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -1,0 +1,7 @@ > +#include <windows.h> > + > +#define REACTOS_VERSION_DLL > +#define REACTOS_STR_FILE_DESCRIPTION "Ports Class Installer\0" > +#define REACTOS_STR_INTERNAL_NAME "msports\0" > +#define REACTOS_STR_ORIGINAL_FILENAME "msports.dll\0" > +#include <reactos/version.rc> > > Propchange: trunk/reactos/dll/win32/msports/msports.rc > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: trunk/reactos/dll/win32/msports/msports.rc > ------------------------------------------------------------------------------ > svn:keywords = author date id revision > > Added: trunk/reactos/dll/win32/msports/msports.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msports/msports.… > ============================================================================== > --- trunk/reactos/dll/win32/msports/msports.spec (added) > +++ trunk/reactos/dll/win32/msports/msports.spec [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -1,0 +1,12 @@ > +@ stub ComDBClaimNextFreePort > +@ stub ComDBClaimPort > +@ stub ComDBClose > +@ stub ComDBGetCurrentPortUsage > +@ stub ComDBOpen > +@ stub ComDBReleasePort > +@ stub ComDBResizeDatabase > +@ stdcall LibMain(ptr long ptr) DllMain > +@ stub ParallelPortPropPageProvider > +@ stdcall PortsClassInstaller(long ptr ptr) > +@ stub SerialDisplayAdvancedSettings > +@ stub SerialPortPropPageProvider > > Propchange: trunk/reactos/dll/win32/msports/msports.spec > ------------------------------------------------------------------------------ > svn:eol-style = native > > Propchange: trunk/reactos/dll/win32/msports/msports.spec > ------------------------------------------------------------------------------ > svn:keywords = author date id revision > > Modified: trunk/reactos/dll/win32/win32.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/win32.rbuild?rev… > ============================================================================== > --- trunk/reactos/dll/win32/win32.rbuild [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/win32.rbuild [iso-8859-1] Tue May 17 19:24:19 2011 > @@ -295,6 +295,9 @@ > <directory name="msnet32"> > <xi:include href="msnet32/msnet32.rbuild" /> > </directory> > +<directory name="msports"> > + <xi:include href="msports/msports.rbuild" /> > +</directory> > <directory name="msrle32"> > <xi:include href="msrle32/msrle32.rbuild" /> > </directory> > > Modified: trunk/reactos/media/inf/ports.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/media/inf/ports.inf?rev=51… > ============================================================================== > Binary files - no diff available. > >

2 2

msports commit (51813) - CMakeLists.txt references nonexistent files
by Adam 18 May '11

18 May '11

When I was trying to build trunk (using Cmake) the configure.cmd did not complete. Host tools were OK but reactos directory was not. I tracked the issue to /dll/win32/msports/CMakeLists.txt which contained references to two nonexistent files (serial.c and parallel.c) and commenting them out allowed the build to continue (albeit with an error at the very end) there.

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 51748: [NTOSKRNL] Patch by Paolo Bonzini <bonzini [at] gnu [dot] org> Fix implementation of ExInterlockedAddLargeStatistic The old version wasn't really atomic. See issue #6223 for more ...
by Alex Ionescu 15 May '11

15 May '11

Congrats on once again breaking another key part of Windows compatibility. This function is DOCUMENTED to tear. It was DESIGNED that way on purpose. Utter failure, once more. Best regards, Alex Ionescu On Sat, May 14, 2011 at 12:29 PM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Sat May 14 19:29:42 2011 > New Revision: 51748 > > URL: http://svn.reactos.org/svn/reactos?rev=51748&view=rev > Log: > [NTOSKRNL] > Patch by Paolo Bonzini <bonzini [at] gnu [dot] org> > Fix implementation of ExInterlockedAddLargeStatistic > The old version wasn't really atomic. > > See issue #6223 for more details. > > Modified: > trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S > > Modified: trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/i386/fastinter… > > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S [iso-8859-1] > (original) > +++ trunk/reactos/ntoskrnl/ex/i386/fastinterlck_asm.S [iso-8859-1] Sat May > 14 19:29:42 2011 > @@ -4,8 +4,9 @@ > * FILE: ntoskrnl/ex/i386/fastinterlck_asm.S > * PURPOSE: FASTCALL Interlocked Functions > * PROGRAMMERS: Alex Ionescu (alex(a)relsoft.net) > - */ > - > + * Paolo Bonzini <bonzini [at] gnu [dot] org> > + */ > + > /* INCLUDES > ******************************************************************/ > > #include <asm.inc> > @@ -31,25 +32,55 @@ > */ > PUBLIC @ExInterlockedAddLargeStatistic@8 > @ExInterlockedAddLargeStatistic@8: > - > -#ifdef CONFIG_SMP > - /* Do the addition */ > - lock add [ecx], edx > - > - /* Check for carry bit and return */ > - jb .l1 > - ret > - > -.l1: > - /* Add carry */ > - lock adc dword ptr [ecx+4], 0 > -#else > - /* Do the addition and add the carry */ > - add dword ptr [ecx], edx > - adc dword ptr [ecx+4], 0 > -#endif > - /* Return */ > - ret > + push ebp > + push ebx > + mov ebp, ecx > + > +Again: > + /* Load comparand in eax for cmpxchg */ > + mov eax, [ebp] > + > + /* Compute low word of the result in ebx */ > + mov ebx, edx > + add ebx, eax > + > + /* Carry needs cmpxchg8b */ > + jc Slow > + > + /* Fast path still needs to be atomic, so use cmpxchg and retry if it > fails > + * Hopefully it will still get through this path :) */ > + LOCK cmpxchg [ecx], ebx > + jnz Again > + > + /* Thats it */ > + pop ebx > + pop ebp > + ret > + > +Slow: > + /* Save increment across cmpxchg8b */ > + push edx > + > + /* Finish loading comparand in edx:eax */ > + mov edx, [ebp+4] > + > + /* Result in ecx:ebx (we know there's carry) */ > + lea ecx, [edx+1] > + > + /* Do a full exchange */ > + LOCK cmpxchg8b [ebp] > + > + /* restore increment */ > + pop edx > + > + /* Need to retry */ > + jnz Again > + > + /* Thats it */ > + pop ebx > + pop ebp > + ret > + > > /*ULONG > *FASTCALL > > >

2 4

Current patch review assignment
by Olaf Siejka 15 May '11

15 May '11

Hiya Attached, you will find a rough draft of current patch assignment proposals. I`m trying to keep it in realtime, so several of those are already in place. As usual, please comment if you find you shouldn't be reviewing assigned patch. Best regards

1 0

Compatibility List moderation
by Javier Agustìn Fernàndez Arroyo 09 May '11

09 May '11

Speaking about bug reports drama, im still watching how there are several people that are still sending totally useless compatibility test results to ROS database... I want to ask for a moderation system for that, and i would want to offer myself to moderate new incoming results, such as Wine system....

4 5

Re: [ros-dev] [EVENTVWR/EVENTLOG] Fix a double off-by-one bug
by Love Nystrom 08 May '11

08 May '11

Hi Eric, Sounds like you got it licked, the right way. Good job ! Best Regards L. 2011/5/6 <ros-dev-request(a)reactos.org> > From: Eric Kohl <eric.kohl(a)t-online.de> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Thu, 05 May 2011 22:41:24 +0200 > Subject: Re: [ros-dev] [EVENTVWR/EVENTLOG] Fix a double off-by-one bug > Hi Love, > > I just committed a fix for the calculation of the available number of event > records. It addresses the issues you mentioned. > > And this is how it works: > When a new log file is created, the first (or oldest) record gets the > record number 1. With each new event record the record number is incremented > by 1. To get the number of records in the log file we need to subtract the > OldestRecordNumber from the CurrentRecordNumber. If the log file is empty > the OldestRecordNumber will be 0. In this case we will return 0 for the > number of event records. > > Now we call clear a filled log file and fill it with new records. The > oldest record will not be record number 1 but we can still return the true > number of records in the log file. > > > Regards > Eric >

1 0

Re: [ros-dev] [freeldr] Add PXE "filesystem" (Aleksey Bragin)
by Love Nystrom 08 May '11

08 May '11

Hi Aleksey, I'm sorry if my opinion came across as critique of the work as such. It was definitely not intended that way. I have great respect for all your efforts. Just a point about unfortunate choice of AT&T syntax. I would gladly volunteer to translate all old AT&T code to Intel. After all, I do have 25 years of expertise in assembly coding. It's just that I'm completely bogged down by R.L and have no time. But if it can wait, just leave it be, and I'll do it later. I'm sure Timo has enough to do with other issues already. I abbreviated the pro's and con's to just two points, of which the 2nd applies just to gcc's inline asm syntax. Translating non-inline AT&T to Intel is fairly straight forward. InvalidateHarshMode(TRUE); No offence taken. Best Regards L. On 2011-05-05 14.58, "Aleksey Bragin" <aleksey(a)reactos.org> wrote: > SetHarshMode(TRUE); > > Your opinion would be interesting if it was motivated by your knowledge and experience in writing assembly > in both AT&T and Intel syntax, so that you could provide us pros and cons of each approach by your judgement. > > Or, if you would be author of that code part in ReactOS. > > Otherwise, I’m afraid, it’s just criticizing a very good work, didn’t even noticing the great PXE milestone, > but nitpicking to a syntax. Don’t join complaints if you can’t fix it. (Timo’s point is valid because that’s him who actually > converts this stuff!) > > SetHarshMode(FALSE); > > WBR, > Aleksey.

2 1

ReactOS YouTube Channel
by Adam 08 May '11

08 May '11

I noticed this YouTube channel here - http://www.youtube.com/reactosorg - and apparently it seems to have 3 videos about ReactOS on it. Nothing seems to be uploaded to it for a little over 1 year and I was wondering perhaps it wouldn't be a bad idea to upload some videos about various events to it. I suspect a major issue with the lack of developers is lack of publicity and I think this seems like a good opportunity. (note I am not sure if it is the official ReactOS channel or not - if not time to make one - apparently it seems the person who made the channel is displaying the Age as 16 years old)

2 1

Apologies
by Olaf Siejka 07 May '11

07 May '11

I am sorry to Vicmarcal for outbursting on ros-dev. The reason for that was yet another pointless bugreport, after my requestes, passed several times, regarding bug reports quality. Sorry, Vicmarcal, as well as those who had to witness it. Regards

3 2

Vicmarcal - are you mad?
by Olaf Siejka 06 May '11

06 May '11

Bugzilla is crowded with untouched bugs for so long, and you HAVE to add more crud to it? Bugs like no.6214, very usefull as we can see below: "1)Download ClickToDesktop 2)Run in ReactOS 3)Click on the desktop to hide. It doesn't work. Apps just lost the focus. Nothing appears in the DebugLog." Now that is informative... Why dont you get back doing something useful for a change?

8 13

Re: [ros-dev] [EVENTVWR/EVENTLOG] Fix a double off-by-one bug
by Love Nystrom 05 May '11

05 May '11

Hi Gabriel, Eric, Isn't the real issue why LogFile->Header.CurrentRecordNumber is off by one ? If that is found and fixed, this patch will make the error re-emerge as an off by -1. And if CurrentRecordNumber is actually used as the next *pending* record number, the identifier is somewhat mis-leading .. ? Just my penny to the pot Best Regards L. ---------- Forwarded message ---------- > From: Gabriel ilardi <gabrielilardi(a)hotmail.it> > To: ros-dev <ros-dev(a)reactos.org> > Date: Mon, 2 May 2011 21:50:03 +0200 > Subject: Re: [ros-dev] [ros-diffs] [ekohl] 51558: [EVENTVWR/EVENTLOG] Fix a > double off-by-one bug: - The eventlog service was reporting one event more > than was available (+1). - The event viewer did not display the latest event > from... > Great work on event service and event viewer... keep it up Eric :) > > > > Date: Mon, 2 May 2011 19:38:24 +0000 > > To: ros-diffs(a)reactos.org > > From: ekohl(a)svn.reactos.org > > Subject: [ros-diffs] [ekohl] 51558: [EVENTVWR/EVENTLOG] Fix a double > off-by-one bug: - The eventlog service was reporting one event more than was > available (+1). - The event viewer did not display the latest event from... > > > > Author: ekohl > > Date: Mon May 2 19:38:23 2011 > > New Revision: 51558 > > > > URL: http://svn.reactos.org/svn/reactos?rev=51558&view=rev > > Log: > > [EVENTVWR/EVENTLOG] > > Fix a double off-by-one bug: > > - The eventlog service was reporting one event more than was available > (+1). > > - The event viewer did not display the latest event from the eventlog > service (-1). > > > > See issue #6182 for more details. > > > > Modified: > > trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c > > trunk/reactos/base/services/eventlog/rpc.c > > > > Modified: trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c > > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils… > > > ============================================================================== > > --- trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c > [iso-8859-1] (original) > > +++ trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c > [iso-8859-1] Mon May 2 19:38:23 2011 > > @@ -503,7 +503,7 @@ > > HWND hwndDlg; > > HANDLE hEventLog; > > EVENTLOGRECORD *pevlr; > > - DWORD dwRead, dwNeeded, dwThisRecord, dwTotalRecords = 0, > dwCurrentRecord = 1, dwRecordsToRead = 0, dwFlags, dwMaxLength; > > + DWORD dwRead, dwNeeded, dwThisRecord, dwTotalRecords = 0, > dwCurrentRecord = 0, dwRecordsToRead = 0, dwFlags, dwMaxLength; > > LPWSTR lpSourceName; > > LPWSTR lpComputerName; > > LPSTR lpData; > > > > Modified: trunk/reactos/base/services/eventlog/rpc.c > > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/eventlog/rpc… > > > ============================================================================== > > --- trunk/reactos/base/services/eventlog/rpc.c [iso-8859-1] (original) > > +++ trunk/reactos/base/services/eventlog/rpc.c [iso-8859-1] Mon May 2 > 19:38:23 2011 > > @@ -199,6 +199,7 @@ > > DWORD *NumberOfRecords) > > { > > PLOGHANDLE lpLogHandle; > > + DWORD dwRecords; > > > > lpLogHandle = ElfGetLogHandleEntryByHandle(LogHandle); > > if (!lpLogHandle) > > @@ -206,7 +207,9 @@ > > return STATUS_INVALID_HANDLE; > > } > > > > - *NumberOfRecords = lpLogHandle->LogFile->Header.CurrentRecordNumber; > > + dwRecords = lpLogHandle->LogFile->Header.CurrentRecordNumber; > > + > > + *NumberOfRecords = (dwRecords > 0) ? (dwRecords - 1) : 0; > > > > return STATUS_SUCCESS; > > } > > > > >

2 1

Re: [ros-dev] [freeldr] Add PXE "filesystem" (Ged Murphy)
by Love Nystrom 05 May '11

05 May '11

Hi Ged, Yes of course I read Hervé's mail. I did not suggest that he should go about porting existing code, I just expressed my opinion that we shouldn't use AT&T for new code. As for porting the existing freeldr AT&T code, I guess I could, eventually, when I get time, if I can just get a firm enough grip on the AT&T directive voodoo, which is obscure. But in the short run, no, sorry, I'm really bogged down by RL :( (It's even hard to try and keep up with the mailing list) You wouldn't happen to have a good pointer for that obscure AT&T string voodoo? Best Regards L. On Tue, May 3, 2011 at 11:12 PM, <ros-dev-request(a)reactos.org> wrote: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > Today's Topics: > > 1. Re: [EVENTVWR/EVENTLOG] Fix a double off-by-one bug (Love Nystrom) > 2. Re: [freeldr] Add PXE "filesystem" (Love Nystrom) > 3. Re: [freeldr] Add PXE "filesystem" (Ged Murphy) > > > ---------- Forwarded message ---------- > From: Love Nystrom <love.nystrom(a)gmail.com> > To: ros-dev(a)reactos.org > Date: Tue, 3 May 2011 21:52:40 +0700 > Subject: Re: [ros-dev] [EVENTVWR/EVENTLOG] Fix a double off-by-one bug > > Hi Gabriel, Eric, > > Isn't the real issue why LogFile->Header.CurrentRecordNumber is off by one > ? > If that is found and fixed, this patch will make the error re-emerge as an > off by -1. > And if CurrentRecordNumber is actually used as the next *pending* record > number, > the identifier is somewhat mis-leading .. ? > > Just my penny to the pot > Best Regards > L. > > ---------- Forwarded message ---------- >> From: Gabriel ilardi <gabrielilardi(a)hotmail.it> >> To: ros-dev <ros-dev(a)reactos.org> >> Date: Mon, 2 May 2011 21:50:03 +0200 >> Subject: Re: [ros-dev] [ros-diffs] [ekohl] 51558: [EVENTVWR/EVENTLOG] Fix >> a double off-by-one bug: - The eventlog service was reporting one event more >> than was available (+1). - The event viewer did not display the latest event >> from... >> Great work on event service and event viewer... keep it up Eric :) >> >> >> > Date: Mon, 2 May 2011 19:38:24 +0000 >> > To: ros-diffs(a)reactos.org >> > From: ekohl(a)svn.reactos.org >> > Subject: [ros-diffs] [ekohl] 51558: [EVENTVWR/EVENTLOG] Fix a double >> off-by-one bug: - The eventlog service was reporting one event more than was >> available (+1). - The event viewer did not display the latest event from... >> > >> > Author: ekohl >> > Date: Mon May 2 19:38:23 2011 >> > New Revision: 51558 >> > >> > URL: http://svn.reactos.org/svn/reactos?rev=51558&view=rev >> > Log: >> > [EVENTVWR/EVENTLOG] >> > Fix a double off-by-one bug: >> > - The eventlog service was reporting one event more than was available >> (+1). >> > - The event viewer did not display the latest event from the eventlog >> service (-1). >> > >> > See issue #6182 for more details. >> > >> > Modified: >> > trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c >> > trunk/reactos/base/services/eventlog/rpc.c >> > >> > Modified: trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c >> > URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils… >> > >> ============================================================================== >> > --- trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c >> [iso-8859-1] (original) >> > +++ trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c >> [iso-8859-1] Mon May 2 19:38:23 2011 >> > @@ -503,7 +503,7 @@ >> > HWND hwndDlg; >> > HANDLE hEventLog; >> > EVENTLOGRECORD *pevlr; >> > - DWORD dwRead, dwNeeded, dwThisRecord, dwTotalRecords = 0, >> dwCurrentRecord = 1, dwRecordsToRead = 0, dwFlags, dwMaxLength; >> > + DWORD dwRead, dwNeeded, dwThisRecord, dwTotalRecords = 0, >> dwCurrentRecord = 0, dwRecordsToRead = 0, dwFlags, dwMaxLength; >> > LPWSTR lpSourceName; >> > LPWSTR lpComputerName; >> > LPSTR lpData; >> > >> > Modified: trunk/reactos/base/services/eventlog/rpc.c >> > URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/eventlog/rpc… >> > >> ============================================================================== >> > --- trunk/reactos/base/services/eventlog/rpc.c [iso-8859-1] (original) >> > +++ trunk/reactos/base/services/eventlog/rpc.c [iso-8859-1] Mon May 2 >> 19:38:23 2011 >> > @@ -199,6 +199,7 @@ >> > DWORD *NumberOfRecords) >> > { >> > PLOGHANDLE lpLogHandle; >> > + DWORD dwRecords; >> > >> > lpLogHandle = ElfGetLogHandleEntryByHandle(LogHandle); >> > if (!lpLogHandle) >> > @@ -206,7 +207,9 @@ >> > return STATUS_INVALID_HANDLE; >> > } >> > >> > - *NumberOfRecords = lpLogHandle->LogFile->Header.CurrentRecordNumber; >> > + dwRecords = lpLogHandle->LogFile->Header.CurrentRecordNumber; >> > + >> > + *NumberOfRecords = (dwRecords > 0) ? (dwRecords - 1) : 0; >> > >> > return STATUS_SUCCESS; >> > } >> > >> > >> > > > > ---------- Forwarded message ---------- > From: Love Nystrom <love.nystrom(a)gmail.com> > To: ros-dev(a)reactos.org > Date: Tue, 3 May 2011 22:35:30 +0700 > Subject: Re: [ros-dev] [freeldr] Add PXE "filesystem" > > Hi Hervé, > > No disrespect for your work, but I'm inclined to concur with Timo regrading > AT&T vs. Intel. > > Even though I usually preach "don't fix it if it isn't broken', I really > think that AT&T syntax > is broken by design, and we should use only Intel assembly, which is *much* > clearer. > After all, we're programming Intel CPU's, not AT&T telephone switchboards > ;) > > 1) AT&T does not conform with Intel instruction reference. > Intel syntax conforms with the instruction reference. > > 2) AT&T has a lot of quaint obscure directive voodoo. > What little directives exist in Intel is clear and concise. > > Eventually, I hope we'll get rid of all backwards & muddy AT&T assembly, > but until then I think we should at least not use it for new code. > > Best Regards > L. > > > ---------- Forwarded message ---------- >> From: "Hervé Poussineau" <hpoussin(a)reactos.org> >> To: ReactOS Development List <ros-dev(a)reactos.org> >> Date: Mon, 02 May 2011 19:33:19 +0200 >> Subject: Re: [ros-dev] [ros-diffs] [hpoussin] 51517: [freeldr] Add PXE >> "filesystem" >> Hi, >> >> The file is in AT&T syntax, as all asm files in >> reactos/boot/freeldr/freeldr/arch/i386/ , except fathelp.asm >> Sorry, I won't "fix" it, so you'll have to find someone to do it. >> >> Regards, >> >> Hervé >> >> Timo Kreuzer a écrit : >> >>> >>> Why did you write the asm code in AT&T syntax? Its both ugly and breaks >>> compilation with MSVC. >>> I've spent quite some time converting all asm code to MSVC friendly intel >>> syntax. >>> Could you please fix that? >>> >>> Regards, >>> Timo >>> >>> Am 01.05.2011 10:11, schrieb hpoussin(a)svn.reactos.org: >>> >>>> Author: hpoussin >>>> Date: Sun May 1 08:11:43 2011 >>>> New Revision: 51517 >>>> >>>> URL: http://svn.reactos.org/svn/reactos?rev=51517&view=rev >>>> Log: >>>> [freeldr] Add PXE "filesystem" >>>> >>>> Added: >>>> trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (with >>>> props) >>>> trunk/reactos/boot/freeldr/freeldr/fs/pxe.c (with props) >>>> trunk/reactos/boot/freeldr/freeldr/include/arch/i386/pxe.h (with >>>> props) >>>> trunk/reactos/boot/freeldr/freeldr/include/fs/pxe.h (with props) >>>> Modified: >>>> trunk/reactos/boot/freeldr/freeldr/arch/i386/machpc.c >>>> trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c >>>> trunk/reactos/boot/freeldr/freeldr/freeldr_base.rbuild >>>> trunk/reactos/boot/freeldr/freeldr/freeldr_base64k.rbuild >>>> trunk/reactos/boot/freeldr/freeldr/fs/fs.c >>>> trunk/reactos/boot/freeldr/freeldr/include/arch/i386/hardware.h >>>> trunk/reactos/boot/freeldr/freeldr/include/arch/i386/machpc.h >>>> trunk/reactos/boot/freeldr/freeldr/include/freeldr.h >>>> >>>> Added: trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S >>>> URL: >>>> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… >>>> ============================================================================== >>>> >>>> --- trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (added) >>>> +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S [iso-8859-1] >>>> Sun May 1 08:11:43 2011 >>>> @@ -1,0 +1,97 @@ >>>> +/* >>>> + * FreeLoader >>>> + * Copyright (C) 2011 Hervé Poussineau >>>> + * >>>> + * This program is free software; you can redistribute it and/or >>>> modify >>>> + * it under the terms of the GNU General Public License as published >>>> by >>>> + * the Free Software Foundation; either version 2 of the License, or >>>> + * (at your option) any later version. >>>> + * >>>> + * This program is distributed in the hope that it will be useful, >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>> + * GNU General Public License for more details. >>>> + * >>>> + * You should have received a copy of the GNU General Public License >>>> along >>>> + * with this program; if not, write to the Free Software Foundation, >>>> Inc., >>>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. >>>> + */ >>>> + >>>> + .text >>>> + .code16 >>>> + >>>> +#define ASM >>>> + >>>> +#include<arch.h> >>>> + >>>> +/* >>>> + * U16 PxeCallApi(U16 Segment, U16 Offset, U16 Service, VOID >>>> *Parameter); >>>> + * >>>> + * RETURNS: >>>> + */ >>>> +_pxe_function: >>>> + .word 0 >>>> +_pxe_entry_point: >>>> + .long 0 >>>> +_pxe_buffer_segment: >>>> + .word0 >>>> +_pxe_buffer_offset: >>>> + .word0 >>>> +_pxe_result: >>>> + .word 0 >>>> + >>>> +EXTERN(_PxeCallApi) >>>> + .code32 >>>> + pushl %ebp >>>> + movl %esp,%ebp >>>> + >>>> + >>>> >>> > > > ---------- Forwarded message ---------- > From: "Ged Murphy" <gedmurphy(a)gmail.com> > To: "'ReactOS Development List'" <ros-dev(a)reactos.org> > Date: Tue, 3 May 2011 17:12:03 +0100 > Subject: Re: [ros-dev] [freeldr] Add PXE "filesystem" > > Did you read Herve’s email?? > > Are you volunteering to convert all the files he mentioned into intel > syntax? > > > > > > *From:* ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] *On > Behalf Of *Love Nystrom > *Sent:* 03 May 2011 16:36 > *To:* ros-dev(a)reactos.org > *Subject:* Re: [ros-dev] [freeldr] Add PXE "filesystem" > > > > > > Hi Hervé, > > > > No disrespect for your work, but I'm inclined to concur with Timo regrading > AT&T vs. Intel. > > > > Even though I usually preach "don't fix it if it isn't broken', I really > think that AT&T syntax > > is broken by design, and we should use only Intel assembly, which is *much* > clearer. > > After all, we're programming Intel CPU's, not AT&T telephone switchboards > ;) > > > > 1) AT&T does not conform with Intel instruction reference. > > Intel syntax conforms with the instruction reference. > > > > 2) AT&T has a lot of quaint obscure directive voodoo. > > What little directives exist in Intel is clear and concise. > > > > Eventually, I hope we'll get rid of all backwards & muddy AT&T assembly, > > but until then I think we should at least not use it for new code. > > > > Best Regards > > L. > > > > > > ---------- Forwarded message ---------- > From: "Hervé Poussineau" <hpoussin(a)reactos.org> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Mon, 02 May 2011 19:33:19 +0200 > Subject: Re: [ros-dev] [ros-diffs] [hpoussin] 51517: [freeldr] Add PXE > "filesystem" > Hi, > > The file is in AT&T syntax, as all asm files in > reactos/boot/freeldr/freeldr/arch/i386/ , except fathelp.asm > Sorry, I won't "fix" it, so you'll have to find someone to do it. > > Regards, > > Hervé > > Timo Kreuzer a écrit : > > > Why did you write the asm code in AT&T syntax? Its both ugly and breaks > compilation with MSVC. > I've spent quite some time converting all asm code to MSVC friendly intel > syntax. > Could you please fix that? > > Regards, > Timo > > Am 01.05.2011 10:11, schrieb hpoussin(a)svn.reactos.org: > > Author: hpoussin > Date: Sun May 1 08:11:43 2011 > New Revision: 51517 > > URL: http://svn.reactos.org/svn/reactos?rev=51517&view=rev > Log: > [freeldr] Add PXE "filesystem" > > Added: > trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (with props) > trunk/reactos/boot/freeldr/freeldr/fs/pxe.c (with props) > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/pxe.h (with > props) > trunk/reactos/boot/freeldr/freeldr/include/fs/pxe.h (with props) > Modified: > trunk/reactos/boot/freeldr/freeldr/arch/i386/machpc.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c > trunk/reactos/boot/freeldr/freeldr/freeldr_base.rbuild > trunk/reactos/boot/freeldr/freeldr/freeldr_base64k.rbuild > trunk/reactos/boot/freeldr/freeldr/fs/fs.c > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/hardware.h > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/machpc.h > trunk/reactos/boot/freeldr/freeldr/include/freeldr.h > > Added: trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (added) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S [iso-8859-1] Sun > May 1 08:11:43 2011 > @@ -1,0 +1,97 @@ > +/* > + * FreeLoader > + * Copyright (C) 2011 Hervé Poussineau > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > along > + * with this program; if not, write to the Free Software Foundation, > Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > + .text > + .code16 > + > +#define ASM > + > +#include<arch.h> > + > +/* > + * U16 PxeCallApi(U16 Segment, U16 Offset, U16 Service, VOID *Parameter); > + * > + * RETURNS: > + */ > +_pxe_function: > + .word 0 > +_pxe_entry_point: > + .long 0 > +_pxe_buffer_segment: > + .word0 > +_pxe_buffer_offset: > + .word0 > +_pxe_result: > + .word 0 > + > +EXTERN(_PxeCallApi) > + .code32 > + pushl %ebp > + movl %esp,%ebp > + > + > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

3 2

Re: [ros-dev] [freeldr] Add PXE "filesystem"
by Love Nystrom 04 May '11

04 May '11

Hi Hervé, No disrespect for your work, but I'm inclined to concur with Timo regrading AT&T vs. Intel. Even though I usually preach "don't fix it if it isn't broken', I really think that AT&T syntax is broken by design, and we should use only Intel assembly, which is *much* clearer. After all, we're programming Intel CPU's, not AT&T telephone switchboards ;) 1) AT&T does not conform with Intel instruction reference. Intel syntax conforms with the instruction reference. 2) AT&T has a lot of quaint obscure directive voodoo. What little directives exist in Intel is clear and concise. Eventually, I hope we'll get rid of all backwards & muddy AT&T assembly, but until then I think we should at least not use it for new code. Best Regards L. ---------- Forwarded message ---------- > From: "Hervé Poussineau" <hpoussin(a)reactos.org> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Mon, 02 May 2011 19:33:19 +0200 > Subject: Re: [ros-dev] [ros-diffs] [hpoussin] 51517: [freeldr] Add PXE > "filesystem" > Hi, > > The file is in AT&T syntax, as all asm files in > reactos/boot/freeldr/freeldr/arch/i386/ , except fathelp.asm > Sorry, I won't "fix" it, so you'll have to find someone to do it. > > Regards, > > Hervé > > Timo Kreuzer a écrit : > >> >> Why did you write the asm code in AT&T syntax? Its both ugly and breaks >> compilation with MSVC. >> I've spent quite some time converting all asm code to MSVC friendly intel >> syntax. >> Could you please fix that? >> >> Regards, >> Timo >> >> Am 01.05.2011 10:11, schrieb hpoussin(a)svn.reactos.org: >> >>> Author: hpoussin >>> Date: Sun May 1 08:11:43 2011 >>> New Revision: 51517 >>> >>> URL: http://svn.reactos.org/svn/reactos?rev=51517&view=rev >>> Log: >>> [freeldr] Add PXE "filesystem" >>> >>> Added: >>> trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (with props) >>> trunk/reactos/boot/freeldr/freeldr/fs/pxe.c (with props) >>> trunk/reactos/boot/freeldr/freeldr/include/arch/i386/pxe.h (with >>> props) >>> trunk/reactos/boot/freeldr/freeldr/include/fs/pxe.h (with props) >>> Modified: >>> trunk/reactos/boot/freeldr/freeldr/arch/i386/machpc.c >>> trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c >>> trunk/reactos/boot/freeldr/freeldr/freeldr_base.rbuild >>> trunk/reactos/boot/freeldr/freeldr/freeldr_base64k.rbuild >>> trunk/reactos/boot/freeldr/freeldr/fs/fs.c >>> trunk/reactos/boot/freeldr/freeldr/include/arch/i386/hardware.h >>> trunk/reactos/boot/freeldr/freeldr/include/arch/i386/machpc.h >>> trunk/reactos/boot/freeldr/freeldr/include/freeldr.h >>> >>> Added: trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S >>> URL: >>> http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… >>> ============================================================================== >>> >>> --- trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (added) >>> +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S [iso-8859-1] >>> Sun May 1 08:11:43 2011 >>> @@ -1,0 +1,97 @@ >>> +/* >>> + * FreeLoader >>> + * Copyright (C) 2011 Hervé Poussineau >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License as published by >>> + * the Free Software Foundation; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + * This program is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> + * GNU General Public License for more details. >>> + * >>> + * You should have received a copy of the GNU General Public License >>> along >>> + * with this program; if not, write to the Free Software Foundation, >>> Inc., >>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. >>> + */ >>> + >>> + .text >>> + .code16 >>> + >>> +#define ASM >>> + >>> +#include<arch.h> >>> + >>> +/* >>> + * U16 PxeCallApi(U16 Segment, U16 Offset, U16 Service, VOID >>> *Parameter); >>> + * >>> + * RETURNS: >>> + */ >>> +_pxe_function: >>> + .word 0 >>> +_pxe_entry_point: >>> + .long 0 >>> +_pxe_buffer_segment: >>> + .word0 >>> +_pxe_buffer_offset: >>> + .word0 >>> +_pxe_result: >>> + .word 0 >>> + >>> +EXTERN(_PxeCallApi) >>> + .code32 >>> + pushl %ebp >>> + movl %esp,%ebp >>> + >>> + >>> >>

3 2

Re: [ros-dev] [ros-diffs] [ekohl] 51558: [EVENTVWR/EVENTLOG] Fix a double off-by-one bug: - The eventlog service was reporting one event more than was available (+1). - The event viewer did not display the latest event from...
by Gabriel ilardi 02 May '11

02 May '11

Great work on event service and event viewer... keep it up Eric :) > Date: Mon, 2 May 2011 19:38:24 +0000 > To: ros-diffs(a)reactos.org > From: ekohl(a)svn.reactos.org > Subject: [ros-diffs] [ekohl] 51558: [EVENTVWR/EVENTLOG] Fix a double off-by-one bug: - The eventlog service was reporting one event more than was available (+1). - The event viewer did not display the latest event from... > > Author: ekohl > Date: Mon May 2 19:38:23 2011 > New Revision: 51558 > > URL: http://svn.reactos.org/svn/reactos?rev=51558&view=rev > Log: > [EVENTVWR/EVENTLOG] > Fix a double off-by-one bug: > - The eventlog service was reporting one event more than was available (+1). > - The event viewer did not display the latest event from the eventlog service (-1). > > See issue #6182 for more details. > > Modified: > trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c > trunk/reactos/base/services/eventlog/rpc.c > > Modified: trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mscutils… > ============================================================================== > --- trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/mscutils/eventvwr/eventvwr.c [iso-8859-1] Mon May 2 19:38:23 2011 > @@ -503,7 +503,7 @@ > HWND hwndDlg; > HANDLE hEventLog; > EVENTLOGRECORD *pevlr; > - DWORD dwRead, dwNeeded, dwThisRecord, dwTotalRecords = 0, dwCurrentRecord = 1, dwRecordsToRead = 0, dwFlags, dwMaxLength; > + DWORD dwRead, dwNeeded, dwThisRecord, dwTotalRecords = 0, dwCurrentRecord = 0, dwRecordsToRead = 0, dwFlags, dwMaxLength; > LPWSTR lpSourceName; > LPWSTR lpComputerName; > LPSTR lpData; > > Modified: trunk/reactos/base/services/eventlog/rpc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/eventlog/rpc… > ============================================================================== > --- trunk/reactos/base/services/eventlog/rpc.c [iso-8859-1] (original) > +++ trunk/reactos/base/services/eventlog/rpc.c [iso-8859-1] Mon May 2 19:38:23 2011 > @@ -199,6 +199,7 @@ > DWORD *NumberOfRecords) > { > PLOGHANDLE lpLogHandle; > + DWORD dwRecords; > > lpLogHandle = ElfGetLogHandleEntryByHandle(LogHandle); > if (!lpLogHandle) > @@ -206,7 +207,9 @@ > return STATUS_INVALID_HANDLE; > } > > - *NumberOfRecords = lpLogHandle->LogFile->Header.CurrentRecordNumber; > + dwRecords = lpLogHandle->LogFile->Header.CurrentRecordNumber; > + > + *NumberOfRecords = (dwRecords > 0) ? (dwRecords - 1) : 0; > > return STATUS_SUCCESS; > } > >

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 51517: [freeldr] Add PXE "filesystem"
by Timo Kreuzer 02 May '11

02 May '11

Why did you write the asm code in AT&T syntax? Its both ugly and breaks compilation with MSVC. I've spent quite some time converting all asm code to MSVC friendly intel syntax. Could you please fix that? Regards, Timo Am 01.05.2011 10:11, schrieb hpoussin(a)svn.reactos.org: > Author: hpoussin > Date: Sun May 1 08:11:43 2011 > New Revision: 51517 > > URL: http://svn.reactos.org/svn/reactos?rev=51517&view=rev > Log: > [freeldr] Add PXE "filesystem" > > Added: > trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (with props) > trunk/reactos/boot/freeldr/freeldr/fs/pxe.c (with props) > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/pxe.h (with props) > trunk/reactos/boot/freeldr/freeldr/include/fs/pxe.h (with props) > Modified: > trunk/reactos/boot/freeldr/freeldr/arch/i386/machpc.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c > trunk/reactos/boot/freeldr/freeldr/freeldr_base.rbuild > trunk/reactos/boot/freeldr/freeldr/freeldr_base64k.rbuild > trunk/reactos/boot/freeldr/freeldr/fs/fs.c > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/hardware.h > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/machpc.h > trunk/reactos/boot/freeldr/freeldr/include/freeldr.h > > Added: trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S (added) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/i386pxe.S [iso-8859-1] Sun May 1 08:11:43 2011 > @@ -1,0 +1,97 @@ > +/* > + * FreeLoader > + * Copyright (C) 2011 Hervé Poussineau > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > + .text > + .code16 > + > +#define ASM > + > +#include<arch.h> > + > +/* > + * U16 PxeCallApi(U16 Segment, U16 Offset, U16 Service, VOID *Parameter); > + * > + * RETURNS: > + */ > +_pxe_function: > + .word 0 > +_pxe_entry_point: > + .long 0 > +_pxe_buffer_segment: > + .word0 > +_pxe_buffer_offset: > + .word0 > +_pxe_result: > + .word 0 > + > +EXTERN(_PxeCallApi) > + .code32 > + pushl %ebp > + movl %esp,%ebp > + > +

2 1

Re: [ros-dev] [ros-diffs] [rharabien] 51510: [COMCTL32] * Properly support WM_SYSCOLORCHANGE in ListView controls with default background. Should be sent to Wine (tm)
by Ged Murphy 01 May '11

01 May '11

There's little point in (tm)ing these wine changes, if they don't get sent to wine or properly documented, then will definitely be overwritten by the next wine sync. On 30 April 2011 22:41, <rharabien(a)svn.reactos.org> wrote: > Author: rharabien > Date: Sat Apr 30 21:41:15 2011 > New Revision: 51510 > > URL: http://svn.reactos.org/svn/reactos?rev=51510&view=rev > Log: > [COMCTL32] > * Properly support WM_SYSCOLORCHANGE in ListView controls with default background. Should be sent to Wine (tm) > > Modified: > trunk/reactos/dll/win32/comctl32/listview.c > > Modified: trunk/reactos/dll/win32/comctl32/listview.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/listvie… > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/listview.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/listview.c [iso-8859-1] Sat Apr 30 21:41:15 2011 > @@ -315,6 +315,7 @@ > COLORREF clrBk; > COLORREF clrText; > COLORREF clrTextBk; > + BOOL bDefaultBkColor; > > /* font */ > HFONT hDefaultFont; > @@ -7870,7 +7871,8 @@ > static BOOL LISTVIEW_SetBkColor(LISTVIEW_INFO *infoPtr, COLORREF clrBk) > { > TRACE("(clrBk=%x)\n", clrBk); > - > + > + infoPtr->bDefaultBkColor = FALSE; > if(infoPtr->clrBk != clrBk) { > if (infoPtr->clrBk != CLR_NONE) DeleteObject(infoPtr->hBkBrush); > infoPtr->clrBk = clrBk; > @@ -9263,6 +9265,7 @@ > infoPtr->clrText = CLR_DEFAULT; > infoPtr->clrTextBk = CLR_DEFAULT; > LISTVIEW_SetBkColor(infoPtr, comctl32_color.clrWindow); > + infoPtr->bDefaultBkColor = TRUE; > > /* set default values */ > infoPtr->nFocusedItem = -1; > @@ -11525,6 +11528,11 @@ > > case WM_SYSCOLORCHANGE: > COMCTL32_RefreshSysColors(); > + if (infoPtr->bDefaultBkColor) > + { > + LISTVIEW_SetBkColor(infoPtr, comctl32_color.clrWindow); > + infoPtr->bDefaultBkColor = TRUE; > + } > return 0; > > /* case WM_TIMER: */ > > >

1 0

Fwd: [NOTEPAD] Patch by Edijs Kolesnikovics: Write default font, weight and point...
by Jérôme Gardou 29 Apr '11

29 Apr '11

SaveDword(hKey, _T("iPointSize"), Globals.lfFont.lfHeight); shouldn't it be SaveDword(hKey, _T("iPointSize"), PointSizeFromHeight(Globals.lfFont.lfHeight)); Also, this would permit to simplify code a bit :-) http://cia.vc/stats/project/ReactOS/.message/3522f92

1 0

Regular meeting
by Aleksey Bragin 29 Apr '11

29 Apr '11

Hello, I want to remind you of the regular meeting, Thursday the 28th at 20:00 UTC at freenode #reactos-meeting. The suggested meeting agenda is: - Status of our GSoC participation - Current ReactOS work. Developers saying what they are working on - Action List proposal - Status of the upcoming LinuxTag event preparations - Website revamp. Current status, who is working, who is willing to help If nobody else volunteers, Amine would be ready to take the minute taker position again in this meeting and I would lead the meeting. In case I am late, Amine will open the up meeting and I will join as soon as I get online. The current list of ReactOS members is as follows. Only these people will be able to participate in the discussions and votings, please tell us if we have forgotten anybody or if you want to be added to this list: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Aleksey Bragin (abragin) - Colin Finck (Colin_Finck) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Kamil Hornicek (Pigglesworth) - Amine Khaldi (AmineKhaldi) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Art Yerkes (arty) Everybody may join the meeting channel as a non-participating observer though. See you at the meeting today, Aleksey Bragin.

6 6

April Meeting Minutes
by Amine Khaldi 29 Apr '11

29 Apr '11

April Meeting Minutes 2011-04-28 20:05 UTC Freenode, #reactos-meeting Participants ============ Adam Stachowicz Aleksey Bragin Amine Khaldi Art Yerkes Daniel Reimer Gabriel Ilardi Ged Murphy Giannis Adamopoulos Gregor Schneider Hervé Poussineau James Tabor Javier Agustìn Fernàndez Arroyo Johannes Anderwald Maciej Białas Matthias Kupfer Olaf Siejka Pierre Schweitzer Rafał Harabień Samuel Serapion Timo Kreuzer Victor Martinez Ziliang Guo Proceedings =========== ○ Meeting called to order at 20:05 UTC by Aleksey Bragin ○ Point 1 in the agenda: GSoC status update =========================================== ■ Amine mentioned that ReactOS has 6 slots this year, and that a great care was put in the accepted projects selection with focus on UI and stability, with the goal to release 0.4 shortly after a successful GSoC. He also mentioned that the students will be granted commit access to official branches, so that the community can follow their progress. Ged and Amine asked the present members to do their best to help the students in any way, not leaving them only to their mentors, and asked the students not to hesitate to request help from anyone. ○ Point 2: Current ReactOS work =============================== ■ Amine: GSoC related tasks and coordination, CMake branch regression tracking and fixing, with the help of Igor and Rafał, still into the website revamp and the ideas around it. ■ Olaf: He has just updated VBox testbot to VBox 4.0.6, and with the great help of Fireball and hackdog he finally got sysreg for it done as well. Olaf also mentioned that our stdio problem of sysreg turned into another less visible one, VBox serial output problem, typically for heavy text output on virtual com via pipes.. The log is very good, but sometimes short parts of text are relocated, like in http://www.reactos.org/testman/detail.php?id=1763684. As a result of these efforts, test repetitions should be more rare. He also suggested to try to run it via com0com once Fireball signs the 64bit driver. Another thing Olaf was working on is trying to shorten the patch queue (http://www.reactos.org/wiki/Bug_Filters) and separate WIP patches from the ready for review patches, and he also began committing translations. ■ Matthias: He is working on patches and minor bug-fixes, with focus on win32 and win32k (espacially alt-tab). All the other ReactOS related tasks have nothing to do with developing. ■ Gregor: He mentioned that he doesn't have as much time as last year, since he works full time now, so he can only offer to help cleaning up bugzilla from time to time, committing patches, reviewing etc. Expect patches to random components from him, but he can't offer much irc activity. He's going through application patches currently. ■ Daniel: Not much time lately. He still hopes to get a new RosBE done in short term. ■ Javier: He tries to introduce new people to #reactos-es, and plans to work more on translations and to also blog about ReactOS in Spanish. ■ Samuel: He is already working on secur32 and started msv1_0. ■ Aleksey: He's trying to finish the ldr rewrite and commit it. Two blocker bugs are preventing him to do this: the first being the DLLs registration failures in the 2nd stage, and the other one is a random Firefox installer hang during file unpacking. When that's done, he plans to move on to organize the massive winesync of the tree, simultaneously trying to fix the remaining heap regressions (with someone?). The main problem is that he's traveling quite often during this time range, and thus can't work on ReactOS as he usually did, so any problem gets longer to solve. He will also continue working on arwinss after those tasks above are complete. ■ Gabriel: He keeps the forum clean on a daily basis (Spam mainly), and he also does small updates to the wiki, Bugzilla maintenance, committing translations and small patches, testing ReactOS and patches. He also added the svn log to the front page of the website and is currently giving some support to a guy that was interested in using ReactOS in his company. ■ Jim: He's mainly working on bug-fixing, especially keyboard messages and message in general. ■ Rafał: He's currently studying for his exams in May, and fixing random bugs from bugzilla during his breaks. He'll eventually help in CMake. ■ Giannis: He started researching his GSoC project and doing some tests. In the meantime he's trying to sort out any work that he started lately but not completed. ■ Johannes: He's mainly working on USB, planning to reach Mike's (mjmartin) driver state in the next few days, as most of the code written now is based on his implementation. He mentioned that today was good day for USB as lots of code got working. His initial goal is to get mass storage working with Win XP (thats the bulk and control transfers), then jump to hub driver and later the USB class driver, but he couldn't really say how long this will take. ■ Timo: He is focusing on his GSoC project. ■ Victor: He was busy this month with real life, but he's trying to create a Testing Forum Team, he hopes to start on it in the upcoming days. He also helps with the website revamp, and he's now preparing for the trip to Berlin for the LinuxTage event. ○ Point 3: Action List proposal =============================== ■ Amine referred to http://www.reactos.org/pipermail/ros-dev/2011-April/014148.html for context, and asked the members whether they have any comments/suggestions about it. Nothing came up, so we proceeded to the next point of this meeting. ○ Point 4: Status of the upcoming LinuxTag event preparations ============================================================= ■ Matthias mentioned that the booth is booked and tables and furniture are ordered/reserved. Due to the lack of interest we have only 4 persons as booth personnel. He will ask whether or not we need a day in advance for preparation of booth, and he prefers to setup the booth on first day, as long we don't have to set up a lot of things. Therefore, he hasn't booked a hotel yet. His preferred hotel is too expensive, and as long as we have some changes in persons he thinks it's easier to book single rooms with a price around 50-70€ per night. ■ A brief discussion went on between Victor, Matthias and Gregor about booking, sharing rooms, what to bring...etc ○ Point 5: Website revamp. Current status, who is working, who is willing to help ================================================================================= ■ Ziliang mentioned that he's porting content over, trimming a lot of stuff in terms of the 'About' and 'Why ReactOS' sections. He merged some parts into the dev FAQ from the general FAQ, and got the location of the Drupal install from Danny, so that he can start dropping in test modules which will allow us to test main page layouts. ■ The rest of the discussion was just a reiteration of what's already in the website revamp collaborative document. ○ Meeting ended at 23:10 UTC. ○ Minutes submitted by Amine Khaldi.

3 3

Task proposals
by Olaf Siejka 26 Apr '11

26 Apr '11

Below, a brief list of tasks i would propose for review at the next meeting. Please post your proposals as well: - LDR rewrite; - HEAP rewrite regression fixup; - CMake adoption; - MSVC adoption; - WineSync; - LIBSync; - Sysreg fixup (stdio problems, transition to pipe, automatical backtrace); - WineTest-with-HEAP-debugging checkup (basically, running every test from suite with heap debugging enabled); - Video Driver fixup (fixing ReactOS to use real video drivers, bug #2286 and all connected);

2 2

Action list
by Olaf Siejka 26 Apr '11

26 Apr '11

Dear colleagues We need to some short-term planning within our project, as the amount of tasks awaiting will simply turn into chaos. I propose a list to be kept, named "Action list". It should list our goals, things to be done, for example Winesync, fixing some particular bug, etc. Every task should be assigned to particular person, who would choose to be responsible for getting it done. It doesn't need to be the only person working on this, but rather someone making sure its done and not forgotten. Other variable assigned to task would be a deadline - approximate one, susceptible to extension when necessary. Goals are removed from the list when completed. Action list should be reviewed at every meeting, by querying people responsible for every task, being asked for an update. I can keep such list. Awaiting proposals for tasks if you think this makes sense. Regards

5 6

Re: [ros-dev] Ros-dev Digest, Vol 80, Issue 28
by Dimas FranK 25 Apr '11

25 Apr '11

Thanks for attention tone I was thinking of developing for ntfs http://www.reactos.org/wiki/index.php?title=Special%3ASearch&search=NTFS 2011/4/25, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Implementing ScmAssignNewTag (bug 6147) (Eric Kohl) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 24 Apr 2011 21:09:19 +0200 > From: Eric Kohl <eric.kohl(a)t-online.de> > Subject: Re: [ros-dev] Implementing ScmAssignNewTag (bug 6147) > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4DB4755F.1040003(a)t-online.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello Thomas, > > your plan sounds good to me. Just implement ScmAssingnNewTag and attach > the patch to bug #6147. I will review and and apply your patch if it is OK. > > Regards, > Eric > > > Thomas Faber wrote: >> Hi, >> >> I'm thinking about implementing the ScmAssignNewTag function in >> base\system\services\rpcserver.c because of >> http://www.reactos.org/bugzilla/show_bug.cgi?id=6147 >> >> My current plan would be: loop through all service keys in the >> registry, check the Tag values for all that are in the same group, >> and choose either max+1 or the first unused tag. >> >> Any opinions? Would it be important to observe how Windows calculates >> tags? Perhaps Eric has a good overview and thus an opinion on this >> service stuff? ;) >> >> Thanks. :) >> >> Regards, >> Tom >> >> _______________________________________________ >> 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 > > End of Ros-dev Digest, Vol 80, Issue 28 > *************************************** >

1 0

Implementing ScmAssignNewTag (bug 6147)
by Thomas Faber 24 Apr '11

24 Apr '11

Hi, I'm thinking about implementing the ScmAssignNewTag function in base\system\services\rpcserver.c because of http://www.reactos.org/bugzilla/show_bug.cgi?id=6147 My current plan would be: loop through all service keys in the registry, check the Tag values for all that are in the same group, and choose either max+1 or the first unused tag. Any opinions? Would it be important to observe how Windows calculates tags? Perhaps Eric has a good overview and thus an opinion on this service stuff? ;) Thanks. :) Regards, Tom

2 1

RSS feeds on the fron page
by Gabriel ilardi 22 Apr '11

22 Apr '11

Hi team, I've found an rss service (http://www.rssinclude.com) that lets us add our svn activity in the frontage, result would like like this: http://img15.imageshack.us/i/svni.jpg/ I'd like to publish it in our site for all languages, anyone disagrees ? There are better ways to do it, but this is a fast one and we'll have more "news" (fresh info) in our homepage directly and right now.... Please answer. Thanks. Gabriel.

2 2

1st stage gui installer partition manipulation
by Andrew Green 16 Apr '11

16 Apr '11

I have stumbled across this documentation http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/source/fmifs.shtml. What it contains discusses how partitions are created. The very cool thing is that by using FMIFS in the installer means that you can delete,create and resize all the partitions that the disk manager supports. This means it will make it a lot easier to add support to both without duplicating efforts.(windows vista+ has resizing xp doesn't seem to though) The current text installer doesn't use this as this part of reactos code is incomplete. I would like to add this to my gsoc proposal. Though I know I'm probably not going to get a place it may help me if I get a chance to do it in the future or maybe this could give ideas to someone else who tries. Any thoughts or suggestions would be very much appreciated.

3 5

Could opensource GPL USB driver for NT4 be help for implementing USB in ReactOS?
by Minas Abrahamyan 15 Apr '11

15 Apr '11

Hi all, The subj. I'm talking about Woodhead's GPL USB driver: * Original page (and site) is dead ("Woodhead--NT4--USB" http://www.geocities.com/mypublic99/index.html ) * But files are backed up, for example, here: [ftp://piekraste.daba.lv/pub/Service_Pack/NT_4/NT4_USB/HS/] (or look into internet wayback machine) Regards, M.A.

3 4

Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
by Minas Abrahamyan 14 Apr '11

14 Apr '11

Hi all, I'm going to implement dmesg.exe, a ROS application to read dmesg/kmsg buffer (debug messages in kernel buffer), which is filled in by appropriate patch 6018 (here: http://www.reactos.org/bugzilla/show_bug.cgi?id=6018 ) (BTW, it's not yet reviewed and not applied!). So I'm requesting advice on: What would be the better way for user-mode code to get the contents of kmsg buffer in kernel-space (kdbg)? Shortly: Linux has special system call "syslog" (man 2 syslog) FreeBSD uses its special sysctl interface to kernel along with 'kern.msgbuf' parameter. My questions: Do we need special system call like Linux, or even more, the whole family of them (sysctl('*')) as in BSD? How to implement simple system call for it, now? --- Now detailed info for unices: Linux case: * syslog(2) - read and/or clear kernel message ring buffer; set console_loglevel int syslog(int type, char *bufp, int len); * also /proc/kmsg virtual file, which when being read returns buffer contents ==excerpt from man proc == /proc/kmsg This file can be used instead of the syslog(2) system call to read kernel messages. A process must have superuser privileges to read this file, and only one process should read this file. This file should not be read if a syslog process is running which uses the sys‐ log(2) system call facility to log kernel messages. Information in this file is retrieved with the dmesg(1) program. ==eo exerpt== dmesg in FreeBSD: Parameter 'kern.msgbuf' given to sysctl(3) returns contents of kernel message buffer. There is also 'kern.msgbuf_clear' to clean the buffer. --- WBR, Minas Abrahamyan

4 13

Re: [ros-dev] [ros-diffs] [dreimer] 51296: - Sync all resource files with the English one. - Translate the new Dialog in the German one. - Normally we use BEGIN and END, no {} - DIALOG -> DIALOGEX
by Johannnes Anderwald 09 Apr '11

09 Apr '11

Am 09.04.2011 16:46, schrieb dreimer(a)svn.reactos.org: > Author: dreimer > Date: Sat Apr 9 14:46:37 2011 > New Revision: 51296 > > URL: http://svn.reactos.org/svn/reactos?rev=51296&view=rev > Log: > - Sync all resource files with the English one. > - Translate the new Dialog in the German one. > - Normally we use BEGIN and END, no {} > - DIALOG -> DIALOGEX > Hi, This change breaks sndvol32. Have you run sndvol32 after your changes? The reason is sndvol32 parses the dialog template code in memory, but it uses the DIALOG resource format instead of the DIALOGEX resource format. Please revert that partial change. kind regards, Johannes Anderwald

1 0

Re: [ros-dev] IFS wrapper project proposal draft
by Love Nystrom 09 Apr '11

09 Apr '11

Hi Bryan, Just like Aleksey, I would welcome an effort to simplify IFS implementation. Seen as NTFS is (and always will be?) not well documented, I've been thinking about supporting some alternative, OSS, journaling file system in ReactOS, e.g. ReiserFS, to allow us to provide the (relative) fail-safety of file transaction journaling that NTFS has. Also, hopefully, to enable us to implement NT's access privilege system (Security) on files. So far, it remains just a thought, since I can't allocate the time to adapt e.g ReiserFS to an NT IFS, and if I'm not mistaken, our IFS implementation has shortcomings of it's own which You may need to address as well in implementing Your proposal. In addition to "Windows NT File System Internals" I would also recommend "Windows Internals, 4th Edition" for additional/complementary insight. Especially Ch.12 "File Systems", but Ch.8-12 are all relevant, and the whole book is strongly recommended (by everyone, I think). It will be a BIG job I think (thesis big), and I hope You have the structural "common sense" to make it a success, and not a mess ;). It would be most welcome ! Comment Your code scrupulously :) Best Regards // Love On Sun, Apr 3, 2011 at 1:55 PM, <ros-dev-request(a)reactos.org> wrote: > ---------- Forwarded message ---------- > From: Bryan Donlan <bdonlan(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Sat, 2 Apr 2011 18:26:23 -0400 > Subject: [ros-dev] [GSoC] IFS wrapper project proposal draft > Hello, > > After reading the ReactOS GSoC ideas page, I became interested in the > IFS wrapper driver project idea[1], and would appreciate any comments > on my project proposal before I formally submit it. > > First, a bit about me. I am a student in a dual-major program, > studying Computer Science and Japanese at the University of > Massachusetts at Amherst. I have had some experience in kernel > development previously; as part of an internship at a research project > at my University, I wrote some network flow analysis code running in > the Linux kernel. While filesystem work will be a first for me, I > think it will be an interesting leaning experience. I am fluent in > English and Japanese, and am in the UTC-0400 timezone (TZ=US/Eastern). > My freenode username is bd_, and my myReactOS username is bdonlan. > > In preparation for writing this proposal, I obtained a copy of the > "Windows NT File System Internals: A Developer's Guide" book from > O'Reilly. Although a bit dated, it has been enourmously helpful in > helping me get an idea of what I'm getting into. > > My goal in this project will be to write a library to significantly > simplify writing a NT File System Driver. Although writing a > kernel-mode filesystem will never be as easy as with, eg, FUSE, it > should be possible to abstract away many of the idiosyncracies of the > NT filesystem API, at least. For example, the wrapper library may > handle: > * Automatically queueing asynchronous filesystem operations on a worker > thread > * Parsing paths and invoking a FS-supplied traversal function for each > directory element > * Interfacing with the NT cache manager, including flushing data from > the cache when a non-cached operation is performed on a cached file, > and establishing cache maps for the underlying device for a disk-based > file system > * Providing a common implementation of byte range locks and oplocks, > and disabling fast I/O when they are in use > * Caching directory entry lookups > * Performing typical input validation/security checks needed by all NT > filesystems > * Helper tools may also be provided to load pseudo-filesystems > (filesystems with neither network nor disk backing) on an ad-hoc basis > > Essentially, the library should make it easy for the filesystem > designer to focus on the actual filesystem, rather than the NT IFS > interfaces - a read call would be able to skip all the preparation and > checks, and directly go to perform the actual I/O. > > Major milestones for the project may include: > - Prepare a sketch of the API and callbacks for the IFS helper library > (subject to change if necessary) > - Implement enough of the wrapper library to implement a simple > pseudo-filesystem demonstrating non-cached reads and writes > - Add support for cached reads/writes (interaction with the cache > manager, caching for on-disk metadata) > - Demonstrate a disk-based filesystem without metadata update support > (MINIX FS or FAT?) > - Demonstrate a disk-based filesystem with full read-write support > - If time allows, add support for ancillary features, such as byte > locks, oplocks, and notify watchers. > > The interfaces exposed by the filesystem library will of course be > clearly documented. Filesystems needing more advanced support will > also be able to override any IFS callbacks they choose. > > I have an existing consulting commitment that will take some of my > time, but I expect to be able to put in 20-30 hours of work per week > into this project. Further, I hereby swear that I have not used nor > seen the source code to any version of the Windows operating system > nor any Microsoft product that may be related to the proposed project > that is under a license incompatible with contribution to ReactOS, > including but not limited to the leaked Windows 2000 source code and > the Windows Research Kernel. > > I would appreciate any comments on my proposal before formally > submitting it to the GSoC site. > > Thanks, > > Bryan Donlan > >

6 15

LinuxTag in Berlin
by Matthias Kupfer 08 Apr '11

08 Apr '11

Hi all, Daniel Reimer wrote recently he is unable to organise due to a bereavement for at least one week. So I will try to organise a little bit, even if i don't know all things. To make it short, we need a list of booth personnel for the period 11th May 2011 to 14th May 2011. We have to distinguish between booth personnel and (even project members as) visitors, because as booth member you can enter the fairground a little bit earlier. We have no hard limit, but we should take care of the amount we request. Looking at the schedule we should do this very soon, the deadline was 6th April. So please tell me/us when and in which role you want to attend the LinuxTag in Berlin (we can get free normal tickets for visitors and members if needed). Maybe we should plan time for set up the booth on 10th May 2011. Do we need any posters to prepare? I already know, we are located in hall 7.2b Suggestions, information remarks are very welcome, because I've lost the overview and try to save the event. Matthias -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany -- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany

3 2

gsoc-application-2011
by Armaan 07 Apr '11

07 Apr '11

Hello friends, suggestions on gsoc application improvement needed: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/armaan/8… Thanks Armaan

1 0

GSoC 2011 proposal - lwIP
by Claudiu Mihail 06 Apr '11

06 Apr '11

Hello all, My name is Claudiu Mihail and I would like to introduce myself to the ReactOS community. I am a computer science student from Bucharest, Romania. I've been hanging around the IRC channel for sometime now under the nick KlausM and I would like to participate in this year's GSoC un behalf of ReactOS. As such I have opted for the "TCP/IP Driver Replacement Using lwIP" idea. The reason why I chose this idea is because, after some discussions on IRC with members of the community, it was setteled that this is something that takes priority for ReactOS. I have basic kernel programming experience on both Linux and Windows and am quite familiar with the Win32 API. I have attached a PDF document with my resume and past projects in the hopes that it will help determine if my skill set is compatible with the ReactOS project demands. Time commitment: I will free to work on the ReactOS project I am applying for from the end of april up until the end of august, the current year. I will have 2 week period of exams from the beginning of July up until the 15th of July. Legal Requirements: I declare the following is *true:* * * I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel. Regarding the milestone part I have some basic sketches and would greatly appreciate some pointers. After some discussions on IRC I have elarned that there is already a branch dedicated to using lwIP. Bringing that branch up to date should be the first task. Thus, during the community bonding period I could do this task (if not earlier) and in so doing get familiarized with the ReactOS codebase. After managing to bring the branch up to date versus a trunk checkout I could further begin improving the replacement driver. Yet I would very much appreciate some pointers as to more precise goals. In the end there should be a fully functional driver and a suite of test cases, that much is clear. I don't have any previous experience with lwIP or protocol drivers but I have some kernel programming experience and am willing to learn. Thank you, Claudiu

1 0

March meeting minutes
by Aleksey Bragin 06 Apr '11

06 Apr '11

March Meeting Minutes 2010-03-31 20:30 UTC Fezile IRC Server (fezile.reactos.org), #meeting Participants Present: Giannis Adamopoulos Johannes Anderwald Javier Agustìn Fernàndez Arroyo Maciej Białas Aleksey Bragin Colin Finck Danny Götte Ziliang Guo Rafał Harabień Kamil Hornicek Amine Khaldi Timo Kreuzer Matthias Kupfer Victor Martinez Ged Murphy Sylvain Petreolle Hervé Poussineau Daniel Reimer Pierre Schweitzer Samuel Serapion Olaf Siejka James Tabor Art Yerkes Proceedings ○ Meeting called to order at 20:30 UTC by Colin Finck ○ Point 1 in the agenda: ReactOS member definition ■ This point wasn’t easy to address, since there is no clear criteria to apply in order to define the team members. As a result, a discussion went on and ended up with an accepted proposal. ■ Colin Finck proposed that we skip a fixed definition of the term "ReactOS Member", but instead maintain a list with names employing the following rule: A person is added to this list if at least two existing ReactOS members propose him and the list maintainer (Colin Finck) or alternatively the backup list maintainer (Aleksey Bragin) agrees with their proposal. ■ The participants accepted Colin’s proposal. (15 yes votes, 2 no votes, 3 abstained) ○ Point 2: Current ReactOS work ■ Aleksey: Currently working on ntdll/ldr and kernel32/ldr loaders, his next goal is undecided yet, he will look at what ReactOS needs more from user perspective. ■ Amine: Currently working on the CMake branch, the website revamp and the ideas around it. ■ Art: Currently working on fixing a few crashes running the regression test CD on the NewCC branch. ■ Colin: He has been busy with preparing the 0.3.13 release, then Chemnitz Linux Days, afterwards this meeting. He will be on a trip abroad starting 9th April and will return 13th May, he’s not yet sure what he will do then. ■ Daniel: He will continue to work on RosBE 1.6/2.0. Playing with the new GCC 4.6 right now. He also regularly works on forum moderation, translations and the rapps database. ■ Giannis: He has been working on fixing several bugs in win32k lately. This included multiple issues in ancient code related to handling desktops and window stations. He looks forward to apply for GSoC and work on theming support. ■ Matthias: He is occasionally working on small bugfixes for the ReactOS source tree. His main ReactOS work lies in leading the German foundation and preparing ReactOS appearances at events in Germany (passed Chemnitz Linux Days and upcoming LinuxTag in Berlin). ■ Maciej: Right now, he is investigating forum modules and extensions for Drupal, which could be handy for our users. This is part of the ongoing website revamp (point 6 in the meeting agenda). ■ Olaf: He has been working on our BuildBot, doing some cleanup work and setting up some builders for the NewCC branch and patches. He will handle the remaining issues like a need to backup the VBox test logs. When the new RosBE is out, he is going to try to make use of it within CMake build scripts. He has also been introducing the WIP (Work In Progress) tag in our Bugzilla and is going to push some more bugs marked with the PATCH tag to developers. ■ Pierre: For the moment, he is mainly cleaning up some parts of kernel32, focusing on the code inside the “file” subdirectory. This requires implementing the Mount Manager, which he is also doing. This may help to bring several improvements elsewhere in ReactOS. His work on FsRtl and especially the FsRtlIs*InExpression functions is also still going on. The current implementation will be superseded by a proper algorithm based on a NFA as soon as he has the time. He is moving to the CERN starting on 4th April, so his involvement in the project might change soon. ■ Samuel: He is already working on secur32, lsalib and schannel to refine his GSoC proposal. ■ Sylvain: He has been busy with various tasks related to the CMake branch, regression tests and bug fixing. ■ Timo: He is working on the GDI handle manager, better performance/ scalability, better tracking of errors that could lead to deadlocks/ leaks and minor interface improvements. Will take some time to get it right. ■ Victor: He is continuing working on PR aspects. He has just returned from another show in Huelva (Spain). Youtube videos will be available soon. He will also work on the website revamp and on improving the users forum experience, trying to create testing coordination. He is open to any suggestion regarding PR and attracting new users and developers. ■ Ziliang: Mostly doing GSoC preparation work at the moment. He is also preparing his own GSoC application concerning performance counters. ○ Point 3: Status of our GSoC participation, in particular students and mentors ■ Amine reported that we have got some student applications, but we still await more. As to mentors, so far we need Hervé and Kamil to register as mentors in the web platform, and we welcome more mentors and at least co-mentors to do the same. So far, we have Aleksey, Art, Ged, Pierre and Kamil as confirmed mentors. As to timeline, for student applications it is 8th April, and to get everything sorted out it is 22nd April. ○ Point 4: Upcoming LinuxTag event on 11th to 14th May ■ Matthias reported that our project has been accepted this week for LinuxTag, so we would like to invite all ReactOS Team members to take part. He stated that he will be there the whole time if necessary, but he recommends that more members take part. ■ Victor expressed that he will be there from 11th to 13th. ■ Matthias thinks that we need at least 2 team members per day, and 3-4 team members overall. He also mentioned that, depending on the count of persons, we cannot pay all expenses for accommodation and transport. ■ Colin stressed out the fact that this is Europe's most-important event regarding Open-Source, and that it would not just be a good chance to present the project internationally, but also to get in touch with other ReactOS members. ○ Point 5: Sum up of previous events, ideas for next ones ■ Colin reported that we recently had the Chemnitz Linux Days event again. We presented ReactOS on 4 laptops there, two native and two in VMs. Compared to last year, ReactOS was now able for two major breakthroughs: One of the laptops running in a VM was capable of streaming internet radio all day long, while on the other hand, ReactOS was also able to run natively on a 4-year old system (with SATA controller!). The only caveat preventing the real usefulness of the native system was the lack of a working network driver for the Intel PRO/1000 PL chip. Having an improved network/driver stack would have made the presentation even better. He I assumes we had 50% interested people who already knew about ReactOS and wanted to hear about the updates in the last year, while the other half was completely new to ReactOS. Colin thinks we still have enough potential to make new people aware of the project and maybe even gain more developers. That was just said to understand why we are so eager about PR lately and have the next event in not much more than a month. ■ Victor reported that he has been holding 2 events lately. The major one is Imaginatica'11. We had a booth there and a showroom, and had a lot of visitors quite interested in ReactOS. Even more, we had 2 important visits from a company and CSIC (Spanish investigators) who asked if a Windows driver would work in ReactOS, because they are doing embedded systems. They also asked Victor if we would work on sponsored specific compatibility aspects, which means "if I pay you a certain amount for having OpenOffice and ContaPlus working, will you work on it ?". Victor suggested as a result that this "Compatibility On demand" concept is a possible market. He also was holding another speech in Huelva: "Jornadas Tecnlogicas". The best thing about this was that it is the first time an Event has contacted us to show ReactOS. As a result of the recent events, he noticed that we have to change our presentations style from the quite technical ones to the quite general ones, for a wider audience. He also reported that he was contacted by a new Spanish designer thanks to Imaginatica. This was a direct result of his emphasis on the fact that we don't just need developers, but also skilled members in the other departments, including designers, bloggers, testers, users, etc. Victor will see if this new designer has web design capabilities, in which case he may join our website revamp efforts. ○ Point 6: Website revamp. Current status, who is working, who is willing to help ■ Colin mentioned that we still want a complete revamp of our website, starting from scratch with the articles and also dropping RosCMS and basing everything around the Drupal CMS. He also mentioned that while the design winner from 2009 is still the target design, it needs to be adapted to Drupal now, not just due to the different technology behind Drupal, but also because our Drupal website should be more based on activity (as outlined in our website revamp google document) ■ A technical discussion has been held to try to analyze the needs and discuss how they will be addressed. ■ Victor is in contact with a Spanish designer, hopefully he can work with him on the design department. ■ Ziliang will be taking care of the content department. ■ Maciej will handle the technical aspects of the website revamp, he set up a testing server where we are going to test the Drupal 7-based website revamp. Moving this server to an officially hosted VM is planned. ■ Danny is handling the VM on the ReactOS server. ■ We agreed on working on these different departments in parallel. ○ Meeting ended at 23:57 UTC. ○ Minutes submitted by Amine Khaldi.

1 0

Re: [ros-dev] Windows Internals 5th Edition
by Love Nystrom 05 Apr '11

05 Apr '11

Hi James, Yes, most interesting, but isn't it a little beside point? I mean, we're still targeting the XP kernel in ReactOS, aren't we? Or have I missed a re-targeting point in my absence? WBR // Love 2011/3/31 <ros-dev-request(a)reactos.org> > ---------- Forwarded message ---------- > From: James Tabor <jimtabor.rosdev(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Wed, 30 Mar 2011 19:23:40 -0500 > Subject: Re: [ros-dev] [ros-diffs] [gadamopoulos] 51115: [ntoskrnl] - > Implement calling OkayToCloseProcedure callouts to win32k for desktop and > window station objects - Fix a bug that caused ObpCloseHandle to return > success even whe... > Hi everyone, > http://www.alex-ionescu.com/ Main Blog, > http://www.alex-ionescu.com/?p=61 Black Hat 2008 Wrap-up <------- here > http://www.alex-ionescu.com/BH08-AlexIonescu.pdf <------------------ read > > I would like everyone (new Developers) that haven't read this blog to > do so and get up to date! > > I'm not sure if M$ fixed their issues, it may not be Server 2003 but > at least 2008 plus or 7. > > Thanks, > James > > ps I have the right to use M$ since 1983........ > > On Tue, Mar 22, 2011 at 9:19 AM, Alex Ionescu <ionucu(a)videotron.ca> wrote: > > It's hilarious how this new code has the exact same Windows security bug > I gave a talk about at BlackHat 2-3 years ago (which Microsoft fixed in > Vista). > > > > It's sad how this code ignores the exported PsSetProcessWindowStation API > and relevant EPROCESS field. > > > > It's awesome how nothing changes whenever I prop up to see the > "progress". > > > > -- > > Best regards, > > Alex Ionescu >

3 6

Brothers In Arms
by Love Nystrom 05 Apr '11

05 Apr '11

Thank You for understanding, Adam! Here's an off-topic for all of You, my Brothers in Arms .. http://www.youtube.com/watch?v=q2rx3IAEISA <http://www.youtube.com/watch?v=q2rx3IAEISA> Happy listening. Peace // Love On Sun, Apr 3, 2011 at 2:21 PM, Adam <geekdundee(a)gmail.com> wrote: > I know exactly what you mean. I live with autism (although not severe) and > depression and it's not good stuff that these things occur. I have seen your > past mails and they are not too shabby. > > Allocating time is a hard thing because unlike ReactOS I do not have a > priority-driven round-robin scheduler. > > Hope you get better soon mate. > > > On Sun, 03 Apr 2011 16:55:38 +1000, Love Nystrom <love.nystrom(a)gmail.com> > wrote: > > As a side note, my shitty RL situation is largely responsible for my >> occasional tantrums, >> for which I am truly sorry. Taking my RL frustrations out on my Brothers >> In Arms is *unfair*. >> I am trying hard to find a more stable RL solution that will allow me to >> allocate time to ReactOS >> coding, but nothing is yet for certain .. all just a glimmer of hope. >> >

1 0

ReactOS Project at LinuxTag 2011 in Berlin
by Colin Finck 04 Apr '11

04 Apr '11

Hi all, Even though Chemnitzer Linux-Tage has not been that long ago, I can already announce that the ReactOS Project has received a sponsored booth at LinuxTag 2011 in Berlin. LinuxTag is considered to be Europe's most important Open-Source event and it takes place from 11th to 14th May at the Berlin Fairgrounds. As it is much more directed at an international audience compared to the Chemnitz event, it would be nice if we can get many ReactOS team members to attend it. So far, I already got a positive answer from Aleksey for 1-2 days, Matthias for the whole time and Victor for an unspecified time. I myself will still be away from Germany during this time, so I won't be able to come. The German foundation might be able to refund some of the transport and accomodation costs, but this also depends on the number of ReactOS members present. On the other hand, this mail should of course also serve as a call for interested people to visit us in Berlin :-) With best regards, Colin

2 1

[GSoC] IFS wrapper project proposal draft
by Bryan Donlan 03 Apr '11

03 Apr '11

Hello, After reading the ReactOS GSoC ideas page, I became interested in the IFS wrapper driver project idea[1], and would appreciate any comments on my project proposal before I formally submit it. First, a bit about me. I am a student in a dual-major program, studying Computer Science and Japanese at the University of Massachusetts at Amherst. I have had some experience in kernel development previously; as part of an internship at a research project at my University, I wrote some network flow analysis code running in the Linux kernel. While filesystem work will be a first for me, I think it will be an interesting leaning experience. I am fluent in English and Japanese, and am in the UTC-0400 timezone (TZ=US/Eastern). My freenode username is bd_, and my myReactOS username is bdonlan. In preparation for writing this proposal, I obtained a copy of the "Windows NT File System Internals: A Developer's Guide" book from O'Reilly. Although a bit dated, it has been enourmously helpful in helping me get an idea of what I'm getting into. My goal in this project will be to write a library to significantly simplify writing a NT File System Driver. Although writing a kernel-mode filesystem will never be as easy as with, eg, FUSE, it should be possible to abstract away many of the idiosyncracies of the NT filesystem API, at least. For example, the wrapper library may handle: * Automatically queueing asynchronous filesystem operations on a worker thread * Parsing paths and invoking a FS-supplied traversal function for each directory element * Interfacing with the NT cache manager, including flushing data from the cache when a non-cached operation is performed on a cached file, and establishing cache maps for the underlying device for a disk-based file system * Providing a common implementation of byte range locks and oplocks, and disabling fast I/O when they are in use * Caching directory entry lookups * Performing typical input validation/security checks needed by all NT filesystems * Helper tools may also be provided to load pseudo-filesystems (filesystems with neither network nor disk backing) on an ad-hoc basis Essentially, the library should make it easy for the filesystem designer to focus on the actual filesystem, rather than the NT IFS interfaces - a read call would be able to skip all the preparation and checks, and directly go to perform the actual I/O. Major milestones for the project may include: - Prepare a sketch of the API and callbacks for the IFS helper library (subject to change if necessary) - Implement enough of the wrapper library to implement a simple pseudo-filesystem demonstrating non-cached reads and writes - Add support for cached reads/writes (interaction with the cache manager, caching for on-disk metadata) - Demonstrate a disk-based filesystem without metadata update support (MINIX FS or FAT?) - Demonstrate a disk-based filesystem with full read-write support - If time allows, add support for ancillary features, such as byte locks, oplocks, and notify watchers. The interfaces exposed by the filesystem library will of course be clearly documented. Filesystems needing more advanced support will also be able to override any IFS callbacks they choose. I have an existing consulting commitment that will take some of my time, but I expect to be able to put in 20-30 hours of work per week into this project. Further, I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel. I would appreciate any comments on my proposal before formally submitting it to the GSoC site. Thanks, Bryan Donlan [1] - http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas#IFS_Wrapper_Dr…

3 3

(no subject)
by Karl Wechselberger 03 Apr '11

03 Apr '11

1 0

Re: [ros-dev] Meeting on Thursday
by Love Nystrom 03 Apr '11

03 Apr '11

Hi Colin, Please put me on the list as well, would You? Because of a real shitty RL situation I haven't been able to contribute the way I would like to, but believe me when I say I am committed to the success of the ReactOS project. I guess we all have our own reasons.. Mine is by and large to be free of Microsoft! As a side note, my shitty RL situation is largely responsible for my occasional tantrums, for which I am truly sorry. Taking my RL frustrations out on my Brothers In Arms is *unfair*. I am trying hard to find a more stable RL solution that will allow me to allocate time to ReactOS coding, but nothing is yet for certain .. all just a glimmer of hope. Peace // Love On Tue, Mar 29, 2011 at 5:23 PM, <ros-dev-request(a)reactos.org> wrote: > > > Date: Tue, 29 Mar 2011 00:32:20 +0200 > > From: colin(a)reactos.org > > To: ros-dev(a)reactos.org > > Subject: [ros-dev] Meeting on Thursday > > > > Hi folks, > > > > As proposed in our urgent meeting in February, we are going to have > > regular meetings at 20:00 UTC on the last Thursday of every month. Next > > Thursday will be the first time to hold such a meeting. > > > > While I was preparing the technical side (we're going to have a > > dedicated IRC server with voting capabilities this time), Amine and > > Victor have come up with a meeting agenda. We have agreed on the > > following points in this order: > > > > - ReactOS member definition. Proposal is not to establish a fixed > > definition, but decide upon always keeping a list of people and just > > giving hints on how you can get on this list > > - Current ReactOS work. Developers saying what they are working on > > - Status of our GSoC participation, in particular students and mentors > > - Upcoming LinuxTag event on 11th to 14th May > > - Sum up of previous events, ideas for next ones > > - Website revamp. Current status, who is working, who is willing to help > > > > You see that the list is more about inquiring and getting information > > than doing vital decisions this time. The agenda is also prioritized so > > that people may leave if they don't want to participate in website > > discussions for example. > > If nobody else volunteers, Amine would be in the minute taker position > > again and I would take the meeting leader role. > > > > My current list of ReactOS members is as follows. Only these people will > > be able to participate in the discussions and votings, so please tell me > > if I have forgotten anybody or if you want to be added to this list: > > > > - Giannis Adamopoulos (smiley1_) > > - Johannes Anderwald (janderwald) > > - Javier Agustìn Fernàndez Arroyo (elhoir) > > - Maciej Bialas (niski) > > - Aleksey Bragin (abragin) > > - Colin Finck (Colin_Finck) > > - Danny Götte (dangerground) > > - Cameron Gutman (aicom) > > - Ziliang Guo (ZWabbit) > > - Rafal Harabien (rafalh) > > - Kamil Hornicek (Pigglesworth) > > - Amine Khaldi (AmineKhaldi) > > - Timo Kreuzer (tkreuzer) > > - Matthias Kupfer (Collibri) > > - Michael Martin (mjmartin) > > - Victor Martinez (vicmarcal) > > - Roel Messiant (Mephisto) > > - Andrew Munger (WaxDragon) > > - Ged Murphy (GedMurphy) > > - Sylvain Petreolle (Usurp) > > - Hervé Poussineau (hpoussin) > > - Daniel Reimer (dreimer) > > - Pierre Schweitzer (HeisSpiter) > > - Samuel Serapion (encoded) > > - Olaf Siejka (Caemyr) > > - James Tabor (jimtabor) > > - Art Yerkes (arty) >

2 1

GSoC
by mebik＠email.cz 02 Apr '11

02 Apr '11

Hi, I am student IT technology college, I can programming in C, NASM or C#. I want try make project for GSoC. I have some teoretic knowledge about filesystem from school. Can you help me with choice ideas from project ? Thank you

1 0

Re: [ros-dev] [ros-diffs] [rharabien] 51221: [SYSTEMINFO] Don't translate System Type Don't mix TCHARs and chars Fix Time Zone for not English systems Use proper registry key for Install Date Format dates using system setti...
by Ged Murphy 01 Apr '11

01 Apr '11

On 1 April 2011 19:58, <rharabien(a)svn.reactos.org> wrote: > Don't mix TCHARs and chars That's ironic. The use of TCHAR is quite messy in this patch.

1 0

Meeting on Thursday
by Colin Finck 01 Apr '11

01 Apr '11

Hi folks, As proposed in our urgent meeting in February, we are going to have regular meetings at 20:00 UTC on the last Thursday of every month. Next Thursday will be the first time to hold such a meeting. While I was preparing the technical side (we're going to have a dedicated IRC server with voting capabilities this time), Amine and Victor have come up with a meeting agenda. We have agreed on the following points in this order: - ReactOS member definition. Proposal is not to establish a fixed definition, but decide upon always keeping a list of people and just giving hints on how you can get on this list - Current ReactOS work. Developers saying what they are working on - Status of our GSoC participation, in particular students and mentors - Upcoming LinuxTag event on 11th to 14th May - Sum up of previous events, ideas for next ones - Website revamp. Current status, who is working, who is willing to help You see that the list is more about inquiring and getting information than doing vital decisions this time. The agenda is also prioritized so that people may leave if they don't want to participate in website discussions for example. If nobody else volunteers, Amine would be in the minute taker position again and I would take the meeting leader role. My current list of ReactOS members is as follows. Only these people will be able to participate in the discussions and votings, so please tell me if I have forgotten anybody or if you want to be added to this list: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Aleksey Bragin (abragin) - Colin Finck (Colin_Finck) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Kamil Hornicek (Pigglesworth) - Amine Khaldi (AmineKhaldi) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Art Yerkes (arty) Everybody may join the meeting channel as a non-participating observer though. I'll hand you all connection details when we're ready. With best regards, Colin

12 18

Re: [ros-dev] [ros-diffs] [gadamopoulos] 51115: [ntoskrnl] - Implement calling OkayToCloseProcedure callouts to win32k for desktop and window station objects - Fix a bug that caused ObpCloseHandle to return success even whe...
by Alex Ionescu 31 Mar '11

31 Mar '11

It's hilarious how this new code has the exact same Windows security bug I gave a talk about at BlackHat 2-3 years ago (which Microsoft fixed in Vista). It's sad how this code ignores the exported PsSetProcessWindowStation API and relevant EPROCESS field. It's awesome how nothing changes whenever I prop up to see the "progress". -- Best regards, Alex Ionescu On 2011-03-22, at 5:19 AM, gadamopoulos(a)svn.reactos.org wrote: > Author: gadamopoulos > Date: Tue Mar 22 09:19:26 2011 > New Revision: 51115 > > URL: http://svn.reactos.org/svn/reactos?rev=51115&view=rev > Log: > [ntoskrnl] > - Implement calling OkayToCloseProcedure callouts to win32k for desktop and window station objects > - Fix a bug that caused ObpCloseHandle to return success even when OkayToCloseProcedure failed > > [win32k] > - Rewrite SetProcessWindowStation to actually set the current window station and close the previous one > - Implement OkayToCloseProcedure callouts from the kernel to prevent closing the current desktop or window station > > Modified: > trunk/reactos/ntoskrnl/ex/win32k.c > trunk/reactos/ntoskrnl/ob/obhandle.c > trunk/reactos/ntoskrnl/ps/win32.c > trunk/reactos/subsystems/win32/win32k/include/desktop.h > trunk/reactos/subsystems/win32/win32k/include/win32.h > trunk/reactos/subsystems/win32/win32k/include/winsta.h > trunk/reactos/subsystems/win32/win32k/main/dllmain.c > trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c > > Modified: trunk/reactos/ntoskrnl/ex/win32k.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/win32k.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/win32k.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/win32k.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -37,9 +37,45 @@ > > PKWIN32_PARSEMETHOD_CALLOUT ExpWindowStationObjectParse = NULL; > PKWIN32_DELETEMETHOD_CALLOUT ExpWindowStationObjectDelete = NULL; > +PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpWindowStationObjectOkToClose = NULL; > +PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpDesktopObjectOkToClose = NULL; > PKWIN32_DELETEMETHOD_CALLOUT ExpDesktopObjectDelete = NULL; > > /* FUNCTIONS ****************************************************************/ > + > +NTSTATUS > +NTAPI > +ExpDesktopOkToClose( IN PEPROCESS Process OPTIONAL, > + IN PVOID Object, > + IN HANDLE Handle, > + IN KPROCESSOR_MODE AccessMode) > +{ > + WIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters; > + > + Parameters.Process = Process; > + Parameters.Object = Object; > + Parameters.Handle = Handle; > + Parameters.PreviousMode = AccessMode; > + > + return ExpDesktopObjectOkToClose(&Parameters); > +} > + > +NTSTATUS > +NTAPI > +ExpWindowStationOkToClose( IN PEPROCESS Process OPTIONAL, > + IN PVOID Object, > + IN HANDLE Handle, > + IN KPROCESSOR_MODE AccessMode) > +{ > + WIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters; > + > + Parameters.Process = Process; > + Parameters.Object = Object; > + Parameters.Handle = Handle; > + Parameters.PreviousMode = AccessMode; > + > + return ExpWindowStationObjectOkToClose(&Parameters); > +} > > VOID > NTAPI > @@ -114,6 +150,7 @@ > ObjectTypeInitializer.PoolType = NonPagedPool; > ObjectTypeInitializer.DeleteProcedure = ExpWinStaObjectDelete; > ObjectTypeInitializer.ParseProcedure = ExpWinStaObjectParse; > + ObjectTypeInitializer.OkayToCloseProcedure = ExpWindowStationOkToClose; > ObCreateObjectType(&Name, > &ObjectTypeInitializer, > NULL, > @@ -124,6 +161,7 @@ > ObjectTypeInitializer.GenericMapping = ExpDesktopMapping; > ObjectTypeInitializer.DeleteProcedure = ExpDesktopDelete; > ObjectTypeInitializer.ParseProcedure = NULL; > + ObjectTypeInitializer.OkayToCloseProcedure = ExpDesktopOkToClose; > ObCreateObjectType(&Name, > &ObjectTypeInitializer, > NULL, > > Modified: trunk/reactos/ntoskrnl/ob/obhandle.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ob/obhandle.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ob/obhandle.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ob/obhandle.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -1752,7 +1752,6 @@ > > /* Detach and return success */ > if (AttachedToProcess) KeUnstackDetachProcess(&ApcState); > - Status = STATUS_SUCCESS; > } > else > { > > Modified: trunk/reactos/ntoskrnl/ps/win32.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/win32.c?rev=51… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/win32.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/win32.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -20,6 +20,8 @@ > PGDI_BATCHFLUSH_ROUTINE KeGdiFlushUserBatch = NULL; > extern PKWIN32_PARSEMETHOD_CALLOUT ExpWindowStationObjectParse; > extern PKWIN32_DELETEMETHOD_CALLOUT ExpWindowStationObjectDelete; > +extern PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpWindowStationObjectOkToClose; > +extern PKWIN32_OKTOCLOSEMETHOD_CALLOUT ExpDesktopObjectOkToClose; > extern PKWIN32_DELETEMETHOD_CALLOUT ExpDesktopObjectDelete; > extern PKWIN32_POWEREVENT_CALLOUT PopEventCallout; > > @@ -116,6 +118,8 @@ > PspW32ThreadCallout = CalloutData->ThreadCallout; > ExpWindowStationObjectParse = CalloutData->WindowStationParseProcedure; > ExpWindowStationObjectDelete = CalloutData->WindowStationDeleteProcedure; > + ExpWindowStationObjectOkToClose = CalloutData->WindowStationOkToCloseProcedure; > + ExpDesktopObjectOkToClose = CalloutData->DesktopOkToCloseProcedure; > ExpDesktopObjectDelete = CalloutData->DesktopDeleteProcedure; > PopEventCallout = CalloutData->PowerEventCallout; > KeGdiFlushUserBatch = CalloutData->BatchFlushRoutine; > > Modified: trunk/reactos/subsystems/win32/win32k/include/desktop.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/desktop.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/desktop.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -69,6 +69,9 @@ > VOID APIENTRY > IntDesktopObjectDelete(PWIN32_DELETEMETHOD_PARAMETERS Parameters); > > +NTSTATUS NTAPI > +IntDesktopOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters); > + > LRESULT CALLBACK > IntDesktopWindowProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); > > > Modified: trunk/reactos/subsystems/win32/win32k/include/win32.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/win32.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/win32.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -166,6 +166,7 @@ > PCLS pclsPrivateList; > PCLS pclsPublicList; > INT cThreads; > + HDESK hdeskStartup; > DWORD dwhmodLibLoadedMask; > HANDLE ahmodLibLoaded[CLIBS]; > struct _WINSTATION_OBJECT *prpwinsta; > > Modified: trunk/reactos/subsystems/win32/win32k/include/winsta.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/include/winsta.h [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/include/winsta.h [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -82,6 +82,9 @@ > APIENTRY > IntWinStaObjectParse(PWIN32_PARSEMETHOD_PARAMETERS Parameters); > > +NTSTATUS NTAPI > +IntWinstaOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters); > + > NTSTATUS FASTCALL > IntValidateWindowStationHandle( > HWINSTA WindowStation, > @@ -106,4 +109,7 @@ > > PWINSTATION_OBJECT FASTCALL IntGetWinStaObj(VOID); > > +BOOL FASTCALL > +UserSetProcessWindowStation(HWINSTA hWindowStation); > + > /* EOF */ > > Modified: trunk/reactos/subsystems/win32/win32k/main/dllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ma… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/main/dllmain.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -119,6 +119,7 @@ > { > DPRINT("Destroying W32 process PID:%d at IRQ level: %lu\n", Process->UniqueProcessId, KeGetCurrentIrql()); > Win32Process->W32PF_flags |= W32PF_TERMINATED; > + > if (Win32Process->InputIdleEvent) > { > EngFreeMem((PVOID)Win32Process->InputIdleEvent); > @@ -144,6 +145,9 @@ > { > LogonProcess = NULL; > } > + > + UserSetProcessWindowStation(NULL); > + > } > > RETURN( STATUS_SUCCESS); > @@ -220,25 +224,14 @@ > { > if(hWinSta != NULL) > { > - if(Process != CsrProcess) > + if(!UserSetProcessWindowStation(hWinSta)) > { > - HWINSTA hProcessWinSta = (HWINSTA)InterlockedCompareExchangePointer((PVOID)&Process->Win32WindowStation, (PVOID)hWinSta, NULL); > - if(hProcessWinSta != NULL) > - { > - /* our process is already assigned to a different window station, we don't need the handle anymore */ > - NtClose(hWinSta); > - } > - } > - else > - { > - NtClose(hWinSta); > + DPRINT1("Failed to set process window station\n"); > } > } > > if (hDesk != NULL) > { > - Win32Thread->rpdesk = NULL; > - Win32Thread->hdesk = NULL; > if (!IntSetThreadDesktop(hDesk, FALSE)) > { > DPRINT1("Unable to set thread desktop\n"); > @@ -441,6 +434,8 @@ > CalloutData.ProcessCallout = Win32kProcessCallback; > CalloutData.ThreadCallout = Win32kThreadCallback; > CalloutData.BatchFlushRoutine = NtGdiFlushUserBatch; > + CalloutData.DesktopOkToCloseProcedure = IntDesktopOkToClose; > + CalloutData.WindowStationOkToCloseProcedure = IntWinstaOkToClose; > > /* Register our per-process and per-thread structures. */ > PsEstablishWin32Callouts((PWIN32_CALLOUTS_FPNS)&CalloutData); > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -166,6 +166,29 @@ > RemoveEntryList(&Desktop->ListEntry); > > IntFreeDesktopHeap(Desktop); > +} > + > +NTSTATUS NTAPI > +IntDesktopOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters) > +{ > + PTHREADINFO pti; > + > + pti = PsGetCurrentThreadWin32Thread(); > + > + if( pti == NULL) > + { > + /* This happens when we leak desktop handles */ > + return TRUE; > + } > + > + /* Do not allow the current desktop or the initial desktop to be closed */ > + if( Parameters->Handle == pti->ppi->hdeskStartup || > + Parameters->Handle == pti->hdesk) > + { > + return FALSE; > + } > + > + return TRUE; > } > > /* PRIVATE FUNCTIONS **********************************************************/ > > Modified: trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/ntuser/winsta.c [iso-8859-1] Tue Mar 22 09:19:26 2011 > @@ -187,6 +187,21 @@ > return STATUS_OBJECT_TYPE_MISMATCH; > } > > +NTSTATUS NTAPI > +IntWinstaOkToClose(PWIN32_OKAYTOCLOSEMETHOD_PARAMETERS Parameters) > +{ > + PPROCESSINFO ppi; > + > + ppi = PsGetCurrentProcessWin32Process(); > + > + if(Parameters->Handle == ppi->hwinsta) > + { > + return FALSE; > + } > + > + return TRUE; > +} > + > /* PRIVATE FUNCTIONS **********************************************************/ > > /* > @@ -915,6 +930,57 @@ > return WinStaObj; > } > > +BOOL FASTCALL > +UserSetProcessWindowStation(HWINSTA hWindowStation) > +{ > + PPROCESSINFO ppi; > + NTSTATUS Status; > + HWINSTA hwinstaOld; > + PWINSTATION_OBJECT NewWinSta = NULL, OldWinSta; > + > + ppi = PsGetCurrentProcessWin32Process(); > + > + if(hWindowStation !=NULL) > + { > + Status = IntValidateWindowStationHandle( hWindowStation, > + KernelMode, > + 0, > + &NewWinSta); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT("Validation of window station handle (0x%X) failed\n", > + hWindowStation); > + SetLastNtError(Status); > + return FALSE; > + } > + } > + > + OldWinSta = ppi->prpwinsta; > + hwinstaOld = ppi->hwinsta; > + > + /* > + * FIXME - don't allow changing the window station if there are threads that are attached to desktops and own gui objects > + */ > + > + InterlockedExchangePointer(&PsGetCurrentProcess()->Win32WindowStation, hWindowStation); > + > + ppi->prpwinsta = NewWinSta; > + ppi->hwinsta = hWindowStation; > + > + > + if(OldWinSta != NULL) > + { > + ObDereferenceObject(OldWinSta); > + } > + > + if(hwinstaOld != NULL) > + { > + ZwClose(hwinstaOld); > + } > + > + return TRUE; > +} > + > /* > * NtUserSetProcessWindowStation > * > @@ -934,44 +1000,15 @@ > BOOL APIENTRY > NtUserSetProcessWindowStation(HWINSTA hWindowStation) > { > - PWINSTATION_OBJECT NewWinSta; > - NTSTATUS Status; > - > - DPRINT("About to set process window station with handle (0x%X)\n", > - hWindowStation); > - > - if(PsGetCurrentProcess() == CsrProcess) > - { > - DPRINT1("CSRSS is not allowed to change it's window station!!!\n"); > - EngSetLastError(ERROR_ACCESS_DENIED); > - return FALSE; > - } > - > - Status = IntValidateWindowStationHandle( > - hWindowStation, > - KernelMode, > - 0, > - &NewWinSta); > - > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("Validation of window station handle (0x%X) failed\n", > - hWindowStation); > - SetLastNtError(Status); > - return FALSE; > - } > - > - /* > - * FIXME - don't allow changing the window station if there are threads that are attached to desktops and own gui objects > - */ > - > - /* FIXME - dereference the old window station, etc... */ > - InterlockedExchangePointer(&PsGetCurrentProcess()->Win32WindowStation, hWindowStation); > - > - DPRINT("PsGetCurrentProcess()->Win32WindowStation 0x%X\n", > - PsGetCurrentProcess()->Win32WindowStation); > - > - return TRUE; > + BOOL ret; > + > + UserEnterExclusive(); > + > + ret = UserSetProcessWindowStation(hWindowStation); > + > + UserLeave(); > + > + return ret; > } > > /* > >

13 23

GSoC 2011 idea
by Ilie Halip 30 Mar '11

30 Mar '11

Hi! My name is Ilie Halip, and I'm a student at the Faculty of Computer Science, in Iasi, Romania. I'd like to take part in this year's Google Summer of Code, and I was browsing the ideas page earlier. What caught my eye was the Management Console, but after some discussions on IRC, I got very excited about another thing not listed on the wiki page for GSoC. It's about implementing support for Windows Error Reporting. It's listed at http://reactos.org/wiki/Missing_ReactOS_Functionality. I think it's doable in less than 3 months, and might prove to be helpful too (the wiki page sais that :P). I'm not sure if you would accept this kind of proposal, so I'm here to ask about that. Also, I would need a mentor to help me with this project - so... would anyone be willing to mentor me, if this project would be accepted? I was also looking at WMI, but I know it's huge, and I'm not sure how much of it would be required to consider such a project successful. Also, another thing I should mention. I do have a full time job right now. That's a reason I didn't dive into anything bigger listed on the ideas page. Even though I do have some experience writing Windows drivers (I wrote a file system filter driver 2 years back), I don't think I'd be able to write an Intel HDA driver in less than 3 months. But I talked to my superiors, and they are willing to let me work part-time during GSoC, so I should be able to work for my would-be project about 30 hours/week. Do you think that's enough? Regards, Ilie.

4 4

Re: [ros-dev] [NTDLL/LDR] - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table.
by Minas Abrahamyan 30 Mar '11

30 Mar '11

Hi Alexey, Since you are still working on these LdrXXX functions then you maybe find possibility to add there some code to prevent them trapping into infinite cycle (bug 5881: http://www.reactos.org/bugzilla/show_bug.cgi?id=5881 ) While booted up with RAM 25 or 24 MB ROS kernel falls into infinite cycle there, but being booted up with 15 Mbs ROS stalls and and hangs up. To test it is enough to run it on any VM with 24Mb of RAM. What occurs there is infinite recursive calls, in form of LdrpLoadModule ->calls LdrFixupImports -> LdrpGetOrLoadModule -> LdrpLoadModule and so forth. (detailed bt is in bug 5881 description). Maybe ROS kernel doesn't check memory availability, something like XXXMalloc returning NULL or so. Thanks! -M.A. On Wed, Mar 23, 2011 at 4:25 PM, <fireball(a)svn.reactos.org> wrote: > Author: fireball > Date: Wed Mar 23 12:25:53 2011 > New Revision: 51123 > > URL: http://svn.reactos.org/svn/reactos?rev=51123&view=rev > Log: > [NTDLL/LDR] > - Fix a few bugs (wrong variable usage, wrong variable initialization) which led to incorrect snapping of import address table. > - Wrap LdrpSnapThunk() invocations into SEH. > > Modified: > trunk/reactos/dll/ntdll/ldr/ldrpe.c > > Modified: trunk/reactos/dll/ntdll/ldr/ldrpe.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrpe.c?rev=…

2 2

SSPI and Interactive logon GSOC Proposal
by Samuel serapion 30 Mar '11

30 Mar '11

Hello fellow ReactOS developers and users, Most of you might know me from IRC as encoded. I am a Computer Science student at the Polytechnic University of Puerto Rico. Although at times not the best IRC citizen, I've always had the best intentions for ReactOS at heart. The following is my proposal/plan outline for Implementing SSPI and secure authentication mechanisms for ReactOS, including Interactive Logon. First, some definitions: Security Support Provider Interface (SSPI) allows applications to use various security models available on a computer or network without changing the interface to the security system. SSPI does not establish logon credentials because that is generally a privileged operation handled by the operating system(LSA). Windows Challenge/Response (NTLM) is the authentication protocol used on systems running Windows. NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire(in case there is a wire). Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials. Secure Channel, also known as Schannel, is a security support provider (SSP) that contains a set of security protocols that provide identity authentication and secure, private communication through encryption. Mainly SSL and TLS, with a variety of cipher options. Primary goals: - Utilize wine secur32 as starting point for implementing SSPI. - NTLM Security Support Provider (SSP) -- Authentication -- feature flags -- SignMessage -- VerifyMessage -- EncryptMessage -- DecryptMessage - Small, low footprint, maintainable code - Implement create credentials/logon/authentication in LSA -- LogonUser -- LsaConnectUntrusted -- others, as necessary. - Separate secur32 and schannel(wine has them unified) Secondary goals: - implement SSL/TLS/ptc SSP (using 3rd party libs) -- GnuTLS, OpenSSL are huge and have many dependencies -- secur32 is (theoretically) loaded and used by many system dlls, would be very bad if it is a performance/memory hog. -- Need to severely trim them down or use alternatives. - run extensive tests/fix other system code paths that have been dormant/stubs why wine secur32 is bad: - Wine is a *nix program so its ok for them to use dlopen(gnutls.so)... and use the system native library but we cant. - Uses fork() to call a program in winbind(samba extra) package! - if we want to use gnutls and such in reactos the following problems occur: -- too many dependencies -- problems running in native mode(lsa) -- big footprint -- too much code/hard to maintain - Wine's implementation of schannel loads GnuTLS, and is barely functional. - wine winhttp and wininet don't use schannel, and instead use OpenSSL directly to implement SSL and TLS. This can lead to confusing differences in certificate verification between applications. Ideally, schannel would use crypt32 for certificate chain verification, and winhttp and wininet would use schannel. (fixme later) -- good news is, wine crypt32 is relatively good and feature complete (at least seems that way).

3 2

GSoC: Kernel-Mode Test Suite
by Thomas Faber 30 Mar '11

30 Mar '11

Hi, I guess I don't have to introduce myself all that much anymore ;) Please see [1] if you disagree. I plan to submit a GSoC project proposal concerning the kernel-mode test suite, and would like to discuss a few key points to better shape the project idea and its timeline. Because of the broadness of the subject, I'm posting here to reach as many ears (er... eyes) as possible, hoping for feedback from people working on several different areas of ROS. My "state of mind" is currently the following regarding the project: Basic key points (I hope everyone agrees; please tell me if I'm wrong :p) - follow Winetest "feeling" - syntax for writing tests should be almost identical; like current kmtests demonstrate - tests should be startable individually from a command line launcher and follow Winetest behavior in that regard, so that an integration with Testman is made easy - code should be CMake and MSVC/WDK compatible from the beginning Ideas I deem useful (would appreciate any comments) - include buffer overrun checks, much like DPH (DPH can't be used for this though, can it?), using e.g. a guard/noaccess page behind each buffer. See [2] for a userland example; I'm working on a kernel-mode one - inspired by Winetest's broken(), one could make tests Windows-version specific. Something like [but better thought-out in syntax] ok(win2k3sp1(ret == 0) | win7x64sp1(ret == 1), ...) This would help compare different versions of Windows and much facilitate future kernel-target switching Questions - as there are ... many... kernel-mode functions, it is unfeasible to write tests for all during the project. My idea would be to create some very thorough sample tests, then focus on the most critical functions. "If there's time", thinly covering a more broad area might also be very useful (as extending existing tests is probably deemed easier than creating new ones by people later on). I have no doubt there's enough to do, ;) but would be interested to hear if you agree with the general strategy and what you think those "critical" areas might be. So what do you guys think? Excited for your input. Thanks. :) Regards, Tom [1] Hi! I'm Thomas, 23, from Germany, currently studying Computer Engineering in Berlin. I've been hanging out on IRC as ThFabba for some time now and submitted some hopefully-not-totally-useless patches ;) I'm interested in.... oh well, pretty much all parts of ROS. *g* Nice to meet you! [2] http://www.reactos.org/paste/index.php/8697/

2 1

Request for apply to GSoC 2011
by Fabio Cristini 30 Mar '11

30 Mar '11

Good day to all, my name is Fabio Cristini. I work as a software designer and developer in Italy, I'm a student in Software Engineering and I would like to apply for a React OS project proposal. I especially like the idea of implementing an SSH Service for Windows, and I hope I can do it for you (I like to develop an OpenSSH clone). Please let me know if you may be intrested. Fabio Cristini Italian, English +1 UTC fcristini(a)gmail.com (not registered yet) if you can contact me in private, I can give you more details and my full contact informations. Many thanks Time Commitment I can work at this project about 20 hours a week Optional (But Suggested) SSH Service for Windows http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas#SSH_Service Legal Requirements Students are required to affirm that the following is true. I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.

2 1

INTRODUCING MYSELF TO THE ROS COMMUNITY.
by Armaan 30 Mar '11

30 Mar '11

Hello friends, I am Syed Armani, i am a 3rd year computer science student at DCE ,NCR, INDIA Email: dce3062(a)gmail.com IRC: #armaan Jabber: syedarmani(a)jabber.org *ABOUT ME:* I have experience of - c/c++ - GUI development with c++. - python - java - lua - NETWORK PROTOCOLS - NETWORK PROGRAMMING - xhtml/css/javascript - Assembly (mid level 8085 n 8086) - BASH scripting. - VIRTUALIZATION, WORKING OF HYPERVISORS AND LIBVERT. - PHP - MYSQL - DEEP LEVEL LINUX OS - BASH SCRIPTING - LAMP/WAMP - WEB 2.0 - Android apps development I have a personality of a creative explorer and i always seek knowledge. I consider experience as a very very important thing. My wish is to take part in the development process of react os. Regards Syed Armani

2 1

Re: [ros-dev] unanswered gsoc mails
by Ged Murphy 30 Mar '11

30 Mar '11

Thanks for that guys, it's really helpful.... From: Ged Murphy [mailto:gedmurphy@gmail.com] Sent: 29 March 2011 11:22 To: 'ReactOS Development List' Subject: unanswered gsoc mails I've noticed there are quite a few emails to ros-dev regarding GSoC participation with no replies. Can someone reply to these in my absence, I won't be around for a few more days yet. As usual, I'm contactable by email and msn. Ged.

1 0

unanswered gsoc mails
by Gerard Murphy 29 Mar '11

29 Mar '11

I've noticed there are quite a few emails to ros-dev regarding GSoC participation with no replies. Can someone reply to these in my absence, I won't be around for a few more days yet. As usual, I'm contactable by email and msn. Ged.

1 0

Merging liveCD and Install CD
by Andrew Green 29 Mar '11

29 Mar '11

I have been thinking about what will be needed for my gsoc proposal. Merging the live cd and install cd of React OS is one of the goals. Though the file structure is different on the install and live cd. The install cd has all the React OS files in a cab file. While live cd has everything in a folder. I do understand the differences are larger than this. Though this has a large duplication of files. I assume having the files in folders is the best solution because the live cd needs access to the files directly. I was wondering what peoples preferred methods would be. People mentioned various things on irc. like extracting from the cab file on the fly, or installing the cab to ram disk and so on. I was wondering what peoples views is on what they would want. Feel free to say your preferences. I may not choose the best solution in my proposal because I will only have 3 or 4 weeks to work on that part. I personally don't think loosing the 100mb of saved space from the cab is a bad thing. It will still fit on 1 cd(i'm guessing 150-200mb) and is better than burning 2 cds(1 for live and 1 for install). Any comments or advice are much appreciated.

3 4

Re: [ros-dev] MP/UP HAL issues
by Love Nystrom 29 Mar '11

29 Mar '11

> > ---------- Forwarded message ---------- > From: Olaf Siejka <caemyr(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Date: Sun, 27 Mar 2011 14:35:18 +0200 > Subject: Re: [ros-dev] MP/UP HAL issues > "but *compile time* is not even 10% as important as *run time*." > > I think Love that you do not imagine what is the impact of buildtime in our > project. As ReactOS is not getting smaller, increased buildtime is simply > slowing down development pace by a considerable margin. It might be a worthy > tradeoff for a project with production version already, but not in our case. > Reaching over 10 minutes of buildtime requires really top of the line > hardware, not to mention dedicating whole host system to this task. For > average team member, it takes not 10 but even over 30-40 minutes to do a > full build. Time that is often so precious to spare. > Yes, Olaf, I *do* consider the impact of build time. It used to take me ~30 min to do a full build. This made me abandon the RAD "trial-and-error" rebuild paradigm, and return to the old-fashioned way of "running the code in my head" a number of times before doing another build. Now I have a faster machine and a full build takes ~10-15 min, but I still stick with the old-fashioned way of coding with those build times. As for time spared, consider this, You may save 2-5 min build time, but that time is paid for by millions of users, over and over and over again... *That* is what I mean. WBR // Love

1 0

Re: [ros-dev] MP/UP HAL issues
by Love Nystrom 29 Mar '11

29 Mar '11

> > ---------- Forwarded message ---------- > From: Timo Kreuzer <timo.kreuzer(a)web.de> > Subject: Re: [ros-dev] MP/UP HAL issues > > Am 26.03.2011 11:45, schrieb Love Nystrom: > To me, performance is *everything* .. > I gladly spend a *week* to gain significant performance, > especially if it also makes the code clearer and more readable! > > And what if it makes the code harder to read and maintain or if its likely > to introduce bugs later? Performance is great, but you need to be > reasonable. Saving a few clock cycles, saving you a microsecond per minute > runtime is not worth downgrading code quality. Its not even worth massively > increasing build time. > Ah.. Yes, *code clarity* (and proper comments) is of course a primary. We all know the headache of fixing code we wrote a year ago and didn't take the time to make stringent and/or comment properly. Btw. when I mention performance improvements, I meant in the order of at least > 5-10%. We all know that's never achieved by a cpl of asm tweaks, always by improved algorithms. As for Win7 I can't tell either way, since I don't have it.. Just a general note that apps that would fit well in 3MB RAM if written properly, now seem to hog up at least 30MB wherever it comes from, and runtime has gone the same way. C# + .NET issue perhaps? Or just incompetent newbie programmers running amok? Dropping single core processor support sound like a bad idea to me. > > Tell that MS, they did that with Windows Vista already. > I tried telling MS a lot of things.. Like fixing some of their bugs that *still live* since the days of NT4 at least. All I I ever got was a blatant "Won't Fix". So.. F them! Also I wasn't even talking about dropping the up kernel, I suggested > compiling it in a different manner, that would not allow inlining spinlock > functions as its done currently, but would cause them to be called. The > function would be linked as UP or SMP depending on whether we are using UP > or SMP kernel (can be done at link time or even at runtime). > I understand. > This way we save us the complete MP kernel build time (almost 2 minutes on > my machine). > Well.. as I said.. personally I don't give a hoot about another 2 minutes build time. > IMO it would also make it easier to maintain the SMP kernel. > Now *that* (code clarity and maintainability) is a more important issue IMO. In my book, that usually means using *the same code* with *minor* precomp switches. WBR // Love > >

1 0

Re: [ros-dev] MP/UP HAL issues
by Love Nystrom 27 Mar '11

27 Mar '11

> > ---------- Forwarded message ---------- > From: Timo Kreuzer <timo.kreuzer(a)web.de>\ > [abbreviated] > > I'm against wasting precious compile time for an MP hal that doesn't even > work. And I would actually like to have the kernel being compiled the same > way. I bet the performance improvements of inlining some spinlock code are > really neglectable. > I hate being a spoilsport, especially on an issue that may have gone stale already, but *compile time* is not even 10% as important as *run time*. I dunno about the particulars in this case, it's just a general priority opinion. To me, performance is *everything* .. I gladly spend a *week* to gain significant performance, especially if it also makes the code clearer and more readable! Is it just I who think that software is getting slower and slower and bigger and bigger these days? And I mean particularly the goo gaa that comes out of Redmond these days :-/ But as everybody in the world seems to play "Follow John" with Microsoft, users are left with software where they have to go for a coffe break after giving a command before their multicore superduper computers even give a burp, because programmers care less about runtime than compile time these days :( Blame the RAD frenzy for that! I'd even go as far as dropping UP support completely and hotpatching > spinlock functions. > Dropping single core processor support sound like a bad idea to me. W.B.R. // Love

4 3

[GSOC]GUI first stage installer
by Andrew Green 26 Mar '11

26 Mar '11

I'm looking to put in a proposal for gui 1st stage installer. I've asked around a bit on IRC who would be the mentor. Though no one seems to know. If anyone could point me in the right direction that would be great. I was thinking of how it would be implemented. I know the gui mostly exists in svn. so that simplifies that. I was thinking that the parts of the project would be setting it up so that as much code is shared between text-mode installer and gui installer. 1st stage gui installer should be able to run in windows as well as ros(this could simplify the install when using windows and make it easy to test the installer) Also fixing the functions that are used. As it seems at the moment disk drives are not appearing as devices. I have been unable to find an api that creates partitions. I thought this would be good rather than manipulating the disk directly as it may provide the ability to create partitions for any file system as long as a driver exists. Making it more flexible. I am also rather excited about this project as the skills that I gain from this could be used to make the disk manager, and other disk utilities. Any comments would be much appreciated.

3 4

Re: [ros-dev] [ros-diffs] [rharabien] 51135: [PSDK] Import strsafe.h from mingw-w64. It's more complete compared to our headers [DDK] Import ntstrsafe.h from mingw-w64 (converted from strsafe.h). It's more complete compared...
by Aleksey Bragin 26 Mar '11

26 Mar '11

We use SIZE_T throughout the kernel, so I don't understand why change a couple of places (out of thousands) to size_t ? Is there an incompatibility between strsafe headers and that type? Then it would need fixing instead. Also not sure if that was on purpose, but you also removed null- termination in ex/init.c, but it's not mentioned in the commit message. WBR, Aleksey Bragin. On Mar 26, 2011, at 12:42 AM, rharabien(a)svn.reactos.org wrote: > Author: rharabien > Date: Fri Mar 25 21:42:48 2011 > New Revision: 51135 > > URL: http://svn.reactos.org/svn/reactos?rev=51135&view=rev > Log: > [PSDK] > Import strsafe.h from mingw-w64. It's more complete compared to our > headers > > [DDK] > Import ntstrsafe.h from mingw-w64 (converted from strsafe.h). It's > more complete compared to our headers > > [NTOSKRNL] > Use sizeof instead of magic numbers > > Let's use strsafe functions now instead of strncpy/wcsncpy, which > doesn't always NULL terminate :) > > Modified: > trunk/reactos/base/applications/notepad/notepad.h > trunk/reactos/include/ddk/ntstrsafe.h > trunk/reactos/include/psdk/strsafe.h > trunk/reactos/ntoskrnl/ex/init.c > > [This mail would be too long, it was shortened to contain the URLs > only.] > > Modified: trunk/reactos/base/applications/notepad/notepad.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/ > applications/notepad/notepad.h?rev=51135&r1=51134&r2=51135&view=diff > > Modified: trunk/reactos/include/ddk/ntstrsafe.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ > ntstrsafe.h?rev=51135&r1=51134&r2=51135&view=diff > > Modified: trunk/reactos/include/psdk/strsafe.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ > strsafe.h?rev=51135&r1=51134&r2=51135&view=diff > > Modified: trunk/reactos/ntoskrnl/ex/init.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/ > init.c?rev=51135&r1=51134&r2=51135&view=diff > >

3 2

Re: [ros-dev] [ros-diffs] [rharabien] 51139: [WIN32K] Make sure strings returned by internal function RegQueryValue are NULL terminated
by Timo Kreuzer 26 Mar '11

26 Mar '11

This breaks REG_MULTI_SZ Am 25.03.2011 23:34, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Fri Mar 25 22:34:53 2011 > New Revision: 51139 > > URL:http://svn.reactos.org/svn/reactos?rev=51139&view=rev > Log: > [WIN32K] > > Make sure strings returned by internal function RegQueryValue are NULL terminated > > Modified: > trunk/reactos/subsystems/win32/win32k/misc/registry.c > > Modified: trunk/reactos/subsystems/win32/win32k/misc/registry.c > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/misc/registry.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/misc/registry.c [iso-8859-1] Fri Mar 25 22:34:53 2011 > @@ -58,7 +58,7 @@ > ULONG cbInfoSize, cbDataSize; > > /* Check if the local buffer is sufficient */ > - cbInfoSize = sizeof(KEY_VALUE_PARTIAL_INFORMATION) + *pcbValue; > + cbInfoSize = FIELD_OFFSET(KEY_VALUE_PARTIAL_INFORMATION, Data) + *pcbValue; > if (cbInfoSize<= sizeof(ajBuffer)) > { > pInfo = (PVOID)ajBuffer; > @@ -89,8 +89,11 @@ > /* Did we get the right type */ > if (pInfo->Type == ulType) > { > - /* Copy the contents to the caller */ > - RtlCopyMemory(pvData, pInfo->Data, min(*pcbValue, cbDataSize)); > + /* Copy the contents to the caller. Make sure strings are null terminated */ > + if (ulType == REG_SZ || ulType == REG_MULTI_SZ || ulType == REG_EXPAND_SZ) > + RtlStringCbCopyNW((LPWSTR)pvData, *pcbValue, (LPWSTR)pInfo->Data, cbDataSize); > + else > + RtlCopyMemory(pvData, pInfo->Data, cbDataSize); > } > else > Status = STATUS_OBJECT_TYPE_MISMATCH; > > >

1 0

Re: [ros-dev] [ros-diffs] [rharabien] 51126: [NTOSKRNL] Revert r51108. ProbeForRead doesn't check if memory is readable. Improve comments and replace trick raising exception with call to ExRaiseAccessViolation. [WIN32K] Rem...
by Timo Kreuzer 24 Mar '11

24 Mar '11

Hi, Please also revert the call to ExRaiseAccessViolation. The behaviour is semi-documented here: http://www.uninformed.org/?v=10&a=2 There's a small but potentially important difference, which is the value of the faulting address. Thanks, Timo Am 23.03.2011 16:49, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Wed Mar 23 15:49:44 2011 > New Revision: 51126 > > URL: http://svn.reactos.org/svn/reactos?rev=51126&view=rev > Log: > [NTOSKRNL] > Revert r51108. ProbeForRead doesn't check if memory is readable. > Improve comments and replace trick raising exception with call to ExRaiseAccessViolation. > > [WIN32K] > Remove ASSERTs in IntSetSysColors: this function is only called in NtUserSetSysColors in SEH block. It shouldn't crash for NULL pointers. > > Modified: > trunk/reactos/ntoskrnl/ex/exintrin.c > trunk/reactos/subsystems/win32/win32k/objects/stockobj.c > > Modified: trunk/reactos/ntoskrnl/ex/exintrin.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/exintrin.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] Wed Mar 23 15:49:44 2011 > @@ -104,7 +104,6 @@ > IN ULONG Alignment) > { > ULONG_PTR Last, Current = (ULONG_PTR)Address; > - CHAR Temp; > PAGED_CODE(); > > /* Only probe if we have a valid length */ > @@ -132,16 +131,7 @@ > ExRaiseAccessViolation(); > } > > - /* Round down to the last page */ > - Last = PAGE_ROUND_DOWN(Last) + PAGE_SIZE; > - do > - { > - /* Attempt a read */ > - Temp = *(volatile CHAR*)Current; > - > - /* Go to the next address */ > - Current = PAGE_ROUND_DOWN(Current) + PAGE_SIZE; > - } while (Current != Last); > + /* ProbeForRead doesn't check if memory pages are readable! */ > } > } > > > Modified: trunk/reactos/subsystems/win32/win32k/objects/stockobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/ob… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/objects/stockobj.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/objects/stockobj.c [iso-8859-1] Wed Mar 23 15:49:44 2011 > @@ -221,9 +221,6 @@ > { > UINT i; > > - ASSERT(Elements); > - ASSERT(Colors); > - > for (i = 0; i< nColors; i++) > { > if ((UINT)(*Elements)< NUM_SYSCOLORS) > > >

1 0

GSOC Self-Presentation
by perencia 22 Mar '11

22 Mar '11

Hi!, my name is Pedro, and i'm a 5th grade student of computer science in Universitat Autonoma de Barcelona ( Spain ). I'd like to apply in this gsoc, i've always wanted to be part of an open-source project, i think it can be a really profitable and exciting experience to share ideas and discuss them with other motivated coders. Now as i'm finishing my last year i've found myself attracted by low-level questions. I've been aware of ReactOS for some time now - couple of years ago I downloaded the code and submitted a patch for the build system - actually, very silly patch :). About the projects proposed, some of them seem a bit heavy for me. At first the ACPI Hal cought my attention, since i'm doing my final year project en the energy-performance tradeoff in multi-cores, but it seems very daunting, i have no experience in kernel development nor drivers. Although is in Java where i'm really experienced, I'm confident with c and c++, and i'm very interested in COM, I've done some of it in DirectX and i really enjoyed that, so i thought the MMC Console seems more affordable. Anyway, i'd like to get some advice, if that's possible, about where i could direct myself, which project my profile may fit better or which has greater priority, and what can i do to start getting in contact to the project and make a better apply proposal. I hope this would be a beginning of a great and profitable experience for me and the community :)

3 3

Re: [ros-dev] [ros-diffs] [cfinck] 51118: Create a branch for Neeraj Yadav's work on the Audio Mixer
by Ged Murphy 22 Mar '11

22 Mar '11

This seems a little premature. I assume Neeraj is aware that there's no guarantee that the audio mixer will be one of the selected GSoC projects? I'm by no means suggesting that we would do this, but good business sense says that if someone is willing to work on a component outside of GSoC, isn't it counter-productive for the project to use one of their slots up? Anyway, we'll see what we have on the April 8 deadline. I wish Neeraj luck in both his application and his forthcoming work in reactos. Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of cfinck(a)svn.reactos.org Sent: 22 March 2011 12:46 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [cfinck] 51118: Create a branch for Neeraj Yadav's work on the Audio Mixer Author: cfinck Date: Tue Mar 22 12:45:40 2011 New Revision: 51118 URL: http://svn.reactos.org/svn/reactos?rev=51118&view=rev Log: Create a branch for Neeraj Yadav's work on the Audio Mixer Added: branches/nyadav-audio-branch/ - copied from r51117, trunk/

1 0

Introduction
by Neeraj Yadav 22 Mar '11

22 Mar '11

Hello, My name is Neeraj Yadav. I am an undergraduate student of Indian Institute of Technology, Delhi studying Textile Engineering.Besides my regular studies I have interest in Multimedia, Networking, Network-Programming and Security.I have a decent knowledge of C and C++ programming.I am familiar with git and svn.I am familiar with Linux, windows and Symbian APIs.I have experience of UI design with Qt. ReactOS is coming as my new interest and luckily this year ReactOS has been selected as a mentoring organisation.I find myself appropriate for SSH server implementation and Audio Mixer Project.

2 1

Re: [ros-dev] [ros-diffs] [rharabien] 51108: Fix ProbeForRead. It wasn't ever checking if memory can be accessed. Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is now nearly the same as in ProbeFo...
by Timo Kreuzer 22 Mar '11

22 Mar '11

Windows doesn't do any access checks in ProbeForRead, it only checks the range and alignment. The MmUserProbeAddress access is used to raise an exception with the appropriate parameters. So the old version was correct (except for the misleading comment maybe) Am 21.03.2011 15:43, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Mon Mar 21 14:43:56 2011 > New Revision: 51108 > > URL: http://svn.reactos.org/svn/reactos?rev=51108&view=rev > Log: > Fix ProbeForRead. It wasn't ever checking if memory can be accessed. Thanks to big-endian it wasn't breaking MmUserProbeAddress as well. Code is now nearly the same as in ProbeForWrite. It shouldn't break anything. If it does, it's not bug in this code. :) > > Modified: > trunk/reactos/ntoskrnl/ex/exintrin.c > > Modified: trunk/reactos/ntoskrnl/ex/exintrin.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/exintrin.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/exintrin.c [iso-8859-1] Mon Mar 21 14:43:56 2011 > @@ -103,6 +103,8 @@ > IN SIZE_T Length, > IN ULONG Alignment) > { > + ULONG_PTR Last, Current = (ULONG_PTR)Address; > + CHAR Temp; > PAGED_CODE(); > > /* Only probe if we have a valid length */ > @@ -115,18 +117,31 @@ > (Alignment == 8) || > (Alignment == 16)); > > - /* Check for correct alignment */ > - if (((ULONG_PTR)Address& (Alignment - 1)) != 0) > + /* Check the alignment */ > + if ((Current& (Alignment - 1)) != 0) > { > /* Incorrect alignment */ > ExRaiseDatatypeMisalignment(); > } > - else if (((ULONG_PTR)Address + Length)< (ULONG_PTR)Address || > - ((ULONG_PTR)Address + Length)> (ULONG_PTR)MmUserProbeAddress) > + > + /* Get the end address */ > + Last = Current + Length - 1; > + if ((Last< Current) || (Last>= (ULONG_PTR)MmUserProbeAddress)) > + { > + /* Raise an access violation */ > + ExRaiseAccessViolation(); > + } > + > + /* Round down to the last page */ > + Last = PAGE_ROUND_DOWN(Last) + PAGE_SIZE; > + do > { > /* Attempt a read */ > - *(volatile CHAR* const)MmUserProbeAddress = 0; > - } > + Temp = *(volatile CHAR*)Current; > + > + /* Go to the next address */ > + Current = PAGE_ROUND_DOWN(Current) + PAGE_SIZE; > + } while (Current != Last); > } > } > > > >

2 2

Server down
by Pierre Schweitzer 22 Mar '11

22 Mar '11

Hi, both doxygen.reactos.org & iso.reactos.org are down (which results in daily builds isos not being uploaded). Anyone able to fix them? Regards, P. Schweitzer

1 0

HAL multi-targeted build
by Pierre Schweitzer 22 Mar '11

22 Mar '11

Hi, currently working on HAL and HAL targets (ACPI, MP, UP and so on), I discovered a quite bad issue in our build process. Just look at the function HalInitSystem@8 (halinit.c), depending on the build target we don't add the same code (look at CONFIG_SMP, which is only defined for HAL MP). But, currently, as we are building using HAL library for reducing code redudancy, this halinit.c file is only built ONCE. So, build targets aren't taken into account (MP, ACPI). So, two choices, or we break that model, and forget about lib, and just keep base .rbuild (hal.rbuild, halacpi.rbuild, and so forth) with all files defined in those. Or with find something smarter better such as rebuilding the lib with the new flags for each build? Or finding a way to include .rbuild files in other rbuild files? I'm not really sure about the way to proceed, that's why I "release" that question to the whole ML. Furthermore, could CMAKE be any use here? To facilitate the process? Regards, P. Schweitzer

4 6

'Security Controls' GSoC Idea
by Guillaume Touron 21 Mar '11

21 Mar '11

Hello RoS developers, I introduce myself. I'm Guillaume Touron, I'm a French engineering student at National School of Computer Science and Applied Mathematics with specialization in information systems and security. Apart from my studies I am interested in OS development, Windows internals and application security (vulnerabilities, reverse engineering, rootkits...). I read a lot about how Windows internals work (kernel data structures...) and Windows security. I have also some experience in NT driver development and kernel debugger (WinDBG). For many months now, I study RoS source code, and especially ntoskrnl source. This includes object manager, i/o manager, security layer, traps/exceptions management... I checkouted source code and installed RoS build environment and I'm ready to begin development. I also took a look at Se* kernel exported APIs, and tried to understand how security checks were performed. That's why I'm interested in RoS GSoC Idea 'Security Controls'. Indeed, implementing this feature would be a good start to add multiuser experience in RoS which is currently missing, and to manage efficiently users and groups. I think I know what is needed to complete this project successfully and I'm ready to write a detailed presentation/proposal to explain what I understand and what would be my goals. I also did GSoC 2010 last year for Honeynet Project on network security area, but I'm more interested in kernel development. Finally, few questions : What should I do to propose in a formal way my proposal to RoS community ? Is it an obligation to have already send some patches or can we begin development as a new contributor ? Who can I contact to speak about technical details ? Thank you very much.

4 9

Re: [ros-dev] [ros-diffs] [rharabien] 51103: Don't destroy ImageList used by ListView if control was created without LVS_SHAREIMAGELISTS flag Fixes crashes when closing RegEdit, RApps and hardware tab in mouse settings.
by Gabriel ilardi 21 Mar '11

21 Mar '11

Welcome to the jungle! Nice to see you committing. Good luck and have fun! > Date: Mon, 21 Mar 2011 14:07:30 +0000 > To: ros-diffs(a)reactos.org > From: rharabien(a)svn.reactos.org > Subject: [ros-diffs] [rharabien] 51103: Don't destroy ImageList used by ListView if control was created without LVS_SHAREIMAGELISTS flag Fixes crashes when closing RegEdit, RApps and hardware tab in mouse settings. > > Author: rharabien > Date: Mon Mar 21 14:07:29 2011 > New Revision: 51103 > > URL: http://svn.reactos.org/svn/reactos?rev=51103&view=rev > Log: > Don't destroy ImageList used by ListView if control was created without LVS_SHAREIMAGELISTS flag > Fixes crashes when closing RegEdit, RApps and hardware tab in mouse settings. > > Modified: > trunk/reactos/base/applications/rapps/winmain.c > trunk/reactos/base/applications/regedit/childwnd.c > trunk/reactos/dll/cpl/input/settings.c > > Modified: trunk/reactos/base/applications/rapps/winmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/rapps/wi… > ============================================================================== > --- trunk/reactos/base/applications/rapps/winmain.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/rapps/winmain.c [iso-8859-1] Mon Mar 21 14:07:29 2011 > @@ -10,7 +10,6 @@ > > HWND hMainWnd; > HINSTANCE hInst; > -HIMAGELIST hImageListView = NULL; > HIMAGELIST hImageTreeView = NULL; > INT SelectedEnumType = ENUM_ALL_COMPONENTS; > SETTINGS_INFO SettingsInfo; > @@ -168,8 +167,8 @@ > { > WCHAR szBuffer1[MAX_STR_LEN], szBuffer2[MAX_STR_LEN]; > HICON hIcon; > - > - if (hImageListView) ImageList_Destroy(hImageListView); > + HIMAGELIST hImageListView; > + > (VOID) ListView_DeleteAllItems(hListView); > > /* Create image list */ > @@ -208,7 +207,11 @@ > } > > /* Set image list for ListView */ > - (VOID) ListView_SetImageList(hListView, hImageListView, LVSIL_SMALL); > + hImageListView = ListView_SetImageList(hListView, hImageListView, LVSIL_SMALL); > + > + /* Destroy old image list */ > + if (hImageListView) > + ImageList_Destroy(hImageListView); > > SelectedEnumType = EnumType; > > @@ -725,7 +728,6 @@ > FreeAvailableAppList(); > if (IS_INSTALLED_ENUM(SelectedEnumType)) > FreeInstalledAppList(); > - if (hImageListView) ImageList_Destroy(hImageListView); > if (hImageTreeView) ImageList_Destroy(hImageTreeView); > > PostQuitMessage(0); > > Modified: trunk/reactos/base/applications/regedit/childwnd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedit/… > ============================================================================== > --- trunk/reactos/base/applications/regedit/childwnd.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/regedit/childwnd.c [iso-8859-1] Mon Mar 21 14:07:29 2011 > @@ -65,7 +65,7 @@ > ReleaseDC(hWnd, hdc); > } > > -static void ResizeWnd(ChildWnd* pChildWnd, int cx, int cy) > +static void ResizeWnd(int cx, int cy) > { > HDWP hdwp = BeginDeferWindowPos(3); > RECT rt, rs, rb; > @@ -77,12 +77,12 @@ > GetWindowRect(hStatusBar, &rs); > cy = rs.bottom - rs.top; > } > - GetWindowRect(pChildWnd->hAddressBtnWnd, &rb); > - cx = pChildWnd->nSplitPos + SPLIT_WIDTH/2; > - DeferWindowPos(hdwp, pChildWnd->hAddressBarWnd, 0, rt.left, rt.top, rt.right-rt.left - tHeight-2, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > - DeferWindowPos(hdwp, pChildWnd->hAddressBtnWnd, 0, rt.right - tHeight, rt.top, tHeight, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > - DeferWindowPos(hdwp, pChildWnd->hTreeWnd, 0, rt.left, rt.top + tHeight+2, pChildWnd->nSplitPos-SPLIT_WIDTH/2-rt.left, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > - DeferWindowPos(hdwp, pChildWnd->hListWnd, 0, rt.left+cx, rt.top + tHeight+2, rt.right-cx, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > + GetWindowRect(g_pChildWnd->hAddressBtnWnd, &rb); > + cx = g_pChildWnd->nSplitPos + SPLIT_WIDTH/2; > + DeferWindowPos(hdwp, g_pChildWnd->hAddressBarWnd, 0, rt.left, rt.top, rt.right-rt.left - tHeight-2, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > + DeferWindowPos(hdwp, g_pChildWnd->hAddressBtnWnd, 0, rt.right - tHeight, rt.top, tHeight, tHeight, SWP_NOZORDER|SWP_NOACTIVATE); > + DeferWindowPos(hdwp, g_pChildWnd->hTreeWnd, 0, rt.left, rt.top + tHeight+2, g_pChildWnd->nSplitPos-SPLIT_WIDTH/2-rt.left, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > + DeferWindowPos(hdwp, g_pChildWnd->hListWnd, 0, rt.left+cx, rt.top + tHeight+2, rt.right-cx, rt.bottom-rt.top-cy, SWP_NOZORDER|SWP_NOACTIVATE); > EndDeferWindowPos(hdwp); > } > > @@ -111,7 +111,7 @@ > last_split = -1; > GetClientRect(hWnd, &rt); > g_pChildWnd->nSplitPos = x; > - ResizeWnd(g_pChildWnd, rt.right, rt.bottom); > + ResizeWnd(rt.right, rt.bottom); > ReleaseCapture(); > } > > @@ -125,7 +125,6 @@ > > static BOOL _CmdWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > { > - ChildWnd* pChildWnd = g_pChildWnd; > HTREEITEM hSelection; > HKEY hRootKey; > LPCTSTR keyPath, s; > @@ -143,18 +142,18 @@ > /* TODO */ > break; > case ID_TREE_EXPANDBRANCH: > - (void)TreeView_Expand(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd), TVE_EXPAND); > + (void)TreeView_Expand(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd), TVE_EXPAND); > break; > case ID_TREE_COLLAPSEBRANCH: > - (void)TreeView_Expand(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd), TVE_COLLAPSE); > + (void)TreeView_Expand(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd), TVE_COLLAPSE); > break; > case ID_TREE_RENAME: > - SetFocus(pChildWnd->hTreeWnd); > - (void)TreeView_EditLabel(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd)); > + SetFocus(g_pChildWnd->hTreeWnd); > + (void)TreeView_EditLabel(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd)); > break; > case ID_TREE_DELETE: > - hSelection = TreeView_GetSelection(pChildWnd->hTreeWnd); > - keyPath = GetItemPath(pChildWnd->hTreeWnd, hSelection, &hRootKey); > + hSelection = TreeView_GetSelection(g_pChildWnd->hTreeWnd); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, hSelection, &hRootKey); > > if (keyPath == 0 || *keyPath == 0) > { > @@ -164,18 +163,18 @@ > DeleteNode(g_pChildWnd->hTreeWnd, 0); > break; > case ID_TREE_EXPORT: > - ExportRegistryFile(pChildWnd->hTreeWnd); > + ExportRegistryFile(g_pChildWnd->hTreeWnd); > break; > case ID_EDIT_FIND: > FindDialog(hWnd); > break; > case ID_EDIT_COPYKEYNAME: > - hSelection = TreeView_GetSelection(pChildWnd->hTreeWnd); > - keyPath = GetItemPath(pChildWnd->hTreeWnd, hSelection, &hRootKey); > + hSelection = TreeView_GetSelection(g_pChildWnd->hTreeWnd); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, hSelection, &hRootKey); > CopyKeyName(hWnd, hRootKey, keyPath); > break; > case ID_EDIT_NEW_KEY: > - CreateNewKey(pChildWnd->hTreeWnd, TreeView_GetSelection(pChildWnd->hTreeWnd)); > + CreateNewKey(g_pChildWnd->hTreeWnd, TreeView_GetSelection(g_pChildWnd->hTreeWnd)); > break; > case ID_EDIT_NEW_STRINGVALUE: > case ID_EDIT_NEW_BINARYVALUE: > @@ -183,8 +182,8 @@ > SendMessage(hFrameWnd, WM_COMMAND, wParam, lParam); > break; > case ID_SWITCH_PANELS: > - pChildWnd->nFocusPanel = !pChildWnd->nFocusPanel; > - SetFocus(pChildWnd->nFocusPanel? pChildWnd->hListWnd: pChildWnd->hTreeWnd); > + g_pChildWnd->nFocusPanel = !g_pChildWnd->nFocusPanel; > + SetFocus(g_pChildWnd->nFocusPanel? g_pChildWnd->hListWnd: g_pChildWnd->hTreeWnd); > break; > default: > if ((wID >= ID_TREE_SUGGESTION_MIN) && (wID <= ID_TREE_SUGGESTION_MAX)) > @@ -196,7 +195,7 @@ > s += _tcslen(s) + 1; > wID--; > } > - SelectNode(pChildWnd->hTreeWnd, s); > + SelectNode(g_pChildWnd->hTreeWnd, s); > break; > } > return FALSE; > @@ -317,7 +316,6 @@ > LRESULT CALLBACK ChildWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > { > BOOL Result; > - ChildWnd* pChildWnd = g_pChildWnd; > > switch (message) > { > @@ -329,45 +327,45 @@ > /* load "My Computer" string */ > LoadString(hInst, IDS_MY_COMPUTER, buffer, sizeof(buffer)/sizeof(TCHAR)); > > - g_pChildWnd = pChildWnd = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ChildWnd)); > - > - if (!pChildWnd) return 0; > - _tcsncpy(pChildWnd->szPath, buffer, MAX_PATH); > - pChildWnd->nSplitPos = 250; > - pChildWnd->hWnd = hWnd; > - pChildWnd->hAddressBarWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Edit"), NULL, WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP, > + g_pChildWnd = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ChildWnd)); > + if (!g_pChildWnd) return 0; > + > + _tcsncpy(g_pChildWnd->szPath, buffer, MAX_PATH); > + g_pChildWnd->nSplitPos = 250; > + g_pChildWnd->hWnd = hWnd; > + g_pChildWnd->hAddressBarWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Edit"), NULL, WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP, > CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > hWnd, (HMENU)0, hInst, 0); > - pChildWnd->hAddressBtnWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Button"), _T("Â»"), WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP | BS_DEFPUSHBUTTON, > + g_pChildWnd->hAddressBtnWnd = CreateWindowEx(WS_EX_CLIENTEDGE, _T("Button"), _T("Â»"), WS_CHILD | WS_VISIBLE | WS_CHILDWINDOW | WS_TABSTOP | BS_DEFPUSHBUTTON, > CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > hWnd, (HMENU)0, hInst, 0); > - pChildWnd->hTreeWnd = CreateTreeView(hWnd, pChildWnd->szPath, (HMENU) TREE_WINDOW); > - pChildWnd->hListWnd = CreateListView(hWnd, (HMENU) LIST_WINDOW/*, pChildWnd->szPath*/); > - SetFocus(pChildWnd->hTreeWnd); > + g_pChildWnd->hTreeWnd = CreateTreeView(hWnd, g_pChildWnd->szPath, (HMENU) TREE_WINDOW); > + g_pChildWnd->hListWnd = CreateListView(hWnd, (HMENU) LIST_WINDOW/*, g_pChildWnd->szPath*/); > + SetFocus(g_pChildWnd->hTreeWnd); > > /* set the address bar and button font */ > - if ((pChildWnd->hAddressBarWnd) && (pChildWnd->hAddressBtnWnd)) > + if ((g_pChildWnd->hAddressBarWnd) && (g_pChildWnd->hAddressBtnWnd)) > { > hFont = (HFONT)GetStockObject(DEFAULT_GUI_FONT); > - SendMessage(pChildWnd->hAddressBarWnd, > + SendMessage(g_pChildWnd->hAddressBarWnd, > WM_SETFONT, > (WPARAM)hFont, > 0); > - SendMessage(pChildWnd->hAddressBtnWnd, > + SendMessage(g_pChildWnd->hAddressBtnWnd, > WM_SETFONT, > (WPARAM)hFont, > 0); > } > /* Subclass the AddressBar */ > - oldproc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(pChildWnd->hAddressBarWnd, GWL_WNDPROC); > - SetWindowLongPtr(pChildWnd->hAddressBarWnd, GWL_USERDATA, (DWORD_PTR)oldproc); > - SetWindowLongPtr(pChildWnd->hAddressBarWnd, GWL_WNDPROC, (DWORD_PTR)AddressBarProc); > + oldproc = (WNDPROC)(LONG_PTR)GetWindowLongPtr(g_pChildWnd->hAddressBarWnd, GWL_WNDPROC); > + SetWindowLongPtr(g_pChildWnd->hAddressBarWnd, GWL_USERDATA, (DWORD_PTR)oldproc); > + SetWindowLongPtr(g_pChildWnd->hAddressBarWnd, GWL_WNDPROC, (DWORD_PTR)AddressBarProc); > break; > } > case WM_COMMAND: > if(HIWORD(wParam) == BN_CLICKED) > { > - PostMessage(pChildWnd->hAddressBarWnd, WM_KEYUP, VK_RETURN, 0); > + PostMessage(g_pChildWnd->hAddressBarWnd, WM_KEYUP, VK_RETURN, 0); > } > else if (!_CmdWndProc(hWnd, message, wParam, lParam)) > { > @@ -383,7 +381,7 @@ > POINT pt; > GetCursorPos(&pt); > ScreenToClient(hWnd, &pt); > - if (pt.x>=pChildWnd->nSplitPos-SPLIT_WIDTH/2 && pt.x<pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > + if (pt.x>=g_pChildWnd->nSplitPos-SPLIT_WIDTH/2 && pt.x<g_pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > { > SetCursor(LoadCursor(0, IDC_SIZEWE)); > return TRUE; > @@ -392,10 +390,10 @@ > goto def; > case WM_DESTROY: > DestroyTreeView(); > - DestroyListView(pChildWnd->hListWnd); > + DestroyListView(g_pChildWnd->hListWnd); > DestroyMainMenu(); > - HeapFree(GetProcessHeap(), 0, pChildWnd); > - pChildWnd = NULL; > + HeapFree(GetProcessHeap(), 0, g_pChildWnd); > + g_pChildWnd = NULL; > PostQuitMessage(0); > break; > case WM_LBUTTONDOWN: > @@ -403,9 +401,9 @@ > RECT rt; > int x = (short)LOWORD(lParam); > GetClientRect(hWnd, &rt); > - if (x>=pChildWnd->nSplitPos-SPLIT_WIDTH/2 && x<pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > - { > - last_split = pChildWnd->nSplitPos; > + if (x>=g_pChildWnd->nSplitPos-SPLIT_WIDTH/2 && x<g_pChildWnd->nSplitPos+SPLIT_WIDTH/2+1) > + { > + last_split = g_pChildWnd->nSplitPos; > draw_splitbar(hWnd, last_split); > SetCapture(hWnd); > } > @@ -432,7 +430,7 @@ > RECT rt; > draw_splitbar(hWnd, last_split); > GetClientRect(hWnd, &rt); > - ResizeWnd(pChildWnd, rt.right, rt.bottom); > + ResizeWnd(rt.right, rt.bottom); > last_split = -1; > ReleaseCapture(); > SetCursor(LoadCursor(0, IDC_ARROW)); > @@ -476,9 +474,9 @@ > break; > > case WM_SETFOCUS: > - if (pChildWnd != NULL) > - { > - SetFocus(pChildWnd->nFocusPanel? pChildWnd->hListWnd: pChildWnd->hTreeWnd); > + if (g_pChildWnd != NULL) > + { > + SetFocus(g_pChildWnd->nFocusPanel? g_pChildWnd->hListWnd: g_pChildWnd->hTreeWnd); > } > break; > > @@ -486,22 +484,22 @@ > break; > > case WM_NOTIFY: > - if ((int)wParam == TREE_WINDOW) > + if ((int)wParam == TREE_WINDOW && g_pChildWnd != NULL) > { > switch (((LPNMHDR)lParam)->code) > { > case TVN_ITEMEXPANDING: > - return !OnTreeExpanding(pChildWnd->hTreeWnd, (NMTREEVIEW*)lParam); > + return !OnTreeExpanding(g_pChildWnd->hTreeWnd, (NMTREEVIEW*)lParam); > case TVN_SELCHANGED: > { > LPCTSTR keyPath, rootName; > LPTSTR fullPath; > HKEY hRootKey; > > - keyPath = GetItemPath(pChildWnd->hTreeWnd, ((NMTREEVIEW*)lParam)->itemNew.hItem, &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, ((NMTREEVIEW*)lParam)->itemNew.hItem, &hRootKey); > if (keyPath) > { > - RefreshListView(pChildWnd->hListWnd, hRootKey, keyPath); > + RefreshListView(g_pChildWnd->hListWnd, hRootKey, keyPath); > rootName = get_root_key_name(hRootKey); > fullPath = HeapAlloc(GetProcessHeap(), 0, (_tcslen(rootName) + 1 + _tcslen(keyPath) + 1) * sizeof(TCHAR)); > if (fullPath) > @@ -512,7 +510,7 @@ > else > fullPath = _tcscpy(fullPath, rootName); > SendMessage(hStatusBar, SB_SETTEXT, 0, (LPARAM)fullPath); > - SendMessage(pChildWnd->hAddressBarWnd, WM_SETTEXT, 0, (LPARAM)fullPath); > + SendMessage(g_pChildWnd->hAddressBarWnd, WM_SETTEXT, 0, (LPARAM)fullPath); > HeapFree(GetProcessHeap(), 0, fullPath); > /* disable hive manipulation items temporarily (enable only if necessary) */ > EnableMenuItem(GetSubMenu(hMenuFrame,0), ID_REGISTRY_LOADHIVE, MF_BYCOMMAND | MF_GRAYED); > @@ -547,15 +545,15 @@ > } > break; > case NM_SETFOCUS: > - pChildWnd->nFocusPanel = 0; > + g_pChildWnd->nFocusPanel = 0; > break; > case TVN_BEGINLABELEDIT: > { > LPNMTVDISPINFO ptvdi; > /* cancel label edit for rootkeys */ > ptvdi = (LPNMTVDISPINFO) lParam; > - if (!TreeView_GetParent(pChildWnd->hTreeWnd, ptvdi->item.hItem) || > - !TreeView_GetParent(pChildWnd->hTreeWnd, TreeView_GetParent(pChildWnd->hTreeWnd, ptvdi->item.hItem))) > + if (!TreeView_GetParent(g_pChildWnd->hTreeWnd, ptvdi->item.hItem) || > + !TreeView_GetParent(g_pChildWnd->hTreeWnd, TreeView_GetParent(g_pChildWnd->hTreeWnd, ptvdi->item.hItem))) > return TRUE; > break; > } > @@ -571,14 +569,14 @@ > ptvdi = (LPNMTVDISPINFO) lParam; > if (ptvdi->item.pszText) > { > - keyPath = GetItemPath(pChildWnd->hTreeWnd, TreeView_GetParent(pChildWnd->hTreeWnd, ptvdi->item.hItem), &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, TreeView_GetParent(g_pChildWnd->hTreeWnd, ptvdi->item.hItem), &hRootKey); > _sntprintf(szBuffer, sizeof(szBuffer) / sizeof(szBuffer[0]), _T("%s\\%s"), keyPath, ptvdi->item.pszText); > - keyPath = GetItemPath(pChildWnd->hTreeWnd, ptvdi->item.hItem, &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, ptvdi->item.hItem, &hRootKey); > if (RegOpenKeyEx(hRootKey, szBuffer, 0, KEY_READ, &hKey) == ERROR_SUCCESS) > { > lResult = FALSE; > RegCloseKey(hKey); > - (void)TreeView_EditLabel(pChildWnd->hTreeWnd, ptvdi->item.hItem); > + (void)TreeView_EditLabel(g_pChildWnd->hTreeWnd, ptvdi->item.hItem); > } > else > { > @@ -594,15 +592,15 @@ > } > else > { > - if ((int)wParam == LIST_WINDOW) > + if ((int)wParam == LIST_WINDOW && g_pChildWnd != NULL) > { > switch (((LPNMHDR)lParam)->code) > { > case NM_SETFOCUS: > - pChildWnd->nFocusPanel = 1; > + g_pChildWnd->nFocusPanel = 1; > break; > default: > - if(!ListWndNotifyProc(pChildWnd->hListWnd, wParam, lParam, &Result)) > + if(!ListWndNotifyProc(g_pChildWnd->hListWnd, wParam, lParam, &Result)) > { > goto def; > } > @@ -616,27 +614,27 @@ > case WM_CONTEXTMENU: > { > POINT pt; > - if((HWND)wParam == pChildWnd->hListWnd) > + if((HWND)wParam == g_pChildWnd->hListWnd) > { > int i, cnt; > BOOL IsDefault; > pt.x = (short) LOWORD(lParam); > pt.y = (short) HIWORD(lParam); > - cnt = ListView_GetSelectedCount(pChildWnd->hListWnd); > - i = ListView_GetNextItem(pChildWnd->hListWnd, -1, LVNI_FOCUSED | LVNI_SELECTED); > + cnt = ListView_GetSelectedCount(g_pChildWnd->hListWnd); > + i = ListView_GetNextItem(g_pChildWnd->hListWnd, -1, LVNI_FOCUSED | LVNI_SELECTED); > if (pt.x == -1 && pt.y == -1) > { > RECT rc; > if (i != -1) > { > rc.left = LVIR_BOUNDS; > - SendMessage(pChildWnd->hListWnd, LVM_GETITEMRECT, i, (LPARAM) &rc); > + SendMessage(g_pChildWnd->hListWnd, LVM_GETITEMRECT, i, (LPARAM) &rc); > pt.x = rc.left + 8; > pt.y = rc.top + 8; > } > else > pt.x = pt.y = 0; > - ClientToScreen(pChildWnd->hListWnd, &pt); > + ClientToScreen(g_pChildWnd->hListWnd, &pt); > } > if(i == -1) > { > @@ -646,7 +644,7 @@ > { > HMENU mnu = GetSubMenu(hPopupMenus, PM_MODIFYVALUE); > SetMenuDefaultItem(mnu, ID_EDIT_MODIFY, MF_BYCOMMAND); > - IsDefault = IsDefaultValue(pChildWnd->hListWnd, i); > + IsDefault = IsDefaultValue(g_pChildWnd->hListWnd, i); > if(cnt == 1) > EnableMenuItem(mnu, ID_EDIT_RENAME, MF_BYCOMMAND | (IsDefault ? MF_DISABLED | MF_GRAYED : MF_ENABLED)); > else > @@ -657,7 +655,7 @@ > TrackPopupMenu(mnu, TPM_RIGHTBUTTON, pt.x, pt.y, 0, hFrameWnd, NULL); > } > } > - else if ((HWND)wParam == pChildWnd->hTreeWnd) > + else if ((HWND)wParam == g_pChildWnd->hTreeWnd) > { > TVHITTESTINFO hti; > HMENU hContextMenu; > @@ -677,13 +675,13 @@ > if (pt.x == -1 && pt.y == -1) > { > RECT rc; > - hti.hItem = TreeView_GetSelection(pChildWnd->hTreeWnd); > + hti.hItem = TreeView_GetSelection(g_pChildWnd->hTreeWnd); > if (hti.hItem != NULL) > { > - TreeView_GetItemRect(pChildWnd->hTreeWnd, hti.hItem, &rc, TRUE); > + TreeView_GetItemRect(g_pChildWnd->hTreeWnd, hti.hItem, &rc, TRUE); > pt.x = rc.left + 8; > pt.y = rc.top + 8; > - ClientToScreen(pChildWnd->hTreeWnd, &pt); > + ClientToScreen(g_pChildWnd->hTreeWnd, &pt); > hti.flags = TVHT_ONITEM; > } > else > @@ -693,19 +691,19 @@ > { > hti.pt.x = pt.x; > hti.pt.y = pt.y; > - ScreenToClient(pChildWnd->hTreeWnd, &hti.pt); > - (void)TreeView_HitTest(pChildWnd->hTreeWnd, &hti); > + ScreenToClient(g_pChildWnd->hTreeWnd, &hti.pt); > + (void)TreeView_HitTest(g_pChildWnd->hTreeWnd, &hti); > } > > if (hti.flags & TVHT_ONITEM) > { > hContextMenu = GetSubMenu(hPopupMenus, PM_TREECONTEXT); > - (void)TreeView_SelectItem(pChildWnd->hTreeWnd, hti.hItem); > + (void)TreeView_SelectItem(g_pChildWnd->hTreeWnd, hti.hItem); > > memset(&item, 0, sizeof(item)); > item.mask = TVIF_STATE | TVIF_CHILDREN; > item.hItem = hti.hItem; > - (void)TreeView_GetItem(pChildWnd->hTreeWnd, &item); > + (void)TreeView_GetItem(g_pChildWnd->hTreeWnd, &item); > > /* Set the Expand/Collapse menu item appropriately */ > LoadString(hInst, (item.state & TVIS_EXPANDED) ? IDS_COLLAPSE : IDS_EXPAND, buffer, sizeof(buffer) / sizeof(buffer[0])); > @@ -734,7 +732,7 @@ > } > > /* Come up with suggestions */ > - keyPath = GetItemPath(pChildWnd->hTreeWnd, NULL, &hRootKey); > + keyPath = GetItemPath(g_pChildWnd->hTreeWnd, NULL, &hRootKey); > SuggestKeys(hRootKey, keyPath, Suggestions, sizeof(Suggestions) / sizeof(Suggestions[0])); > if (Suggestions[0]) > { > @@ -758,16 +756,16 @@ > s += _tcslen(s) + 1; > } > } > - TrackPopupMenu(hContextMenu, TPM_RIGHTBUTTON, pt.x, pt.y, 0, pChildWnd->hWnd, NULL); > + TrackPopupMenu(hContextMenu, TPM_RIGHTBUTTON, pt.x, pt.y, 0, g_pChildWnd->hWnd, NULL); > } > } > break; > } > > case WM_SIZE: > - if (wParam != SIZE_MINIMIZED && pChildWnd != NULL) > - { > - ResizeWnd(pChildWnd, LOWORD(lParam), HIWORD(lParam)); > + if (wParam != SIZE_MINIMIZED && g_pChildWnd != NULL) > + { > + ResizeWnd(LOWORD(lParam), HIWORD(lParam)); > } > /* fall through */ > default: > > Modified: trunk/reactos/dll/cpl/input/settings.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/cpl/input/settings.c?r… > ============================================================================== > --- trunk/reactos/dll/cpl/input/settings.c [iso-8859-1] (original) > +++ trunk/reactos/dll/cpl/input/settings.c [iso-8859-1] Mon Mar 21 14:07:29 2011 > @@ -14,7 +14,6 @@ > #include "input.h" > > static HWND MainDlgWnd; > -static HIMAGELIST hImgList; > // for SaveInputLang() > static INT OldLayoutNum; > > @@ -299,7 +298,7 @@ > } > > static VOID > -InitLangList(HWND hWnd) > +InitLangList(HWND hWnd, HIMAGELIST hImgList) > { > HKEY hKey, hSubKey; > TCHAR szBuf[MAX_PATH], szPreload[CCH_LAYOUT_ID + 1], szSub[CCH_LAYOUT_ID + 1]; > @@ -370,11 +369,19 @@ > VOID > UpdateLayoutsList(VOID) > { > - (VOID) ImageList_Destroy(hImgList); > + HIMAGELIST hImgList; > + > + /* Clear the list */ > (VOID) ListView_DeleteAllItems(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST)); > + > + /* Crate new list */ > hImgList = ImageList_Create(16, 16, ILC_COLOR8 | ILC_MASK, 0, 1); > - InitLangList(MainDlgWnd); > - (VOID) ListView_SetImageList(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), hImgList, LVSIL_SMALL); > + InitLangList(MainDlgWnd, hImgList); > + hImgList = ListView_SetImageList(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), hImgList, LVSIL_SMALL); > + > + /* Destroy old image list */ > + if(hImgList) > + (VOID) ImageList_Destroy(hImgList); > } > > typedef struct _REG_KB_ENTRY_ > @@ -728,12 +735,14 @@ > { > case WM_INITDIALOG: > { > + HIMAGELIST hImgList; > + > MainDlgWnd = hwndDlg; > AddListColumn(hwndDlg); > (VOID) ListView_SetExtendedListViewStyle(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), > LVS_EX_FULLROWSELECT); > hImgList = ImageList_Create(16, 16, ILC_COLOR8 | ILC_MASK, 0, 1); > - InitLangList(hwndDlg); > + InitLangList(hwndDlg, hImgList); > (VOID) ListView_SetImageList(GetDlgItem(MainDlgWnd, IDC_KEYLAYOUT_LIST), hImgList, LVSIL_SMALL); > } > break; > @@ -781,7 +790,6 @@ > } > break; > case WM_DESTROY: > - (VOID) ImageList_Destroy(hImgList); > break; > } > > >

1 0

Theming
by Andrew Green 21 Mar '11

21 Mar '11

I have been doing some investigation on theming. I have been looking into comctl32. One of the issues is that windows version 5 of the control has not theming and uses SxS so that applications that use version 6 will get themed controls. Currently comctl only has one version and applies theming regardless of the version the application requests. I have spoken on the Wine mailing list and the only person that replied did not want to use SxS. I assume to make it easier to maintain(though i don't understand why common parts cant share the same files and build 2 dlls). I was wondering what React OS developers think is the best choice. The second issue is that if comctl32 version 6 is loaded in windows it takes control of components that are usually in user32. Someone said this was called ( window class redirection). I can't really find any information on it. Though isn't this just registering the class except from comctl32? or does this cause a race condition(with the last one one loaded taking control)? is this is how "window class redirection" is different? Also the last thing is. Should sub classing be used? You should be able to load another window proc method even from user32 and call it when it is suitable from new control. I would imagine this could cause issues when the default procedure can't handle something as the new control would. Any advise would be much appreciated.

1 0

Uninitialized static variable in function
by Alexander Potashev 20 Mar '11

20 Mar '11

Hi, In the commit r51083 (http://git.reactos.org/?p=reactos.git;a=commitdiff;h=83ba2eecbf0ff43ec3a178…), please, initialize "i" to 0. Non-initialized variable store garbage, not zeroes. -- Alexander Potashev

5 8

[ros-diffs] [gadamopoulos] 51086: [win32k] - SetThreadDesktop: Actually set hdesk in PTHREADINFO Now GetThreadDesktop doesn't return 0
by James Tabor 20 Mar '11

20 Mar '11

This breaks the class test, so our message subsystem is broken and even abiword is effected by it.

1 2

New builder available
by Olaf Siejka 19 Mar '11

19 Mar '11

Dear colleagues I am very pleased to inform you that a new builder has been just made operational. Named Patch_x86_GCCWin Debug, you can see it waterfall right now. Based on x86 RBuild trunk, its capable of downloading a patch from bugzilla, applying it to trunk, building reactos testcd and running winetests on it via VBox sysreg. To use it, just pass revision, as well as Parameter 1, name id, value: attachement id. For example, http://www.reactos.org/bugzilla/attachment.cgi?id=5989 name: id, value: 5989 Just the same way you use source for vbox retesting. Right now test ISOs are stored, named with x86_Patch, revision and patch id. Logs itself will be also stored (when i bugfix them) If any issues arise, please mail me or catch me on irc.

8 9

Fwd: [hm] Open Source Hardware Convention 2011 en Madrid
by Javier Agustìn Fernàndez Arroyo 18 Mar '11

18 Mar '11

Hi all, let me forward this email that i have received i dunno if this is useful for you, as its a *hardware *meeting, but anyway.... have a look and let me know! P.S.: email is in english language at the bottom ---------- Forwarded message ---------- From: Syvic <syvic(a)sindormir.net> Date: 2011/3/18 Subject: [hm] Open Source Hardware Convention 2011 en Madrid To: Hackmeeting <hackmeeting(a)listas.sindominio.net> Buenas, (Perdón si os llega por duplicado) Hoy, tras unos cuantos meses de curro, lanzamos al mundo las OSHWCon 2011: (Catalán e inglés más abajo) La OSHWCon <http://oshwcon.org/es> es un encuentro anual de 3 días que organiza el colectivo Synusia <http://synusia.es/> en un esfuerzo de difundir el uso delHardware Libre<http://es.wikipedia.org/wiki/Hardware_libre> y de promocionar la electrónica y la filosofía del «Hazlo tú mismo<http://es.wikipedia.org/wiki/Diy>». Tendrá lugar en el Centro de Formación Padre Piquer<http://www.padrepiquer.com/> de Madrid los *días 23, 24 y 25 de Septiembre de 2011*. Durante la OSHWCon se ofrecerán *charlas*, *talleres*, *mesas redondas*, exposición de *proyectos personales* y sobre todo, un *lugar de encuentro para profesionales y aficionados al mundo de la electrónica*. La *asistencia * es *libre y gratuita* y está pensada para que nadie se quede fuera. Se programarán desde actividades de iniciación, hasta charlas y talleres de alto nivel técnico. Estamos trabajando para que durante la OSHWCon todo el mundo disfrute aprendiendo, intercambiando conocimientos, concursando e incluso jugando con la electrónica o la robótica, siempre desde la filosofía del *Open Source Hardware*. Contamos con *cuatro espacios* para celebrar varias *actividades simultáneas*, de forma que siempre habrá algo que hacer. Si tienes algo que aportar, quieres compartir tu última creación electrónica, eres experto en cierta materia electrónica y deseas explicarlo al mundo, háznoslo saber en el apartado «Propón tu charla<http://jhl.synusia.es/propuesta_charla>». Mira antes el «Call4Papers <http://jhl.synusia.es/call4papers>» para obtener más información acerca de las actividades en las que estamos interesados. Si quieres saber más acerca de qué nos motiva a realizar este encuentro, consulta la página «Manifiesto <http://jhl.synusia.es/manifiesto>». Estáis todos invitados a participar, ya sea como visitantes o como ponentes durante la Con. *¡Te esperamos el fin de semana del 23 al 25 de Septiembre!* Recuerda inscribirte <http://jhl.synusia.es/inscripcion> en la web si tienes pensado asistir. Además, una vez finalizada la OSHWCon, pondremos a disposición de todo el mundo las grabaciones de todas las actividades. Sobre Synusia Synusia <http://synusia.es/> es el grupo de trabajo de electrónica establecido en el C.F. Padre Piquer <http://www.padrepiquer.com/> que organiza esta Con. Synusia nació de la necesidad de crear un punto de encuentro donde compartir libremente y profundizar en el conocimiento de diferentes tecnologías electrónicas y el OSHW. Si estás interesado en participar en la OSHWCon o en saber más acerca de Synusia, no dudes en mandarnos un correo (Encontrarás más información en nuestra página web<http://synusia.es/>). Cualquier sugerencia será bienvenida. CATALÀ La Convenció de Hardware Lliure, Electrònica i Robòtica<http://oshwcon.org/ca> és una trobada anual de 3 dies que organitza el col.lectiu Synusia en un esforç per difondre l'ús del Maquinari Lliure i de promocionar l'electrònica i la filosofia de “Fes-ho tu mateix<http://ca.wikipedia.org/wiki/Do_It_Yourself>” Tindrà lloc en el Centre de Formació Padre Piquer<http://www.padrepiquer.com/> de Madrid els dies *23, 24 i 25 de setembre del 2011*. Durant el OSHWCon s'oferiran *xerrades*, *tallers*, *taules rodones*, exposició de *projectes personals* i, sobretot, un lloc de trobada pels professionals i aficionats al món de l'electrònica. *L'assistència és lliure i gratuïta* i està pensada perquè ningú es quedi fora. Es programaran des d'activitats d'iniciació fins a xerrades i tallers d' un alt nivell tècnic. Estem treballat per a que durant la convenció tothom disfruti aprenent, concursant i, fins i tot, jugant amb l'electrònica o la robòtica, sempre des de la filosofia de l' Open Source Hardware. Comptem amb *quatre espais* per celebrar diverses*activitats simultànies*, de manera que sempre hi haurà alguna cosa a fer. Si tens alguna cosa per aportar, vols compartir la teva darrera creació electrònica, ets expert en certa matèria electrònica i vols explicar-ho a tothom, fes-nos-ho saber en l'apartat “Proposa la teva xerrada<http://oshwcon.org/ca/proposa>”. Mira abans el “Call4Papers <http://oshwcon.org/ca/call4papers>” per obtenir més informació sobre les activitats que realitzem. Si vols saber més sobre què ens motiva a realitzar aquesta trobada, consulta la pàgina “Manifest<http://oshwcon.org/ca/manifest> ”. Esteu tots convidats a participar, ja sigui com a visitants o com a membres actius de el OSHWCon. *T'esperem el cap de setmana del 23 al 25 de setembre! * Recorda inscriure't a la web si tens pensat assistir-hi. A més, una vegada finalitzat la convenció, posarem a la disposició de tothom els enregistraments de les activitats. Sobre Synusia Synusia <http://synusia.es/> és el grup de treball d'electrònica establert en el C.F. Padre Piquer <http://www.padrepiquer.com/> que organitza aquesta convenció. Synusia va nèixer de la necessitat de crear un punt de trobada on es pogués compartir lliurement y profunditzar en el coneixement de diverses tecnologies electròniques i el OSHW. Si estàs interessat en participar en el OSHWCon o en saber més sobre Synusia, no dubtis en enviar-nos un correu (Trobaràs més informació a la nostra pàgina web <http://synusia.es/>). Qualsevol suggerència serà benvinguda. ENGLISH Open Source Hardware, Electronics and Robotics Convention<http://oshwcon.org/en> is a 3-days event organized by the Synusia group in an effort to spread the Open Source Software <http://en.wikipedia.org/wiki/Open-source_hardware> and to promote Electronics and the philosophy of "do it yourself<http://en.wikipedia.org/wiki/DIY>". The event will take place in Madrid, in C. F. Padre Piquer<http://www.padrepiquer.com/>, from *23 to 25 September 2011*. During the OSHWCon, visitors will be able to watch and participate in *talks, workshops, round table discussions*,*personal projects exhibitions* and, above all, we'll offer a meeting place for professionals and amateurs of the world of electronics. *Attendance is free and open to everyone*. Activities are intended to be for everybody: from beginners to hi-level talks and workshops. Our objective is for everybody to enjoy learning, sharing knowledge, taking part or even playing with electronics and robotics throughout the OSHWCon... All of it from the Open Source Hardware philosophy. There are *four different rooms/halls* to hold several *simultaneous activities*, so there will always be something interesting to do. If you have something to contribute with, you want to share your latest electronic creation or you are an expert on some electronic matters and you want to explain it to the world, let us know in "Suggest your talk<http://oshwcon.org/en/suggestyourtalk>". Check out first "Call4Papers <http://oshwcon.org/en/call4papers>" for more information about the activities we are into. In case you wonder what make us organize this event, take a look at our "Manifesto<http://oshwcon.org/en/manifesto> ". You are all welcome to participate, either as a visitor or as an active member of the OSHWCon. *We'll be waiting for you on September 23 to 25!* Please, remember to register first on our site if you are intended to come. We'll also offer the recordings of every activity once the OSHWCon come to close. About Synusia Synusia <http://synusia.es/> is the working group established in C. F. Padre Piquer <http://www.padrepiquer.com/> that organizes this Convention. Synusia<http://synusia.es/> was born from the need of setting up a meeting point where sharing and deepen into the knowledge of different electronic technologies. If you are willing to participate in the OSHWCon or you want to know more about Synusia, feel free to send us an email (you'll find out more in our web site<http://synusia.es/>). Any suggestions will be welcome! _______________________________________________ HackMeeting mailing list HackMeeting(a)listas.sindominio.net https://listas.sindominio.net/mailman/listinfo/hackmeeting

2 2

Choice of google summer of code project
by Andrew Green 18 Mar '11

18 Mar '11

I have been investigating a lot of aspects about theming, and my make that my proposal. Though I have been thinking that will not be of much valuable in the short term or in learning ongoing skills that will be needed in reactos. Of course on of the stated goals of gsoc or to give programmers the skills to contribute in the long term. So I was wondering what were your ideas on what would be considered valuable short term and what would give the skills to to help reactos in the long term. I know it is still 18 hours until google summer of code organizations are announced, but I'm sure reactos will be accepted. Any thoughts or suggestions would be much appreciated.

1 0

After the release
by Olaf Siejka 15 Mar '11

15 Mar '11

Hiya I would like to point out to actions in my opinion necessary to be done after the release: 1. Syncing: Starting a new development/release cycle is the best moment for winesync to be performed. Syncing early will give us much time to find and wipe all Wine-originated bugs, which are simply unavoidable. The Winesync itself should be spreaded to as many revisions as its possible/feasible, as it will help out testers to regress-test any issues more precisely. Before Winesync can be performed, CMake branch should be synchronized with current trunk and the revision synchronized - locked up as reference frame for any Trunk-CMake comparison tests. We would not want CMake effort to be delayed due to any issues with WINE code in trunk. 2. Patches Now guys, i know i`m repeating myself, but please be warned that i will not drop this issue. The way our project is handling patches from outside is absolutely counterproductive. This is the only way new devs can be recruited and get commit access, but delays in reviewing and even reacting to patches is disgraceful. We are driving away potential newcomers, something no one should wonder about, if it often takes months for someone to write down a simple question about the patch content... We are risking a potential project dawnfall if we continue doing this way. I know you are busy with real life, project and other stuff, but seriously, this approach will only make things even more difficult. I did all things i could think of to help you out. Patches are now clearly tagged, listed in accessible way ( http://www.reactos.org/wiki/Bug_Filters ), i even tried to filter them, moving old and questionable stuff into separate directory (WIP aka Work in progress). Right now i took the more direct step of assigning patches to devs personally. It might be questionable, please react in such cases and comment, i will gladly relocate, but please do react. Due to Daniel recent issues and lack of free time, i volunteered for commit translation patches, at least those that can be done easily. Next thing planned here, is a builder dedicated to patch testing, but this is just a rough plan for futher discussion. I would be grateful for ANY feedback from you, perhaps some things could be done better/differently. Thanks in advance for your comments

2 1

Last 0.3.13 tests
by Colin Finck 14 Mar '11

14 Mar '11

Hi all, The branch with all planned changes for 0.3.13 has been finished now and I've uploaded a first build: http://svn.reactos.org/prereleases/ReactOS-0.3.13-prerelease-r51045-bootcd.… It's now time to test this build out and update http://reactos.org/wiki/Tests_for_0.3.13 accordingly. mIRC has already been discovered as a prominent failing application, which just crashes upon connecting (see http://www.reactos.org/bugzilla/show_bug.cgi?id=6005). I consider this a release blocker bug, so some networking guy should look at it. - Colin

3 3

[ros-diffs] [gadamopoulos] 51031: [win32] - Rafal Harabien:
by James Tabor 13 Mar '11

13 Mar '11

Hi all! Since everyone works so fast to ride my ass for breaking things, I hope one of you have a fix for this one and also hope this did not make it into branch! The commit breaks things, I wanted Michael to review the patch before hand. I'm sure any of the IRC archives can find my comments. Going on Holiday, James

1 0

Re: [ros-dev] [ros-diffs] [fireball] 51013: [NOTEPAD] - Edijs: Zero initialize the caption string. See issue #5992 for more details.
by Aleksey Bragin 10 Mar '11

10 Mar '11

I made a mistake, this patch was written by Rafal Harabien. WBR, Aleksey Bragin. On Mar 11, 2011, at 1:07 AM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Mar 10 22:07:56 2011 > New Revision: 51013 > > URL: http://svn.reactos.org/svn/reactos?rev=51013&view=rev > Log: > [NOTEPAD] > - Edijs: Zero initialize the caption string. > See issue #5992 for more details. > > Modified: > trunk/reactos/base/applications/notepad/dialog.c

1 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 51011: FatCreateCcb has no params. Fixes building on msvc
by Gabriel ilardi 10 Mar '11

10 Mar '11

omg, glad to see you committing :-) > Date: Thu, 10 Mar 2011 15:37:51 +0000 > To: ros-diffs(a)reactos.org > From: gedmurphy(a)svn.reactos.org > Subject: [ros-diffs] [gedmurphy] 51011: FatCreateCcb has no params. Fixes building on msvc > > Author: gedmurphy > Date: Thu Mar 10 15:37:51 2011 > New Revision: 51011 > > URL: http://svn.reactos.org/svn/reactos?rev=51011&view=rev > Log: > FatCreateCcb has no params. > Fixes building on msvc > > Modified: > trunk/reactos/drivers/filesystems/fastfat_new/dir.c > > Modified: trunk/reactos/drivers/filesystems/fastfat_new/dir.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat_new/dir.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat_new/dir.c [iso-8859-1] Thu Mar 10 15:37:51 2011 > @@ -248,7 +248,7 @@ > } > > /* Set the file object */ > - Ccb = FatCreateCcb(IrpContext); > + Ccb = FatCreateCcb(); > FatSetFileObject(FileObject, > UserDirectoryOpen, > Dcb, > >

1 0

Re: [ros-dev] [ros-diffs] [fireball] 50981: [NTOS/FSRTL] - Implement parameters checking i
by Pierre Schweitzer 08 Mar '11

08 Mar '11

Hi, this commits just shows you didn't understand how that function works. If you had, you wouldn't have said: "- Implement parameters checking in FsRtlIsNameInExpressionPrivate." It's already done. "- Add two shortcuts for common wildcard invocations to make the function faster." If you look at the algorithm, it will take at maximum as much loop iterations as name length. "- Second (main part of the function) is still under review." Thanks for discussing the issue with the original author of the algorithm, especially since you don't understand it. Furthermore, if you're not happy with said algorithm, you were asked to review it more than a year ago, and for at least 6 months. Thing that you NEVER did. So, now you discovered what my mail address is, contact me before committing anything wrong/useless to current code. And as you said less than a week ago, focus on fixing things that don't work, instead of rewriting working code. And as someone else also said once: 1:1 isn't the solution everywhere. Or if you think so, start dropping arwinss. Of course, don't take that personal, I like everyone ;-). Regards, P. Schweitzer

6 10

Re: [ros-dev] [ros-diffs] [jimtabor] 50933: [Win32k|User32] - Clarify the meaning and the
by Johannes Anderwald 07 Mar '11

07 Mar '11

> Author: jimtabor > Date: Mon Feb 28 06:31:44 2011 > New Revision: 50933 > > URL: http://svn.reactos.org/svn/reactos?rev=50933&view=rev > Log: > [Win32k|User32] > - Clarify the meaning and the use of 0, 1 and 2 for user window regions, wine never did. Noticing patches not corresponding in correctness and understanding, leaving potential crashes in the DCE code, which depend on these types. > - Patch based on Rafal Harabien patch, fixes wine msg SetWindowRgn test, see also bug 5959. This change breaks Winamp 5.601: (ntoskrnl/ps/thread.c:119) PS: Unhandled Kernel Mode Exception Pointers = 0xF86A8568 (ntoskrnl/ps/thread.c:126) Code c0000005 Addr F87D4C3E Info0 00000000 Info1 00000020 Info2 00000000 Info3 00000020 *** Fatal System Error: 0x0000007e (0xC0000005,0xF87D4C3E,0xF86A8A50,0xF86A8690) [7hEntered debugger on embedded INT3 at 0x0008:0x808fd45c.bt Eip: <ntoskrnl.exe:fd45d (lib/rtl/i386/debug_asm.S:39 (RtlpBreakWithStatusInstruction))> Frames: <ntoskrnl.exe:a902 (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))> <ntoskrnl.exe:aa4d (ntoskrnl/ke/bug.c:1438 (KeBugCheckEx@20))> <ntoskrnl.exe:ead94 (ntoskrnl/ps/thread.c:129 (PspUnhandledExceptionInSystemThread))> <ntoskrnl.exe:eadaf (ntoskrnl/ps/thread.c:159 (_SEHExcept.39966))> <ntoskrnl.exe:fa9fa (lib/pseh/i386/framebased-gcchack.c:132 (_SEH2FrameHandler))> <ntoskrnl.exe:fcecb (lib/rtl/i386/except_asm.s:183 (RtlpExecuteHandler2))> <ntoskrnl.exe:fce9f (lib/rtl/i386/except_asm.s:150 (RtlpExecuteHandlerForUnwind))> <ntoskrnl.exe:3222 (ntoskrnl/ke/i386/exp.c:938 (KiDispatchException@20))> <ntoskrnl.exe:36bd (ntoskrnl/ke/i386/exp.c:1137 (KiDispatchExceptionFromTrapFrame@28))> <ntoskrnl.exe:6941 (ntoskrnl/include/internal/arch/../i386/ke.h:597 (@KiTrap0EHandler@4))> <ntoskrnl.exe:f7408 (ntoskrnl/ke/i386/trap.s:99 (VfIsVerificationEnabled@8))> <win32k.sys:bac39 (subsystems/win32/win32k/objects/region.c:2104 (@RGNOBJAPI_Lock@8))> <win32k.sys:bb0b3 (subsystems/win32/win32k/objects/region.c:3753 (NtGdiPtInRegion@12))> <win32k.sys:71bbb (subsystems/win32/win32k/ntuser/msgqueue.c:248 (@co_MsqInsertMouseMessage@4))> <win32k.sys:5ded4 (subsystems/win32/win32k/ntuser/cursoricon.c:205 (UserSetCursorPos))> <win32k.sys:66630 (subsystems/win32/win32k/ntuser/input.c:1134 (@IntMouseInput@4))> <win32k.sys:66cca (subsystems/win32/win32k/ntuser/input.c:194 (@ProcessMouseInputData@8))> <win32k.sys:66fbf (subsystems/win32/win32k/ntuser/input.c:308 (MouseThreadMain@4))> <ntoskrnl.exe:eac86 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <ntoskrnl.exe:5936 (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <ntoskrnl.exe:eac22 (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> WBR, Johannes

2 9

Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox "feature" : claim that SY...
by Aleksey Bragin 07 Mar '11

07 Mar '11

On Mar 7, 2011, at 4:33 PM, jgardou(a)svn.reactos.org wrote: > Author: jgardou > /* Check if the CPU is too old to support SYSENTER */ > - if ((Prcb->CpuType < 6) || > - ((Prcb->CpuType == 6) && (Prcb->CpuStep < 0x0303))) > + if ((Reg[0] & 0x0FFF3FFF) < 0x00000633) > { It was intentionally done over CpuType and CpuStep. Now you criptified it back to a raw Reg[0] value and weird hardcoded constant. Could you please 1) elaborate this change and 2) if you still think it's correct, and if you still tihnk(!) Windows does it same way, then rework it to use Prcb->Cpu* instead of these magic values? Not to say adding a hack for VirtualBox is far from being a beautiful, and would need to be *at least* marked so that it's not forgotten. Thanks, Aleksey Bragin.

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 50991: [NTOSKRNL] - Print supported CPU features. - Simplify detection of non working but claimed SYSENTER support for intel processors - Workaround a virtualbox "feature" : claim that SY...
by Timo Kreuzer 07 Mar '11

07 Mar '11

Am 07.03.2011 14:33, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Mar 7 13:33:10 2011 > New Revision: 50991 > ... > + Reg[3] |= 0x800; > ... > + if ((Reg[0]& 0x0FFF3FFF)< 0x00000633) I'd prefer symbolic constants over these magic numbers. > + > + DPRINT1("Supported CPU features :\n"); > +#define print_supported(kf_value) \ > + if(FeatureBits& kf_value) DPRINT1("\t" #kf_value "\n") > + print_supported(KF_V86_VIS); > + print_supported(KF_RDTSC); > + print_supported(KF_CR4); > + print_supported(KF_CMOV); > + print_supported(KF_GLOBAL_PAGE); > + print_supported(KF_LARGE_PAGE); > + print_supported(KF_MTRR); > + print_supported(KF_CMPXCHG8B); > + print_supported(KF_MMX); > + print_supported(KF_WORKING_PTE); > + print_supported(KF_PAT); > + print_supported(KF_FXSR); > + print_supported(KF_FAST_SYSCALL); > + print_supported(KF_XMMI); > + print_supported(KF_3DNOW); > + print_supported(KF_AMDK6MTRR); > + print_supported(KF_XMMI64); > + print_supported(KF_DTS); > + print_supported(KF_NX_BIT); > + print_supported(KF_NX_DISABLED); > + print_supported(KF_NX_ENABLED); > +#undef print_supported Can we make this more compact please? Like "Supported CPU features: V86_VIS, RDTSC ..." Thanks, Timo

3 2

[ros-diffs] [jimtabor] 50987: [GDI32] - Remove the old SetDIBBits, it severed us well....
by James Tabor 07 Mar '11

07 Mar '11

[GDI32] - Remove the old SetDIBBits, it severed us well.... Hold on to the win32k call. - Tested, Area.exe, wine gdi32 bitmaps test, AbiWord 2.8.6, OOo 2.4.3, SM 2.0.11 and ReactOS applications. - Aimp 2.61.583 (FULL, painted okay), CoolPlayer 219, winamp 0.98d and winamp 2.95 (not FUll). The rest have drawing issue with DIB. See bug 5886. The sound applications have the same issue with revision 50933+ (region unassociated with the DC owner), except CoolPlayer and winamp 0.98d. There is also an issue with vbrun60spX too. I'm not sure how to move on and start compressed bitmaps. Thanks, James

1 0

Re: [ros-dev] [ros-diffs] [fireball] 50967: - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtrace...
by Timo Kreuzer 06 Mar '11

06 Mar '11

Hmm... I remember I added it to enable the possibility for backtraces in 1st stage for sysreg. Why does it now cause the opposite? And why is there an inconsistency? In 2nd stage there is an option for debug mode, in 1st stage there is none, so using kdserial (which imo is appropriate way to do it, I always select it) as default is as consistent as using "normal" debug, getting the input from the keyboard driver. Just my 0,002 ct/kb Timo Am 04.03.2011 17:57, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Fri Mar 4 16:57:56 2011 > New Revision: 50967 > > URL: http://svn.reactos.org/svn/reactos?rev=50967&view=rev > Log: > - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtraces. > See issue #5811 for more details. > > Modified: > trunk/reactos/boot/bootdata/txtsetup.sif > > Modified: trunk/reactos/boot/bootdata/txtsetup.sif > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/txtsetup.sif… > ============================================================================== > --- trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] Fri Mar 4 16:57:56 2011 > @@ -59,7 +59,7 @@ > [SetupData] > DefaultPath = \ReactOS > OsLoadOptions = "/NOGUIBOOT /NODEBUG" > -DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE /KDSERIAL" > +DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE" > ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=SCREEN" > ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=BOCHS" > > > >

3 5

DHCP not working?
by Javier Agustìn Fernàndez Arroyo 04 Mar '11

04 Mar '11

Hi all, im testing ROS right now in real hardware... As i cannot log into IRC (via webchat.freenode.net, i cant even reach the page, i dont know why), let me post this in ML The think is, i have installed RealTek´s official driver for the NIC, and hardware is recognized... but, dhcp dont get any IP... any idea? log is attached btw, in the log there are many errors ("xxxx failed") about ndis.......

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 50942: [WIN32K] Do raster operation on 4 bytes instead of only 3. Fixes ... maybe noone has noticed yet ; -)
by Colin Finck 01 Mar '11

01 Mar '11

tkreuzer(a)svn.reactos.org wrote: > Do raster operation on 4 bytes instead of only 3. Quoting jgardou's commit before: > - When applying raster operation, do so only on 24 bits, we don't > support alpha channel in win32k I have no idea about DIB code, but just from the commit message I presume that this change to 24 bits has happened deliberately. - Colin

3 2

Heap corruption detector is ready
by Aleksey Bragin 25 Feb '11

25 Feb '11

Hi all, I finished implementing main features of a special mechanism for monitoring uesrmode heap allocations in ReactOS. This mechanism is called Debug Page Heap, after the very similar mechanism present in recent versions of Microsoft Windows NT. Explaining the heap manager, the "usual" heap allocator (the one I also developed earlier) also contains a heap corruption detector, but it works post-factum, only after the respective block is freed its patterns are checked (if such heap flags are specified) and if they are damaged the block is reported. This makes debugging problematic, because a lot of code is executed between the moment the corruption occured and moment when the corrupted block is freed. Also it may be so that block's patterns are untouched, but internal heap structures are damaged. The usual heap allocator won't be able to catch this, but will crash with undetermined exception. Debug page heap (DPH) comes to solve this problem. Simply speaking it guards every block with a no-access page either after or before the block, so that when a badly written app wants to write beyond the allowed area, an exception occurs showing exactly the faulty instruction. Not so simply speaking, it's a rather complicated debugging tool with abilities to catch access-after-free cases also when they happen, and do some other nice tricks too. If you want to read more about it, look for "debug page heap" in MSDN and also visit URLs specified as references in rtl/heappage.c. How to use it? The best way is to use Microsoft's utility gflags.exe which is part of the Debugging package of WDK. To make long things short, just copy gflags.exe to C:\ReactOS\system32, boot your ReactOS installation, fire up cmd prompt and type: gflags /p /enable name.exe /full Now, when you run your app called name.exe, it will use the DPH heap allocator. Detailed information about gflags.exe could be found here: http:// msdn.microsoft.com/en-us/library/ff549557%28VS.85%29.aspx Also, I suggest looking in MSDN for page heap explanation (I provided some references in heappage.c too). Have fun! Aleksey.

1 0

ReactOS Urgent Meeting
by Colin Finck 23 Feb '11

23 Feb '11

ReactOS Urgent Meeting Preamble ========= The following people which are generally considered as ReactOS-related people have called for an urgent project meeting. They agree with the meeting agenda and the rules for this meeting: * Giannis Adamopoulos * Johannes Anderwald * Maciej Białas * Aleksey Bragin * Colin Finck * Ziliang Guo * Kamil Hornicek * Amine Khaldi * Timo Kreuzer * Victor Martinez * Roel Messiant * Sylvain Petreolle * Pierre Schweitzer * Olaf Siejka * James Tabor * Art Yerkes As we have not established any general rules for meetings yet, we consider these demands enough to justify the need for such an urgent meeting. Based on the experiences Colin has from formal ReactOS Deutschland e.V. foundation meetings, we need at least a discussion leader and a minute taker to get an organized meeting done over IRC. General Information ==================== * Date and Time: Tuesday, 22nd February, 2011 - 20:00 UTC * Place: #reactos-meeting on Freenode * Meeting leader: Colin Finck * Minute taker: Amine Khaldi * Allowed Participants The following people are allowed to participate in the discussion on that channel. This list is taken from the people which were recently active on the #reactos-dev IRC channel. Others are not included as they don’t have a chance to know about the recent developments. If you consider yourself a ReactOS-related person, you may still ask Colin Finck to put you on this list. Apart from this, everybody may join as an observer. o Giannis Adamopoulos (smiley1_) o Johannes Anderwald (janderwald) o Maciej Białas (niski) o Aleksey Bragin (abragin) o Colin Finck (Colin_Finck) o Danny Götte (dangerground) o Ziliang Guo (ZWabbit) o Amine Khaldi (AmineKhaldi) o Timo Kreuzer (rosdude) o Matthias Kupfer (Collibri) o Victor Martinez (vicmarcal) o Roel Messiant (Mephisto) o Ged Murphy (GedMurphy) o Sylvain Petreolle (Usurp) o Daniel Reimer (dreimer) o Pierre Schweitzer (HeisSpiter) o Samuel Serapion (encoded) o Olaf Siejka (Caemyr) o James Tabor (jimtabor) o Art Yerkes (arty) Meeting Agenda =============== 1. Agree on a preliminary definition for the term "ReactOS Team Member". To create a basis for the next regular meeting, we need to know who may participate and who may not. As we need to focus on the release right now, this definition should only be preliminary and is subject to change in a future meeting. Some participants will present proposals for such a definition. 2. Establish regular meetings every month. This is the only chance to ensure discussions among a broad range of ReactOS Team members with binding decisions. These meetings should follow the rules of typical meetings, including meeting leaders and minute takers. In contrast to this meeting, all team members should be able to participate. Minutes should also be published on the website. Such regular meetings should begin after CLT2011 (after 20th March) due to the time it takes to prepare this event. 3. Set up binding 0.3.13 Release Plans. The CLT2011 event is a big PR chance for a new ReactOS release, so we should look forward to get a release ready by then. This point includes: 1. Getting information about the most annoying bugs and regressions. Victor Martinez and Olaf Siejka will report on this. 2. Building teams to care about each bug. As soon as a bug is fixed, a team has to report back about this to one of the release engineers. They will then add you to another team. Of course, you may also suggest stuff you want to work on afterwards. 3. Setting deadlines for the bugs. We need to determine what bugs can be realistically fixed in the given time. If a bug is not fixed by then, the appropriate team has to report back about this to one of the release engineers. They are then responsible for finding a solution. We believe that other topics, especially the ones discussed in the "ReactOS Reaction" document should be covered in the first regular meeting, so that we can focus on 0.3.13 right now.

2 4

Re: [ros-dev] [ros-diffs] [pschweitzer] 50867: [KERNEL32] Don't make GetBinaryTypeA() rely on Wine's strings conversions functions
by Aleksey Bragin 23 Feb '11

23 Feb '11

This commit sounds like FilenameA2W is some evil we should get rid of as soon as possible, otherwise it takes over the world. In fact, FilenameA2W is the same stuff which you just unwrapped, so instead of 1 line, there are 20 lines now. The only thing would be setting correct LastError, but for some reason I think Wine did it right too (they have tests). In my opinion, it makes sense to either rewrite the buggy code (buggy being really buggy or questionable origin, if code comes from Wine it doesn't automatically mean it's buggy), or let the shared code be shared and just update it from the latest Wine. WBR, Aleksey Bragin. On Feb 22, 2011, at 9:43 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Tue Feb 22 18:43:38 2011 > New Revision: 50867 > > URL: http://svn.reactos.org/svn/reactos?rev=50867&view=rev > Log: > [KERNEL32] > Don't make GetBinaryTypeA() rely on Wine's strings conversions > functions > > Modified: > trunk/reactos/dll/win32/kernel32/file/bintype.c > > Modified: trunk/reactos/dll/win32/kernel32/file/bintype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ > kernel32/file/bintype.c?rev=50867&r1=50866&r2=50867&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/win32/kernel32/file/bintype.c [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/kernel32/file/bintype.c [iso-8859-1] > Tue Feb 22 18:43:38 2011 > @@ -301,23 +301,43 @@ > */ > BOOL > WINAPI > -GetBinaryTypeA ( > - LPCSTR lpApplicationName, > - LPDWORD lpBinaryType > - ) > +GetBinaryTypeA(IN LPCSTR lpApplicationName, > + OUT LPDWORD lpBinaryType) > { > - PWCHAR ApplicationNameW; > - > - if(!lpApplicationName || !lpBinaryType) > - { > - SetLastError(ERROR_INVALID_PARAMETER); > - return FALSE; > - } > - > - if (!(ApplicationNameW = FilenameA2W(lpApplicationName, FALSE))) > - return FALSE; > - > - return GetBinaryTypeW(ApplicationNameW, lpBinaryType); > + ANSI_STRING ApplicationNameString; > + UNICODE_STRING ApplicationNameW; > + BOOL StringAllocated = FALSE, Result; > + NTSTATUS Status; > + > + RtlInitAnsiString(&ApplicationNameString, lpApplicationName); > + > + if (ApplicationNameString.Length * sizeof(WCHAR) >= > NtCurrentTeb()->StaticUnicodeString.MaximumLength) > + { > + StringAllocated = TRUE; > + Status = RtlAnsiStringToUnicodeString(&ApplicationNameW, > &ApplicationNameString, TRUE); > + } > + else > + { > + Status = RtlAnsiStringToUnicodeString(&(NtCurrentTeb()- > >StaticUnicodeString), &ApplicationNameString, FALSE); > + } > + > + if (!NT_SUCCESS(Status)) > + { > + BaseSetLastNTError(Status); > + return FALSE; > + } > + > + if (StringAllocated) > + { > + Result = GetBinaryTypeW(ApplicationNameW.Buffer, > lpBinaryType); > + RtlFreeUnicodeString(&ApplicationNameW); > + } > + else > + { > + Result = GetBinaryTypeW(NtCurrentTeb()- > >StaticUnicodeString.Buffer, lpBinaryType); > + } > + > + return Result; > } > > /* EOF */ > >

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 50854: [RTL] - Silence this dprint. It's flooding the
by Pierre Schweitzer 21 Feb '11

21 Feb '11

Hi, this debug wasn't supposed to be silent as it highlights a quite crappy situation in ReactOS. And that's even what one would call: "a hack". That way, you could also silence IopParseDevice hack debug... At least, you could have asked the author, I'm not that unreachable ;-). Regards, P. Schweitzer

4 4

CallOneParam? 0x10? sometimes 0x20
by James Tabor 21 Feb '11

21 Feb '11

I noticed this everywhere, (subsystems/win32/win32k/objects/gdiobj.c:249) GDIOBJ_LockObj: Attempted to lock object 0x10064, wrong reuse counter (Handle: 0x0, Entry: 0x8) (subsystems/win32/win32k/objects/dclife.c:726) Could not lock source DC 00010064 (subsystems/win32/win32k/ntuser/simplecall.c:349) Calling invalid routine number 0x10 in NtUserCallOneParam(), Param=0x31 CallOneParam? Looks like a stack issue.

2 2

Buidlbot (& trunk?) broken
by Pierre Schweitzer 21 Feb '11

21 Feb '11

Hi, it seems that recent changes lead buildbot to brokenness status. It's looping forever on a backtrace. Crash occurs in user32_winetest win. Before the end: win.c:1028: HCBT_DESTROYWND: hwnd 000A04E6 win.c:1058: previous shell window: 00020098 (subsystems/win32/win32k/ntuser/window.c:2500) Destroying the ShellWindow! (subsystems/win32/win32k/ntuser/message.c:1629) SendNotifyMessage: Failed in Broadcast! [7hEntered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x47534D59 could not be written: Page not present. kdb:> bt Eip: <win32k.sys:7125d (include/ddk/wdm.h:8188 (@MsqCleanupMessageQueue@4))> Frames: <win32k.sys:71438 (subsystems/win32/win32k/ntuser/msgqueue.c:1575 (@MsqDestroyMessageQueue@4))> <win32k.sys:400a2 (subsystems/win32/win32k/main/dllmain.c:346 (Win32kThreadCallback@8))> <ntoskrnl.exe:dfc5d (ntoskrnl/ps/kill.c:693 (PspExitThread@4))> <ntoskrnl.exe:e002c (ntoskrnl/ps/kill.c:890 (PsExitSpecialApc@20))> <ntoskrnl.exe:9004 (ntoskrnl/ke/apc.c:471 (KiDeliverApc@12))> <ntoskrnl.exe:70be (ntoskrnl/include/internal/arch/../i386/ke.h:690 (@KiServiceExit@8))> <win32k.sys:e6a73 (subsystems/win32/win32k/ntuser/menu.c:0 (@IntCreateMenu@8))> <ff8848b8> <b0465eb0> <win32k.sys:e6a73 (subsystems/win32/win32k/ntuser/menu.c:0 (@IntCreateMenu@8))> <win32k.sys:e7153 (/mnt/ramdisk/buildbot/debug/obj/include/psdk/oleidl.h:0 (_SEH2FrameHandler))> <b0467604> <b04675cc> <b04667cc> <b0466794> <b0290874> <b029083c> <b04504ac> <b0450474> <b0464634> Regards, P. Schweitzer

1 2

Releasing
by Aleksey Bragin 15 Feb '11

15 Feb '11

Hi, recently amount of new features added to the trunk decreased, and there were quite a lot of bugfixes coming in. In my opinion, it is a very good time for a release. After release is branched, it would be possible to sync wine shared code and continue with other changes. If there are no objections, let's start the work right away. Testers being the first team working, and Colin - when/if you have time for this release? WBR, Aleksey Bragin.

10 17

Re: [ros-dev] [ros-diffs] [pschweitzer] 50616: [RTL] Minor code changes to RTL (one would call them "optimisation"). Added some missing paged code. Plus added useful asserts (used to catch r50615 bug!)
by Timo Kreuzer 08 Feb '11

08 Feb '11

You wrote it was an optimization, but it rather looks like a functional change ("+ sizeof(WCHAR)"). is that intended? wdm:8428 #define RtlAnsiStringToUnicodeSize(String) ( \ NLS_MB_CODE_PAGE_TAG ? \ RtlxAnsiStringToUnicodeSize(String) : \ ((String)->Length + sizeof(ANSI_NULL)) * sizeof(WCHAR) \ ) wdm:8916 #define RtlUnicodeStringToAnsiSize(String) ( \ NLS_MB_CODE_PAGE_TAG ? \ RtlxUnicodeStringToAnsiSize(String) : \ ((String)->Length + sizeof(UNICODE_NULL)) / sizeof(WCHAR) \ ) Am 08.02.2011 00:23, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Mon Feb 7 23:23:33 2011 > New Revision: 50616 > > URL: http://svn.reactos.org/svn/reactos?rev=50616&view=rev > Log: > [RTL] > Minor code changes to RTL (one would call them "optimisation"). Added some missing paged code. > Plus added useful asserts (used to catch r50615 bug!) > ... > - Length = RtlAnsiStringToUnicodeSize(AnsiSource); > + if (NlsMbCodePageTag == FALSE) > + { > + Length = AnsiSource->Length * 2 + sizeof(WCHAR); > + } > + else > + { > + Length = RtlxAnsiStringToUnicodeSize(AnsiSource); > + } ... > > - Length = RtlUnicodeStringToAnsiSize(UniSource); > + ASSERT(!(UniSource->Length& 1)); > + > + if (NlsMbCodePageTag == FALSE) > + { > + Length = (UniSource->Length + sizeof(WCHAR)) / sizeof(WCHAR); > + } > + else > + { > + Length = RtlxUnicodeStringToAnsiSize(UniSource); > + } > if (Length> MAXUSHORT) return STATUS_INVALID_PARAMETER_2;

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 50612: [NTOSKRNL/PPC] Fix the fix, spotted by "ThFabba" on IRC
by Timo Kreuzer 07 Feb '11

07 Feb '11

Under "normal conditions" sizeof of an array covers the whole array. is this different for function paramters? Am 06.02.2011 14:50, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Sun Feb 6 13:50:57 2011 > New Revision: 50612 > > URL: http://svn.reactos.org/svn/reactos?rev=50612&view=rev > Log: > [NTOSKRNL/PPC] > Fix the fix, spotted by "ThFabba" on IRC > > Modified: > trunk/reactos/ntoskrnl/ke/powerpc/cpu.c > > Modified: trunk/reactos/ntoskrnl/ke/powerpc/cpu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/powerpc/cpu.c?… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/powerpc/cpu.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/powerpc/cpu.c [iso-8859-1] Sun Feb 6 13:50:57 2011 > @@ -44,7 +44,7 @@ > CPUID(IN ULONG CpuInfo[4], > IN ULONG InfoType) > { > - RtlZeroMemory(CpuInfo, sizeof(CpuInfo) * sizeof(ULONG)); > + RtlZeroMemory(CpuInfo, 4 * sizeof(ULONG)); > } > > VOID > > >

3 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 50605: [WIN32K] Fix a bug in calculation of the background color for 32bpp -> 1bpp color translations. Fixes bug 2372
by Gabriel ilardi 04 Feb '11

04 Feb '11

What about the patch in that bug http://www.reactos.org/bugzilla/attachment.cgi?id=1568 :) ? > Date: Fri, 4 Feb 2011 13:53:50 +0000 > To: ros-diffs(a)reactos.org > From: tkreuzer(a)svn.reactos.org > Subject: [ros-diffs] [tkreuzer] 50605: [WIN32K] Fix a bug in calculation of the background color for 32bpp -> 1bpp color translations. Fixes bug 2372 > > Author: tkreuzer > Date: Fri Feb 4 13:53:49 2011 > New Revision: 50605 > > URL: http://svn.reactos.org/svn/reactos?rev=50605&view=rev > Log: > [WIN32K] > Fix a bug in calculation of the background color for 32bpp -> 1bpp color translations. > Fixes bug 2372 > > Modified: > trunk/reactos/subsystems/win32/win32k/eng/xlate.c > > Modified: trunk/reactos/subsystems/win32/win32k/eng/xlate.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/en… > ============================================================================== > --- trunk/reactos/subsystems/win32/win32k/eng/xlate.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/win32k/eng/xlate.c [iso-8859-1] Fri Feb 4 13:53:49 2011 > @@ -91,7 +91,7 @@ > iColor >>= 13; > iNewColor |= iColor & 0x3E0; > > - /* Copy green */ > + /* Copy blue */ > iColor >>= 13; > iNewColor |= iColor & 0x1F; > > @@ -417,11 +417,11 @@ > pexlo->aulXlate[0] = > PALETTE_ulGetNearestPaletteIndex(ppalSrc, crSrcBackColor); > } > + else if (ppalSrc->flFlags & PAL_RGB) > + { > + pexlo->aulXlate[0] = crSrcBackColor; > + } > else if (ppalSrc->flFlags & PAL_BGR) > - { > - pexlo->aulXlate[0] = crSrcBackColor; > - } > - else if (ppalSrc->flFlags & PAL_RGB) > { > pexlo->aulXlate[0] = RGB(GetBValue(crSrcBackColor), > GetGValue(crSrcBackColor), > >

2 1

ReactOS Project at Chemnitzer Linux-Tage 2011
by Colin Finck 03 Feb '11

03 Feb '11

Hi all, Even if it has already been reported through the newsletter, here is the announcement for mailing list readers: The ReactOS Project will have a booth at the Chemnitzer Linux-Tage 2011, the second-largest Open-Source-related exhibition in Germany, from 19th to 20th March. Our project is going to be represented by the ReactOS developers Colin Finck, Timo Kreuzer, Matthias Kupfer, Daniel Reimer and Christoph von Wittich. This year, we will also be joined by Kai Tietz from the MinGW-w64 Project. Like in the last years, you will be able to try out the latest development state of ReactOS as well as getting some merchandising articles. So if you have the time to visit Chemnitz, stop by and say hello at our booth. Cheers, Colin

1 0

About debugging ROS
by Xu Liu 31 Jan '11

31 Jan '11

I am just a new person who wants to debug ROS, so my questions may be stupid. I have checked http://www.reactos.org/wiki/Debugging . It seems the main debugging way is "Debugging through text messages" (I think it is more like "checking logs"). If I want to use GDB, I have to use QEMU. Would you please tell me is Kdbg the only way to debug code in VMWare or VirtualBox? And if I want to debug ReactOS, do I have to install QEMU or VMWare or VirtualBox? Using "make install" in RosBE can generate many binary files. Is there any build-in way to start ROS from these bin files without any virtual machine? Thank you in advance.

3 4

BuildBot changes
by Colin Finck 24 Jan '11

24 Jan '11

Hello all, As you have certainly noticed, Amine, Olaf and me have upgraded the BuildBot some days ago. While doing this, we have added Olaf's build slaves which used to be available at http://reactos.ath.cx:8081. The new BuildBot version finally enables authenticated access for features like forcing a build. When you want to do this now, you have to enter your SVN credentials into the respective fields. If you are a tester and need these BuildBot features, please ask Aleksey or me for getting the appropriate credentials. In the next few days, we're probably going to make the testing results of his CMake bot available at http://reactos.org/testman and upload his builds to http://iso.reactos.org. I might also change the BuildBot Web page design. Now that the main part has got wider, we might remove the ReactOS design around it to get some space for the real important stuff. - Colin

4 4

Re: [ros-dev] [ros-diffs] [spetreolle] 50454: [CMAKE] Use cmake subversion capabilities to generate buildno.h and version.h.
by Colin Finck 21 Jan '11

21 Jan '11

spetreolle(a)svn.reactos.org wrote: > + subversion_wc_info(${CMAKE_CURRENT_SOURCE_DIR} SVNINFO) This will fail when we're not inside a working copy (see http://www.vtk.org/Bug/view.php?id=10200), because the macro outputs an error in this case. Please take a look into http://svn.reactos.org/svn/project-tools/trunk/rosev_ircsystem/src/CMakeLis… to see how you can easily reimplement this step properly. Apart from that, nice to see that we finally get rid of this old stuff! :-) - Colin

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 50443: [GDI32] Fix broken portable implementation of _lrintf, 2nd try :)
by Aleksey Bragin 19 Jan '11

19 Jan '11

I bet _lrintf just needed more underscores! ;) On Jan 19, 2011, at 9:10 PM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Wed Jan 19 18:10:50 2011 > New Revision: 50443 > > URL: http://svn.reactos.org/svn/reactos?rev=50443&view=rev > Log: > [GDI32] > Fix broken portable implementation of _lrintf, 2nd try :) > > Modified: > trunk/reactos/dll/win32/gdi32/include/gdi32p.h > > Modified: trunk/reactos/dll/win32/gdi32/include/gdi32p.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/ > gdi32/include/gdi32p.h?rev=50443&r1=50442&r2=50443&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/win32/gdi32/include/gdi32p.h [iso-8859-1] > (original) > +++ trunk/reactos/dll/win32/gdi32/include/gdi32p.h [iso-8859-1] Wed > Jan 19 18:10:50 2011 > @@ -413,7 +413,7 @@ > } > #else > /* slow, but portable */ > - return (int)(x >= 0 ? x+0.5 : x-0.5); > + return (int)(f >= 0 ? f+0.5 : f-0.5); > #endif > } > > >

1 0

Getting a Windows Server 2003 license for the project?
by Colin Finck 19 Jan '11

19 Jan '11

Hi everybody, I've been thinking about getting a license of an English Windows Server 2003 Standard 32-Bit for the project. It could be installed on one of our servers and be made available over RDP. This would enable project members to do development and testing work on our actual target platform. Considering that some developers even use a non-Windows platform for development work, it might simplify their work as well. We may as well use the license for other purposes (Buildslave, Testslave, whatever), but at least native building could be done by any Windows version. And in this case, I might be able to donate an XP Pro license myself (German though). As I don't know about the needs of the other members, I'd like to hear your opinion about my idea. It would also be nice to hear if anybody knows a cheap (but legal!) way to get such a license or can even donate one (e.g. unused OEM license shipped with a server, unused license after getting Server 2008, etc.) English Windows licenses are rare/expensive on German eBay, so this would only be a last resort :-) Cheers, Colin P.S.: If you have the opposite problem and actually need a Linux VM available over SSH/RDP (e.g. for testing build system changes), just let me know and I could set it up.

12 32

Re: [ros-dev] [ros-diffs] [mkupfer] 50398: - Fix draw of cursors in static controls - Last part of fix for bug #4874
by Timo Kreuzer 16 Jan '11

16 Jan '11

Shouldn't that work the same way (at least if there is any hbmColor)? Cursors can have a different size as well, so maybe we should rather query the hbmMask, if hbmColor is 0(=) I didn't bother reading the context of the function though. Am 16.01.2011 13:51, schrieb mkupfer(a)svn.reactos.org: > Author: mkupfer > Date: Sun Jan 16 12:51:14 2011 > New Revision: 50398 > > URL: http://svn.reactos.org/svn/reactos?rev=50398&view=rev > Log: > - Fix draw of cursors in static controls > - Last part of fix for bug #4874 > > Modified: > trunk/reactos/dll/win32/user32/controls/static.c > > Modified: trunk/reactos/dll/win32/user32/controls/static.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/controls/… > ============================================================================== > --- trunk/reactos/dll/win32/user32/controls/static.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/user32/controls/static.c [iso-8859-1] Sun Jan 16 12:51:14 2011 > @@ -863,7 +863,15 @@ > else > { > BITMAP bm; > - if (!GetObjectW(info.hbmColor, sizeof(BITMAP),&bm)) return; > + if (info.fIcon) > + { > + GetObjectW(info.hbmColor, sizeof(BITMAP),&bm); > + } > + else > + { > + bm.bmWidth = GetSystemMetrics(SM_CXCURSOR); > + bm.bmHeight = GetSystemMetrics(SM_CYCURSOR); > + } > if (style& SS_CENTERIMAGE) > { > iconRect.left = (rc.right - rc.left) / 2 - bm.bmWidth / 2; > > >

1 0

Re: [ros-dev] [ros-diffs] [weiden] 50396: Portability bugfixes
by Ged Murphy 16 Jan '11

16 Jan '11

Thomas the 2nd?? On 16 January 2011 01:32, <weiden(a)svn.reactos.org> wrote: > Author: weiden > Date: Sun Jan 16 01:32:45 2011 > New Revision: 50396 > > URL: http://svn.reactos.org/svn/reactos?rev=50396&view=rev > Log: > Portability bugfixes > > Modified: > trunk/reactos/lib/rtl/srw.c > > Modified: trunk/reactos/lib/rtl/srw.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/srw.c?rev=50396&r1… > > ============================================================================== > --- trunk/reactos/lib/rtl/srw.c [iso-8859-1] (original) > +++ trunk/reactos/lib/rtl/srw.c [iso-8859-1] Sun Jan 16 01:32:45 2011 > @@ -131,7 +131,7 @@ > } >

2 1

Re: [ros-dev] [ros-diffs] [gadamopoulos] 50381: [rosautotest] -Implement closing any dialog that shows and stays visible for some time. This way rosautotest can now continue if a test application crashes or asserts.
by Timo Kreuzer 13 Jan '11

13 Jan '11

Am 13.01.2011 10:58, schrieb gadamopoulos(a)svn.reactos.org: > Author: gadamopoulos > Date: Thu Jan 13 09:58:04 2011 > New Revision: 50381 > > URL: http://svn.reactos.org/svn/reactos?rev=50381&view=rev > Log: > [rosautotest] > -Implement closing any dialog that shows and stays visible for some time. This way rosautotest can now continue if a test application crashes or asserts. > Seems it causes a regression in testbot: *http://www.reactos.org/testman/compare.php?ids=4355,4356 *

1 0

Re: [ros-dev] [ros-diffs] [fireball] 50309: [HEAP] - Fix a typo (assignment) in the ASSERT, spotted by Johannes Anderwald.
by Ged Murphy 10 Jan '11

10 Jan '11

fireball(a)svn.reactos.org wrote: > if (Locked) RtlLeaveHeapLock(Heap->LockVariable); > + DbgBreakPoint(); > return FALSE; Doh

3 2

coordinate transformation
by Timo Kreuzer 06 Jan '11

06 Jan '11

Hi, I'm currently working on the coordinate transformation code in win32k. While Windows does this in win32k, I wonder why its not done in user mode and if we could depart from windows design here. The advantages would be decreased complexity in the kernel and no use of floating point emulation on x86 (better performance). Are there any things that would make it unreasonable? I don't plan to go and change this now, I just like to discuss whether we might or might not do that at some point. Timo

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 50243: [CMAKE] Add generation of a depencency graph for shared libraries. The output is a graphml file. Can be enabled with GENERATE_DEPENDENCY_GRAPH switch.
by Ged Murphy 01 Jan '11

01 Jan '11

I didn't know about this feature. Will this help the effort towards a minwin effort in fixing the dependency hierarchy (mess)? Ged. On 31 December 2010 16:49, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Fri Dec 31 16:49:49 2010 > New Revision: 50243 > > URL: http://svn.reactos.org/svn/reactos?rev=50243&view=rev > Log: > [CMAKE] > Add generation of a depencency graph for shared libraries. > The output is a graphml file. Can be enabled with GENERATE_DEPENDENCY_GRAPH > switch. > >

3 3

Is Testman and DBG-Server on strike or on Christmas holidays?
by victor martinez 30 Dec '10

30 Dec '10

I have asked several times in #reactos and in #reactos-dev channels, so now time to ask again here: What happens with the server? We are commiting a lot ( more than 25 commits/days last days) and we dont know if: 1)One of those commits (hopefully not) has broken building.. 2)One of those commits (hopefully not) has broken booting.. Both of these are pain in the a...if regtesting is needed. So: Can anyone fix this situation asap? Merry Thanks and Many Christmas ;)

6 7

Re: [ros-dev] [ros-diffs] [tkreuzer] 50217: [CMAKE] LD is stupid and doesn't handle stdcall decoration as proper as dlltool does (after we provided a patch). Passing --kill-at, also kills C++ mangled names and exports with ...
by Colin Finck 30 Dec '10

30 Dec '10

tkreuzer(a)svn.reactos.org wrote: > LD is stupid and doesn't handle stdcall decoration as proper as > dlltool does (after we provided a patch) [...] Wouldn't it have been easier to just provide a similar patch for LD then? It was a matter of changing a strchr() call to strrchr()... (http://sourceware.org/bugzilla/show_bug.cgi?id=9766) We can always use a patched binutils version in the next RosBE if the patch is not applied to the upstream source in time. Cheers, Colin

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 50077: [USBDRIVER] - Fix a bug that resulted in us onl
by Pierre Schweitzer 27 Dec '10

27 Dec '10

Hi, > Author: cgutman > Date: Tue Dec 21 04:35:12 2010 > New Revision: 50077 > > URL: http://svn.reactos.org/svn/reactos?rev=50077&view=rev > Log: > [USBDRIVER] > - Fix a bug that resulted in us only copying half of the old keyboard data > - CID 10402 > > Modified: > trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c > > Modified: trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/usb/nt4compat/usbd… > ============================================================================== > --- trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/usb/nt4compat/usbdriver/keyboard.c [iso-8859-1] Tue Dec 21 04:35:12 2010 > @@ -277,7 +277,7 @@ > } > > // Save old keyboard data > - RtlCopyMemory(pdev_ext->kbd_old, data, sizeof(data)); > + RtlCopyMemory(pdev_ext->kbd_old, data, 8); > > // resubmit the urb > status = usb_submit_urb(pdev_ext->dev_mgr, purb); This change is really dangerous and should be changed to a correct fix. Using magic values on memory copying is a bad idea. Using magic values (in general) is a bad idea. Please provide a better fix without magic value. Regards, P. Schweitzer

1 0

Re: [ros-dev] [ros-diffs] [dgorbachev] 50117: Marco Radossevich <fwdprojects=at=email=dot=it>, a.k.a. forart: "Just two important examples that involved my contributions: UniATA & FullFAT." No code changes. See thread <http...
by Ged Murphy 25 Dec '10

25 Dec '10

hahaha -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dgorbachev(a)svn.reactos.org Sent: 24 December 2010 01:59 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [dgorbachev] 50117: Marco Radossevich <fwdprojects=at=email=dot=it>, a.k.a. forart: "Just two important examples that involved my contributions: UniATA & FullFAT." No code changes. See thread <http... Author: dgorbachev Date: Fri Dec 24 01:59:13 2010 New Revision: 50117 URL: http://svn.reactos.org/svn/reactos?rev=50117&view=rev Log: Marco Radossevich <fwdprojects=at=email=dot=it>, a.k.a. forart: "Just two important examples that involved my contributions: UniATA & FullFAT." No code changes. See thread <http://www.reactos.org/forum/viewtopic.php?f=14&t=8809> for more details. Modified: trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h trunk/reactos/drivers/filesystems/fastfat_new/rw.c trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h Modified: trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… ============================================================================== --- trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h [iso-8859-1] Fri Dec 24 01:59:13 2010 @@ -80,7 +80,7 @@ CcUnpinData((xContext)->Bcb); \ (xContext)->Bcb = NULL; \ } \ - + #define FatPinEndOfPage(xContext, xType) \ Add2Ptr((xContext)->Buffer, (xContext)->ValidLength, xType) Modified: trunk/reactos/drivers/filesystems/fastfat_new/rw.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… ============================================================================== --- trunk/reactos/drivers/filesystems/fastfat_new/rw.c [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/fastfat_new/rw.c [iso-8859-1] Fri Dec 24 01:59:13 2010 @@ -36,7 +36,7 @@ FatCompleteRequest(IrpContext, IrpContext->Irp, STATUS_SUCCESS); return STATUS_SUCCESS; } - + OpenType = FatDecodeFileObject(FileObject, &Vcb, &Fcb, &Ccb); DPRINT("FatiRead() Fcb %p, Name %wZ, Offset %d, Length %d, Handle %p\n", Modified: trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/storage/ide/uniata… ============================================================================== --- trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h [iso-8859-1] (original) +++ trunk/reactos/drivers/storage/ide/uniata/inc/PostDbgMesg.h [iso-8859-1] Fri Dec 24 01:59:13 2010 @@ -43,4 +43,4 @@ }; #endif //__cplusplus -#endif //__DBG_DUMP_TOOLS__H__ +#endif //__DBG_DUMP_TOOLS__H__

5 5

[ros-diffs] [fireball] 50108: [NTOS] - Fix memory region size calculation in MemoryBasicInformation in certain cases
by victor martinez 23 Dec '10

23 Dec '10

I have a doubt: ============================================================================== --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Wed Dec 22 21:59:27 2010 @@ -2446,6 +2446,9 @@ /* Check if this VAD is too high */ if (BaseVpn < Vad->StartingVpn) { + /* Stop if there is no left child */ + if (!Vad->LeftChild) break; + /* Search on the left next */ Vad = Vad->LeftChild; } @@ -2453,6 +2456,11 @@ { /* Then this VAD is too low, keep searching on the right */ ASSERT(BaseVpn > Vad->EndingVpn); + + /* Stop if there is no right child */ + if (!Vad->LeftChild) break; + + /* Search on the right next */ Vad = Vad->RightChild; } }======================================================== Look these lines: + /* Stop if there is no left child */ + if (!Vad->LeftChild) break; + /* Stop if there is no right child */ + if (!Vad->LeftChild) break; 1) Is there a typo in the copy-pasta condition? 2) Is the comment wrong or misleading? 3) Am I a complete noob? I think the order is 3), 1), 2) One of the latest changes has made ReactOS totally uninstallable(12 tries /12 fails) using less than 192MB Ram.It halts in first stage during copying files. Merry Christmas!!

2 1

[ros-diffs] [pschweitzer] 50090: [FASTFAT] Fix for a buffer overflow and then a buffer overrun (if ever it fixes something) The way filenames are handled for FAT entries should be REALLY simplified. This would...
by James Tabor 22 Dec '10

22 Dec '10

Hi! I guess once long tyme ago, there was a little file called dos.h! Need this #define _A_VOLID 0x08 /* Volume ID file */ VolumeLabelDirEntry.Fat.Attrib = 0x08; }

2 1

Unable to get wubble launch working with ua-ros-pkg
by GANESH KUMAR 21 Dec '10

21 Dec '10

I'm not able to get the wubble simulation working for the ua-ros-pkg at: http://code.google.com/p/ua-ros-pkg [Note: I'm a new comer to ROS] Summary of Issue: I am using the Q&A Format provided by the site above. a. What steps will reproduce the problem? 1. Follow http://code.google.com/p/ua-ros-pkg/wiki/DeveloperInstall to install uav-ros-pkg packages 2. Run roslaunch wubble_mapping simulation.launch b. What is the expected output? What do you see instead? Expected output: Runs as given in http://code.google.com/p/ua-ros-pkg/wiki/ClassInstructions. Observed output: -------------- while processing /opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/empty_blocks_world.launch: while processing /opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/world_common.launch: Invalid roslaunch XML syntax: [Errno 2] No such file or directory: u'/opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/world_common.launch' ------------ c. What version of the product are you using? On what operating system? Latest trunk, on Ubuntu 10.04 /Lucid. d. Additional Notes? world_common isn't there in the given files, and neither does it get generated during the build. Also, while running make-all.sh I get 'Built 46 packages with 1 failure'. My gearbox has the following issue during the build: ========================== mkdir -p build/gearbox-svn/build cd `rospack find gearbox` && patch -d build/gearbox-svn/src/hokuyo_aist/python --verbose < `rospack find gearbox`/aist_python_mt.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- CMakeLists.txt 2010-11-05 17:13:52.719057243 -0700 |+++ CMakeLists.txt.ros 2010-11-05 17:12:30.921672551 -0700 -------------------------- Patching file CMakeLists.txt using Plan A... Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. Hunk #1 ignored at 41. 1 out of 1 hunk ignored -- saving rejects to file CMakeLists.txt.rej done =========================== I wonder whether this is causing the problem, and am not totally clear as to how to correct this. Thanks! -- Ganesh $ g++ file.c -fblocks -Wall /usr/lib/bundle1.o -arch x86_64 -o file.out

2 1

Re: [ros-dev] [ros-diffs] [rmessiant] 50076: [CLASSPNP] - Use correct type in sizeof expression (CID 1646 and 10401). - Simplify signature define (CID 3653 and 3654). - Remove funky 0xFF characters.
by Timo Kreuzer 21 Dec '10

21 Dec '10

Am 21.12.2010 01:41, schrieb rmessiant(a)svn.reactos.org: > Author: rmessiant > Date: Tue Dec 21 00:41:52 2010 > New Revision: 50076 > > ... > > -#define DICTIONARY_SIGNATURE (((ULONG)'dict'<< 32) + 'sig ') > - > -struct _DICTIONARY_HEADER { > +#define DICTIONARY_SIGNATURE 'dsig' > + I think it was supposed to be something like (ULONGLONG)'dictsig '

2 1

Heap Issues
by James Tabor 17 Dec '10

17 Dec '10

I've tested my patches with 49720 so far the wine user Dialog works. Upping to 50046 and repeating the test since 50000, this happens, (subsystems/win32/win32k/ntuser/window.c:2067) co_UserCreateWindowEx(): NCCREATE message failed (subsystems/win32/win32k/ntuser/window.c:2339) co_UserCreateWindowEx failed! kdb:> bt Eip: <ntdll.dll:92b1> lib/rtl/heap.c:358 (RtlpRemoveFreeBlock@16) Frames: <ntdll.dll:b189> lib/rtl/heap.c:2193 (RtlAllocateHeap@12) <user32.dll:32610> dialog.c:157 (DIALOG_get_info) <user32.dll:3369c> dialog.c:1577 (DefDlgProcA@16) <user32.dll:495dc> message.c:1091 (@IntCallWindowProcW@28) <user32.dll:49ead> message.c:2449 (User32CallWindowProcFromKernel@8) <ntdll.dll:7a84> <user32.dll:542c5> window.c:409 (CreateWindowExA@48) <user32.dll:343bf> dialog.c:925 (DIALOG_CreateIndirect) <user32.dll:352c0> dialog.c:1764 (DialogBoxParamA@20) <user32_winetest.exe:2055c> <user32_winetest.exe:22065> <user32_winetest.exe:a36e6> <user32_winetest.exe:a38fb> <user32_winetest.exe:a3d95> <user32_winetest.exe:a3dde> it faults at 0x00000004,,,....

2 1

Re: [ros-dev] [ros-diffs] [pschweitzer] 50021: [NTOSKRNL] Rewritten FsRtlIsDbcsInExpression() using FsRtlIsNameInExpression() pattern. This fixes all failing tests from kmtest.sys and make this function definitely tastier t...
by Ged Murphy 13 Dec '10

13 Dec '10

pschweitzer(a)svn.reactos.org wrote: > > ASSERT(Name->Length); > ASSERT(Expression->Length); > ASSERT(!FsRtlDoesDbcsContainWildCards(Name)); It'd be preferable to wrap that last ASSERT so it isn't compiled into release builds. Adding functions into asserts adds overhead on release builds as they're called for no reason. Ged.

2 2

Moving /trunk/tools into an own repository
by Colin Finck 13 Dec '10

13 Dec '10

Hello all, I'm currently developing two project tools which are going to be used by the German ReactOS foundation (custom IRC Server and plugin for Jameica - http://www.willuhn.de/products/jameica/). They shall be committed into a public ReactOS SVN repository. Since I believe that these tools are hardly useful for the average ReactOS developer, I don't want to commit them to our current /trunk/tools directory in the "reactos" repository. Among other disadvantages, every commit to them would trigger a useless BuildBot build, source checkouts would include unnecessary stuff, etc. As this is generally the case with most of the stuff in /trunk/tools, I'd like to move everything below this directory and the /irc directory into a new repository called "project-tools". We have already done a similar step in the past for the former "web" directory. Additionally, the "press-media" directory would be a similar candidate for an own "press-media" repository. After these steps, our "reactos" repository would finally contain only OS development related stuff. For comparison, Wine already keeps its main repository free from unrelated stuff and has several similar repositories (see http://source.winehq.org/git/). If there are no objections to my idea within the next two weeks, I will proceed and set up "project-tools" and "press-media" repositories (preserving as much SVN history as possible). Cheers, Colin

3 3

Re: [ros-dev] [ros-diffs] [fireball] 50000: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory mana...
by Ged Murphy 10 Dec '10

10 Dec '10

A worthy commit for r50000. You've been waiting for this revision, haven't you .... haha. Ged -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org Sent: 10 December 2010 09:33 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [fireball] 50000: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory mana... Author: fireball Date: Fri Dec 10 09:33:20 2010 New Revision: 50000 URL: http://svn.reactos.org/svn/reactos?rev=50000&view=rev Log: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory management. It supported 3 out of the 18 possible NT Heap Flags, did not support custom allocation/deallocation routines, and was about 50-80x slower with fragmentation rates up to 500x higher when compared to NT's LFH (WINE is lucky because the advanced NT Heap features are used in kernel-mode usually, not in user-mode, and they are crossing their fingers for this being the same). Several high-end SQL/Database applications would significantly benefit from custom heap features provided by NT. Not to say about removing crappy support for a custom Commit routine and crappy support for User-defined flags and the User-defined value. - So, the glorious moment for a new heap manager, which is (to remind you) a totally new heap manager, resembling real NT heap manager, based on data structures similar to Windows 2003 and Vista+'s heap structures, supporting advanced heap flags (e.g. useful for debugging), having substantially lower fragmentation rates (and thus speed and reliability), having native support for user-defined flags and user-defined values, also native support for a custom commit routine, which is very important for trunk's win32 subsystem. It also reserves, commits, decommits and frees memory on the fly, unlike existing heap manager which prefers to reserve and commit as much as possible, and doesn't decommit when it's no longer necessary. Not to say about support for per process heaps, with a proper lock, and a further support for a special so-called debug heap allocator (to be implemented in heapdbg.c) which will be useful for finding heap corruptions. Yeah, I'm not a fun person :D Added: trunk/reactos/lib/rtl/heap.c - copied unchanged from r49999, trunk/reactos/lib/rtl/heap_rewrite.c Removed: trunk/reactos/lib/rtl/heap_rewrite.c [This mail would be too long, it was shortened to contain the URLs only.] Removed: trunk/reactos/lib/rtl/heap_rewrite.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/heap_rewrite.c?rev…

4 3

Re: [ros-dev] Ros-dev Digest, Vol 76, Issue 1
by Manikandan 04 Dec '10

04 Dec '10

HI Can you tell me the files that are to be installed at time of booting the system with reactos?. With regards Mani

2 1

Re: [ros-dev] [ros-diffs] [greatlrd] 49912: all code are in ReactOS trunk for ReactX delete the old branch and prepare create new one Most of the code will be focus on dxg.sys and few part of gdi32.dll in the new branch of ...
by Ged Murphy 03 Dec '10

03 Dec '10

greatlrd(a)svn.reactos.org wrote: > Sent: 03 December 2010 09:20 > To: ros-diffs(a)reactos.org > Subject: [ros-diffs] [greatlrd] 49912: all code are in > ReactOS trunk for ReactX delete the old branch and prepare > create new one Most of the code will be focus on dxg.sys and > few part of gdi32.dll in the new branch of ... Hells bells, it's gratelood! Good to see you back mate. Ged.

1 0

Testbot
by Pierre Schweitzer 24 Nov '10

24 Nov '10

Hi, anyone (ie Colin or Christoph?) knows what's wrong with testbot? Since r49761 it can't reach 2nd stage & more. This revision has been reverted in r49767 but testbot keeps being broken. Any clue? Regards, P. Schweitzer

2 1

Re: [ros-dev] Ros-dev Digest, Vol 75, Issue 27
by Manikandan 24 Nov '10

24 Nov '10

> > I am new to reactos and i want to study it in detail. For that I wish to > construct it manually. So can u tell me the important files needed to boot > the reactos. Thanking you.

3 2

Unable to build ReactOS anymore
by Ros Arm 23 Nov '10

23 Nov '10

Hello, Why everyone else had been complaining on how we should revert changes that expose compiler bugs, I, on the other hand, have not even been able to build ReactOS anymore starting with recent revisions (probably related to C++ changes). Anyone want to fix this, please? [PCH] obj-i386/base/shell/explorer/.gch_explorer/precomp.h.gch In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/localefwd.h:42, from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/string:45, from base/shell/explorer/utility/utility.h:58, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/mingw32/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/mingw32/bits/c++locale.h:74: error: expected primary-expression before ',' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/string:46, from base/shell/explorer/utility/utility.h:58, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h: In function 'void std::__ostream_write(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:48: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:50: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h: In function 'void std::__ostream_fill(std::basic_ostream<_CharT, _Traits>&, std::streamsize)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:60: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:63: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:66: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h: In function 'std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:85: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:88: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:92: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:93: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:94: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:95: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:96: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:99: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:100: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:104: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:108: error: expected primary-expression before '.' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/iostream:40, from base/shell/explorer/utility/utility.h:59, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, _CharT)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:447: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:452: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:452: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:458: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, signed char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:464: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, unsigned char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:469: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const _CharT*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:491: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:493: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:508: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:510: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const signed char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:519: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const unsigned char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:524: error: expected primary-expression before '<<' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:565, from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/iostream:40, from base/shell/explorer/utility/utility.h:59, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:324: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:342: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:343: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:347: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:351: error: expected primary-expression before '.' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/iostream:40, from base/shell/explorer/utility/utility.h:59, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const char*) [with _Traits = std::char_traits<char>]': base/shell/explorer/utility/xmlstorage.h:2923: instantiated from here /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:512: error: return-statement with no value, in function returning 'std::basic_ostream<char, std::char_traits<char> >&' make: *** [obj-i386/base/shell/explorer/.gch_explorer/precomp.h.gch] Error 1 -r

2 1

Video of ReactOS Booting on ARM
by Ros Arm 23 Nov '10

23 Nov '10

Hello, As some have asked, http://www.youtube.com/watch?v=RFNuY2OFRjU&hd=1 Cheers! -r

6 7

Comments regarding r49691
by Pierre Schweitzer 21 Nov '10

21 Nov '10

Hi, most of the justifications for r49691 have been included in the commit message. But here are needed addings. Olaf made buildbot rebuild r49662 and retest it. Testbot manages to pass 3rd stage and to run tests. Then, Olaf retried with r49665, and it failed the same way it was failing earlier. So, we are reverting to "last good known state", aka r49662. Only two issues have been seen there: - one with MM: (ARM³::PAGFAULT:751) PAGE TABLES FAULTED IN! You can find full log here: http://download.myreactos.com/Amine/49662%20testbot%20ouptput-stdio.7z (thanks to Sylvain) - One with NPFS. Aleksey and Eric are already working on it. You can easily find it on testbot output. Other issues may also be found as many commits were done while testbot was down. Please don't start a drama on that revision. Whatever you may think about it, we cannot stay with a broken testbot forever and people keeping on committing. Taking a decision trying to sort out a mess is being professional. All the help everyone will be able to give will be appreciated! Thanks. P. Schweitzer PS: For ReactOS testbot raw results, don't forget: http://build.reactos.org:8010/ You'll find the tests ran today.

1 2

Re: [ros-dev] [ros-diffs] [pschweitzer] 49662: [NTOSKRNL] [HAL] Disable INIT_FUNCTION to s
by Pierre Schweitzer 20 Nov '10

20 Nov '10

Hi, finally this commit won't be reverted (unless someone explicitly asks for it) as it brings testman back and shows quite important bugs. Feel free to find a nice bugfix instead. WBR, P. Schweitzer

4 9

Official buildbot
by Olaf Siejka 20 Nov '10

20 Nov '10

Hiya It looks like buildbot has crashed or been shut down. I restarted the master but have no access to slaves. It will at least gather the build requests, but the missing ones since last 6 hours need to be forced manually. Christoph, could you take a look at the slaves?? Regards

1 0

Re: [ros-dev] [ros-diffs] [ekohl] 49646: [NPFS] - Rename DEVICE_EXTENSION to NPFS_VCB. - Add a type variable to distinguish FCBs and CCBs for device, directory or pipe. - Attach an FCB to the VCB that represents the root di...
by Aleksey Bragin 20 Nov '10

20 Nov '10

Great work, one more driver incompatibility away! WBR, Aleksey Bragin. On Nov 20, 2010, at 1:42 AM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Fri Nov 19 22:42:53 2010 > New Revision: 49646 > > URL: http://svn.reactos.org/svn/reactos?rev=49646&view=rev > Log: > [NPFS] > - Rename DEVICE_EXTENSION to NPFS_VCB. > - Add a type variable to distinguish FCBs and CCBs for device, > directory or pipe. > - Attach an FCB to the VCB that represents the root directory of > the file system and implement an open routine for the root directory. > - Make NpfsWaitPipe work when it is called for the root directory. > > [KERNEL32] > - Remove the old version of WaitNamedPipeW. > > This patch fixes the broken wait pipe code. It was written and > tested on r49458 because later revisions do not work for me.

1 0

Something for the holidays?
by Ros Arm 20 Nov '10

20 Nov '10

http://img824.imageshack.us/img824/734/stuffy.png -r

6 8

Virtualization tool to run ReactOS
by Arko Provo Mukherjee 18 Nov '10

18 Nov '10

Dear All, Can you please kindly let me know which Virtualization tool I can use to run ReactOS. I am using Ubuntu currently and want to run ReactOS in top of that using a VM. Thanks a lot in advance! Warm regards Arko Provo Mukherjee

4 4

winetest related regressions
by Timo Kreuzer 15 Nov '10

15 Nov '10

Just for the record: The changes are between r7324487 and r7281232. gdi32:palette +2 failures shell32:shlexec: crash user32:combo: +4 failures user32:cursoricon: -8 tests / +8 failures user32:edit: crash user32:monitor: not run user32:msg not run user32:win: -5743 tests winmm:mixer -192 tests

2 3

Question regarding declaration of RTL_DRIVE_LETTER_CURDIR in include\ndk\rtltypes.h
by Sven Barth 15 Nov '10

15 Nov '10

Hello together! I'm currently poking around in the NDK headers very much and I noted a small inconsistency in the declaration of one type. The declaration is the following in include\ndk\rtltypes.h: ==== source begin ==== typedef struct RTL_DRIVE_LETTER_CURDIR { USHORT Flags; USHORT Length; ULONG TimeStamp; UNICODE_STRING DosPath; } RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR; ==== source end ==== Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of "RTL_DRIVE_LETTER_CURDIR"? I don't know what influences this missing underscore has on compilation and such, cause I can read C without big problems and write a bit as well, but I don't understand every single bit a C compiler does ^^ Regards, Sven

5 8

Re: [ros-dev] ReactOS official compatibility target and the new build system
by Samuel serapion 14 Nov '10

14 Nov '10

Doesn't windows use SxS to provide multiple versions of some dlls? I know its not for exacly the same purpose but perhaps coupled with some sort of app compat wizard we could really set hard version targets... but ofcourse it would mean building many dlls more than once On Nov 13, 2010 2:09 PM, "Colin Finck" <mail(a)colinfinck.de> wrote:

3 2

ReactOS official compatibility target and the new build system
by Jérôme Gardou 13 Nov '10

13 Nov '10

Dear reactos developers. Once again, bringing reactos build to cmake arises questions. When this "port" has begun, it was decided that import libraries would be shipped with build environment, the now famous RosBE. This decision was made considering that : 1) functions exported by dlls do not change often. 2) Building an import library is a process that requires unneeded extra time. 3) 1 makes 2 unworthy. 4) If dll A imports function from dll B, it's not necessary to build B before A. 5) Solving 4 solves the problem of cross-dependency. As our target is win2k3 sp1 compatibility, a wise choice would be to choose import libraries that expose function only present on win2k3 sp1. The problem is that some wine dlls export functions that are from other windows versions, and, worse, use them. Let's see why this is a problem. - function A is a vista function from dll foo - function B is an XP function from dll bar - for some reasons, B implementation calls A. As you're clever developers ;-), you've seen that this would raise an error from the linker, as A is not present in our libfoo.a Hopefully, those cases are not too widespread, but they exist. Let's consider solutions that have arisen as of now : 1) Implement A as an inline function in headers, so anyone requiring it has it. 2) Linking bar.dll to some winefoo.dll, which forwards everything from foo.dll and exports the function A. 3) Add a "#if WIN32_WINNT > 0x502" before the guilty part of code, and "#else" with a win2k3 compliant implementation. 4) Oh dreams -> Ideally, convince wine to do it themself (./configure --wintarget=2k3sp1). 5) Change our target to win7, so we're ahead of wine. :-p 6) Do not change anything, and let our user mode libraries be a complete inconsistent anarchy. As 4 and 5 won't happen in a short time, let's consider 1, 2, 3 and 6: 1 is the best solution for easy winesyncs. We guard inline implementation by #ifndef BUILDING_FOO_DLL 2 would put a whole mess in system32 directory, but should be the most easy thing to do. 3 requires some extra work when syncing wine dlls. Though doing it often would reduce hassle. 6 isn't what I'd wish. What do you think? Your input is much appreciated. Best regards. The french speaking cmake team :-)

6 18

[PREFIXES] in commit messages still useful?
by Colin Finck 11 Nov '10

11 Nov '10

Hi everyone, I'm wondering whether our [PREFIXES] in commit messages are still useful as of today? If I recall correctly, they were once added to autogenerate a changelog. I also remember that this dramatically failed when Ziliang created the 0.3.12 changelog and the full changelog needed to be redone from scratch, manually of course. Furthermore, I doubt that prefixes like "[SPRINTF]" (r49512) or faulty ones like "{ASM]" (r49413) can still be reasonably associated to a changelog category. After all, we don't even have a list of valid prefixes, so one has to first look at all used ones anyway. Of course, I don't want them to be dropped instantly tomorrow, but I'm interested in your opinions. I also don't yet know about the planned method for creating the 0.3.13 changelog, so I might be wrong on this. Cheers, Colin

5 4

Networking
by Oleg Baikalow 06 Nov '10

06 Nov '10

Hi, I see you're busy discussing other stuff and my message went unnoticed :) I made a look to existing network branches, found many of them. LWIP is interesting. Alexey said the best way is to join your irc channel. I will try to occasionally join, but in your project, mailing list must be a primary point of discussion not irc channel. I think I start from making a simple, but robust tcpip driver (with help of numerously available source code of tcp/ip protocol implementations). Hopefully you could give me branch access, it's gonna be hard to develop it with patches. // Oleg Baikalow. P.S. I really like your "kernel coding style", quite rare to see that in opensource projects. Most of foss projects utilize linux-alike stlye, whic is harder to read and not that clean.

17 28

Hook rewrite / regressions
by Aleksey Bragin 05 Nov '10

05 Nov '10

Hello, we have a serious regression in trunk which started 23rd of October with revision 49231 ("hook rewrite"). Considerable amount of time passed, automatic testing is not possible thus I'm afraid we are accumulating bugs. I think there is a need to revert 49231 + its dependencies in trunk to allow automated testing to work again and also fix regressions caused by this rewrite, and move this rewrite to a branch if possible. In future, it would be a good idea to: a. Discuss such serious rewrite merges beforehand (like Timo did with Yarotows). b. Try not to merge all rewrites simulteneously. E.g. I have to wait with heap rewrite merge (every rewrite contains a certain amount of bugs, by definition) even though it's fully ready. James - could you please share your opinion? The decision is yours, as you are the author of that commit. WBR, Aleksey Bragin.

4 10

Exceptional exception handling
by Roel Messiant 04 Nov '10

04 Nov '10

Hey everyone, a few days ago, I started investigating a report in Bugzilla containing an application that raises an exception that goes unhandled, and the stack trace that gets printed is clearly corrupt. The report is the following: http://www.reactos.org/bugzilla/show_bug.cgi?id=5684 At first I thought the context wasn't being recorded properly, since both EBP and ESP are reported as being 0 at the time the exception was raised. However, there are applications for which we show a correct stack trace in case of an unhandled exception, so this most likely wasn't the case. My next thought was that we were somehow corrupting the context, but this wasn't the case either. The exception is also being dispatched nicely: exception handlers get the correct details. Lastly, the UnhandledExceptionFilter seemed to be passing the context on to the stack trace printing function without altering it, so the problem isn't there either. So where else could something be happening? That's right, inside one of the exception handler functions. Some of you may recognize the exception code (0xeedfade) in the bug report as a Delphi exception. I did too, so I fired up my copy of Delphi 6 and went digging in its exception handler functions. Every occurrence of UnhandledExceptionFilter in its exception handler functions showed the context wasn't being passed to it, but instead the registration frame was. This happens in a very predictive way however, so creating a patch (read: filthy hack) that detects this and fixes up the context record was easy. It is heavily tied to exactly this kind of defect, no general case. Running the application still triggers the exception of course, but now we get a reliable stack trace. A naive search in Bugzilla indicates at least the following reports are affected by this problem: Bug 3602, bug 3927, bug 5123 and bug 5684. I haven't tested them all, but the tell-tale signs are there. What does one do when encountering such a bug in compiler? Check if it still exists in the latest version and file a bug report of course. I got confirmation that the bug is present in the recently released Delphi XE with the help of Marco van de Voort of the FreePascal project (shameless plug, I know). A bug report has been filed with what I consider an extreme amount of detail and how to solve it in their product. Did I mention the report also contains a shameless plug to the ReactOS project? Today, to my astonishment, I found another report on their site which.. you guessed it.. mentions this problem. This report appears to have been made in 2007, so guessing when (newly compiled) Delphi applications will finally start calling UnhandledExceptionFilter correctly is an exercise I leave to the reader. Now to get to the question that some of you may already be asking, and is the purpose of this mail: Are we putting this hack into our codebase so we get a decent stack trace when an application messes up in the manner this mail is about, or not? Applications can mess this up in a lot of different ways, so it won't work on those. I warmly invite everyone to weigh in on this attempt of a discussion (which I hope will be productive), and hope people will see (again) that not everything that goes wrong in ReactOS is the fault of the OS. References for those interested in the nasty details: Bug report: http://qc.embarcadero.com/wc/qcmain.aspx?d=89377 Patch: Index: dll/win32/kernel32/except/except.c =================================================================== --- dll/win32/kernel32/except/except.c (revision 49448) +++ dll/win32/kernel32/except/except.c (working copy) @@ -218,6 +218,13 @@ PEXCEPTION_RECORD ExceptionRecord = ExceptionInfo->ExceptionRecord; PCONTEXT ContextRecord = ExceptionInfo->ContextRecord; + /* Attempt to hack around bad calls of UnhandledExceptionFilter */ + if ((ULONG_PTR) (ExceptionRecord->ExceptionAddress) != (ULONG_PTR) (ContextRecord->Eip)) + { + DPRINT1("Bogus context detected, using context record HACK!!\n"); + ContextRecord = (PCONTEXT) ExceptionInfo[1].ExceptionRecord; + } + /* Print a stack trace. */ DbgPrint("Unhandled exception\n"); DbgPrint("ExceptionCode: %8x\n", ExceptionRecord->ExceptionCode); @@ -415,11 +422,17 @@ if (dwExceptionCode == 0xeedface) { - DPRINT1("Delphi Exception at address: %p\n", ExceptionRecord.ExceptionInformation[0]); + DPRINT1("Delphi 2 Exception at address: %p\n", ExceptionRecord.ExceptionInformation[0]); DPRINT1("Exception-Object: %p\n", ExceptionRecord.ExceptionInformation[1]); DPRINT1("Exception text: %s\n", ExceptionRecord.ExceptionInformation[2]); } + if (dwExceptionCode == 0xeedfade) + { + DPRINT1("Delphi Exception at address: %p\n", ExceptionRecord.ExceptionInformation[0]); + DPRINT1("Exception-Object: %p\n", ExceptionRecord.ExceptionInformation[1]); + } + /* Trace the wine special error and show the modulename and functionname */ if (dwExceptionCode == 0x80000100 /*EXCEPTION_WINE_STUB*/) { WBR, Roel Messiant

2 4

Re: [ros-dev] [ros-diffs] [fireball] 49465: [REGEDIT] Adam Kachwalla <geekdundee at gmail.
by Pierre Schweitzer 04 Nov '10

04 Nov '10

Hi, when commiting translation changes in a patch, please modify every language resources file. Think about our translators :). Best regards, P. Schweitzer

4 5

Re: [ros-dev] explorer_new
by Ged Murphy 03 Nov '10

03 Nov '10

Exactly. The current explorer is self contained and incorrect according to true win32 shell architecture. Our shell libraries aren’t complete enough to support the new explorer. Andrew Hill was working on these libraries along with a basic ATL implementation some time ago. I haven’t heard from him for a while now though. Ged. From: Adam Kachwalla [mailto:geekdundee@gmail.com] Sent: 03 November 2010 08:51 To: Ged Murphy Subject: Re: [ros-dev] explorer_new Interesting... so I guess the old explorer.exe implemented that from scratch - I guess the one in shell32 is incomplete then right? On Wed, 03 Nov 2010 19:50:18 +1100, Ged Murphy <gedmurphy(a)gmail.com> wrote: It’s implemented in shell32 as an undocumented COM object. From: Adam Kachwalla [mailto:geekdundee@gmail.com] Sent: 03 November 2010 08:34 To: Ged Murphy Subject: Re: [ros-dev] explorer_new It is part of the shell though isn't it? If start menu isn't part of explorer then what is it part of? On Wed, 03 Nov 2010 19:32:53 +1100, Ged Murphy <gedmurphy(a)gmail.com> wrote: That’s because the start menu isn’t part of explorer From: Adam Kachwalla [mailto:geekdundee@gmail.com] Sent: 03 November 2010 08:28 To: 'ReactOS Development List'; Ged Murphy Subject: Re: [ros-dev] explorer_new Although it seems completely non-functional in the latest trunk builds. Start menu doesn't work, etc. On Wed, 03 Nov 2010 19:23:29 +1100, Ged Murphy <gedmurphy(a)gmail.com> wrote: It’s relatively complete, it’s the support libraries which are incomplete. The only people with then necessary COM and shell skills (which is only really 2 of the ros devs) are either busy with other things or on sabbatical. Ged. From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Adam Kachwalla Sent: 03 November 2010 01:19 To: ReactOS Development List Subject: [ros-dev] explorer_new Can anybody tell me what explorer_new is meant to be there for? I understand people used to be working on it before, but it seems abandoned. -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish. -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish. -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish.

2 2

explorer_new
by Adam Kachwalla 03 Nov '10

03 Nov '10

Can anybody tell me what explorer_new is meant to be there for? I understand people used to be working on it before, but it seems abandoned.

4 5

Keyboard device question
by Fan Zhang 02 Nov '10

02 Nov '10

Hi guys, I'm reading win32k.sys right now. I found KeyboardThreadMain thread only use KeyboardClass0 device. I want to know how to communicate KeyboardClass1,KeyboardClass2, and so on? Fan Zhang

1 0

Keyboard device question
by Fan Zhang 02 Nov '10

02 Nov '10

Hi guys, I'm reading win32k.sys right now. I found KeyboardThreadMain thread only use KeyboardClass0 device. I want to know how to communicate KeyboardClass1,KeyboardClass2, and so on? Fan Zhang

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 49346: [CMAKE] - jscript requires stdole2.tlb
by Timo Kreuzer 01 Nov '10

01 Nov '10

Aren't you confusing build time dependencies with run time dependencies here? Am 30.10.2010 11:22, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Sat Oct 30 09:22:55 2010 > New Revision: 49346 > > URL: http://svn.reactos.org/svn/reactos?rev=49346&view=rev > Log: > [CMAKE] > - jscript requires stdole2.tlb > > Modified: > branches/cmake-bringup/dll/win32/jscript/CMakeLists.txt > > Modified: branches/cmake-bringup/dll/win32/jscript/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/dll/win32/jscript… > ============================================================================== > --- branches/cmake-bringup/dll/win32/jscript/CMakeLists.txt [iso-8859-1] (original) > +++ branches/cmake-bringup/dll/win32/jscript/CMakeLists.txt [iso-8859-1] Sat Oct 30 09:22:55 2010 > @@ -50,5 +50,5 @@ > kernel32 > ntdll) > > -add_dependencies(jscript jsglobal jscript_def) > +add_dependencies(jscript jsglobal jscript_def stdole2) > add_livecd_target(jscript reactos/system32) > > >

1 0

Re: [ros-dev] [ros-diffs] [janderwald] 49389: [PORTCLS] - Add MPU-401 Uart miniport driver from DDK 2003 sample
by Ged Murphy 01 Nov '10

01 Nov '10

Shouldn't miniport_dmus.cpp have a licence header? -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of janderwald(a)svn.reactos.org Sent: 01 November 2010 00:27 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [janderwald] 49389: [PORTCLS] - Add MPU-401 Uart miniport driver from DDK 2003 sample Author: janderwald Date: Mon Nov 1 00:26:59 2010 New Revision: 49389 URL: http://svn.reactos.org/svn/reactos?rev=49389&view=rev Log: [PORTCLS] - Add MPU-401 Uart miniport driver from DDK 2003 sample Modified: trunk/reactos/drivers/wdm/audio/backpln/portcls/guids.cpp trunk/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp trunk/reactos/drivers/wdm/audio/backpln/portcls/private.hpp Modified: trunk/reactos/drivers/wdm/audio/backpln/portcls/guids.cpp URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/wdm/audio/backpln/… ============================================================================== --- trunk/reactos/drivers/wdm/audio/backpln/portcls/guids.cpp [iso-8859-1] (original) +++ trunk/reactos/drivers/wdm/audio/backpln/portcls/guids.cpp [iso-8859-1] Mon Nov 1 00:26:59 2010 @@ -35,7 +35,6 @@ const GUID CLSID_MiniportDriverFmSynth = {0xb4c90ae0L, 0x5791, 0x11d0, {0x86, 0xf9, 0x00, 0xa0, 0xc9, 0x11, 0xb5, 0x44}}; const GUID CLSID_MiniportDriverFmSynthWithVol = {0xe5a3c139L, 0xf0f2, 0x11d1, {0x81, 0xaf, 0x00, 0x60, 0x08, 0x33, 0x16, 0xc1}}; - const GUID IID_IPort = {0xb4c90a25L, 0x5791, 0x11d0, {0x86, 0xf9, 0x00, 0xa0, 0xc9, 0x11, 0xb5, 0x44}}; const GUID IID_IDrmPort = {0x286D3DF8L, 0xCA22, 0x4E2E, {0xB9, 0xBC, 0x20, 0xB4, 0xF0, 0xE2, 0x01, 0xCE}}; const GUID IID_IDrmPort2 = {0x1ACCE59CL, 0x7311, 0x4B6B, {0x9F, 0xBA, 0xCC, 0x3B, 0xA5, 0x9A, 0xCD, 0xCE}}; @@ -46,6 +45,7 @@ const GUID IID_IPortDMus = {0xc096df9cL, 0xfb09, 0x11d1, {0x81, 0xb0, 0x00, 0x60, 0x08, 0x33, 0x16, 0xc1}}; const GUID IID_IAdapterPowerManagement = {0x793417D0L, 0x35FE, 0x11D1, {0xAD, 0x08, 0x00, 0xA0, 0xC9, 0x0A, 0xB1, 0xB0}}; +const GUID IID_IMiniport = {0xb4c90a24, 0x5791, 0x11d0, {0x86, 0xf9, 0x00, 0xa0, 0xc9, 0x11, 0xb5, 0x44}}; const GUID IID_IMiniportWaveCyclic = {0xb4c90a27L, 0x5791, 0x11d0, {0x86, 0xf9, 0x00, 0xa0, 0xc9, 0x11, 0xb5, 0x44}}; const GUID IID_IPortWaveCyclic = {0xb4c90a26L, 0x5791, 0x11d0, {0x86, 0xf9, 0x00, 0xa0, 0xc9, 0x11, 0xb5, 0x44}}; const GUID IID_IResourceList = {0x22C6AC60L, 0x851B, 0x11D0, {0x9A, 0x7F, 0x00, 0xAA, 0x00, 0x38, 0xAC, 0xFE}}; @@ -59,6 +59,7 @@ const GUID IID_IPortClsVersion = {0x7D89A7BBL, 0x869B, 0x4567, {0x8D, 0xBE, 0x1E, 0x16, 0x8C, 0xC8, 0x53, 0xDE}}; const GUID IID_IUnknown = {0x00000000, 0x0000, 0x0000, {0x00, 0x00, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x46}}; const GUID IID_IPortEvents = {0xA80F29C4L, 0x5498, 0x11D2, {0x95, 0xD9, 0x00, 0xC0, 0x4F, 0xB9, 0x25, 0xD3}}; +const GUID IID_IMusicTechnology = {0x80396C3C, 0xCBCB, 0x409B, {0x9F, 0x65, 0x4F, 0x1E, 0x74, 0x67, 0xCD, 0xAF}}; const GUID KSNAME_PIN = {0x146F1A80, 0x4791, 0x11D0, {0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00}}; const GUID IID_IDrmAudioStream = {0x1915c967, 0x3299, 0x48cb, {0xa3, 0xe4, 0x69, 0xfd, 0x1d, 0x1b, 0x30, 0x6e}}; @@ -69,7 +70,13 @@ const GUID KS_CATEGORY_RENDER = {0x65E8773E, 0x8F56, 0x11D0, {0xA3, 0xB9, 0x00, 0xA0, 0xC9, 0x22, 0x31, 0x96}}; const GUID KS_CATEGORY_CAPTURE = {0x65E8773D, 0x8F56, 0x11D0, {0xA3, 0xB9, 0x00, 0xA0, 0xC9, 0x22, 0x31, 0x96}}; const GUID KS_CATEGORY_TOPOLOGY = {0xDDA54A40, 0x1E4C, 0x11D1, {0xA0, 0x50, 0x40, 0x57, 0x05, 0xC1, 0x00, 0x00}}; +const GUID KSCATEGORY_AUDIO = {0x6994AD04L, 0x93EF, 0x11D0, {0xA3, 0xCC, 0x00, 0xA0, 0xC9, 0x22, 0x31, 0x96}}; + +const GUID KSNODETYPE_SYNTHESIZER = {0xDFF220F3, 0xF70F, 0x11D0, {0xB9, 0x17, 0x00, 0xA0, 0xC9, 0x22, 0x31, 0x96}}; +const GUID KSAUDFNAME_DMUSIC_MPU_IN = {0xB2EC0A7D, 0xBAC9, 0x11d2, {0xB7, 0xA8, 0x00, 0x60, 0x08, 0x33, 0x16, 0xC1}}; +const GUID KSAUDFNAME_MIDI = {0x185FEDF8L, 0x9905, 0x11D1, {0x95, 0xA9, 0x00, 0xC0, 0x4F, 0xB9, 0x25, 0xD3}}; +const GUID KSAUDFNAME_DMUSIC_MPU_OUT = {0xA4DF0EB5, 0xBAC9, 0x11d2, {0xB7, 0xA8, 0x00, 0x60, 0x08, 0x33, 0x16, 0xC1}}; const GUID KSDATAFORMAT_TYPE_AUDIO = {0x73647561L, 0x0000, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}}; const GUID KSDATAFORMAT_SUBTYPE_PCM = {0x00000001L, 0x0000, 0x0010, {0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}}; @@ -80,13 +87,16 @@ const GUID KSPROPSETID_Connection = {0x1D58C920L, 0xAC9B, 0x11CF, {0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00}}; const GUID KSPROPTYPESETID_General = {0x97E99BA0L, 0xBDEA, 0x11CF, {0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00}}; const GUID KSPROPSETID_DrmAudioStream = {0x2f2c8ddd, 0x4198, 0x4fac, {0xba, 0x29, 0x61, 0xbb, 0x05, 0xb7, 0xde, 0x06}}; +const GUID KSPROPSETID_Synth = {0xfedfae25L, 0xe46e, 0x11d1, {0xaa, 0xce, 0x00, 0x00, 0xf8, 0x75, 0xac, 0x12}}; +const GUID KSPROPSETID_Audio = {0x45FFAAA0L, 0x6E1B, 0x11D0, {0xBC, 0xF2, 0x44, 0x45, 0x53, 0x54, 0x00, 0x00}}; const GUID KSEVENTSETID_LoopedStreaming = {0x4682B940L, 0xC6EF, 0x11D0, {0x96, 0xD8, 0x00, 0xAA, 0x00, 0x51, 0xE5, 0x1D}}; const GUID KSEVENTSETID_Connection = {0x7f4bcbe0L, 0x9ea5, 0x11cf, {0xa5, 0xd6, 0x28, 0xdb, 0x04, 0xc1, 0x00, 0x00}}; const GUID IID_IAllocatorMXF = {0xa5f0d62cL, 0xb30f, 0x11d2, {0xb7, 0xa3, 0x00, 0x60, 0x08, 0x33, 0x16, 0xc1}}; +const GUID IID_IMXF = {0xc096df9e, 0xfb09, 0x11d1, {0x81, 0xb0, 0x00, 0x60, 0x08, 0x33, 0x16, 0xc1}}; +const GUID KSMUSIC_TECHNOLOGY_PORT = {0x86C92E60, 0x62E8, 0x11CF, {0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00}}; -const GUID KSPROPSETID_Audio = {0x45FFAAA0L, 0x6E1B, 0x11D0, {0xBC, 0xF2, 0x44, 0x45, 0x53, 0x54, 0x00, 0x00}}; /// /// undocumented guids Modified: trunk/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/wdm/audio/backpln/… ============================================================================== --- trunk/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp [iso-8859-1] (original) +++ trunk/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp [iso-8859-1] Mon Nov 1 00:26:59 2010 @@ -1,15 +1,92 @@ -/* - * COPYRIGHT: See COPYING in the top level directory - * PROJECT: ReactOS Kernel Streaming - * FILE: drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp - * PURPOSE: DirectMusic miniport - * PROGRAMMER: Johannes Anderwald - */ - #include "private.hpp" -class CMiniportDMus : public IMiniportDMus -{ +// + for absolute / - for relative +#define kOneMillisec (10 * 1000) + +// +// MPU401 ports +// +#define MPU401_REG_STATUS 0x01 // Status register +#define MPU401_DRR 0x40 // Output ready (for command or data) + // if this bit is set, the output FIFO is FULL +#define MPU401_DSR 0x80 // Input ready (for data) + // if this bit is set, the input FIFO is empty + +#define MPU401_REG_DATA 0x00 // Data in +#define MPU401_REG_COMMAND 0x01 // Commands +#define MPU401_CMD_RESET 0xFF // Reset command +#define MPU401_CMD_UART 0x3F // Switch to UART mod + + +/***************************************************************************** + * Prototypes + */ + +NTSTATUS NTAPI InitMPU(IN PINTERRUPTSYNC InterruptSync,IN PVOID DynamicContext); +NTSTATUS ResetHardware(PUCHAR portBase); +NTSTATUS ValidatePropertyRequest(IN PPCPROPERTY_REQUEST pRequest, IN ULONG ulValueSize, IN BOOLEAN fValueRequired); +NTSTATUS NTAPI PropertyHandler_Synth(IN PPCPROPERTY_REQUEST PropertyRequest); +NTSTATUS NTAPI DMusMPUInterruptServiceRoutine(PINTERRUPTSYNC InterruptSync,PVOID DynamicContext); +VOID NTAPI DMusUARTTimerDPC(PKDPC Dpc,PVOID DeferredContext,PVOID SystemArgument1,PVOID SystemArgument2); +NTSTATUS NTAPI SynchronizedDMusMPUWrite(PINTERRUPTSYNC InterruptSync,PVOID syncWriteContext); +/***************************************************************************** + * Constants + */ + +const BOOLEAN COMMAND = TRUE; +const BOOLEAN DATA = FALSE; + +const ULONG kMPUInputBufferSize = 128; + + +/***************************************************************************** + * Classes + */ + +/***************************************************************************** + * CMiniportDMusUART + ***************************************************************************** + * MPU-401 miniport. This object is associated with the device and is + * created when the device is started. The class inherits IMiniportDMus + * so it can expose this interface and CUnknown so it automatically gets + * reference counting and aggregation support. + */ +class CMiniportDMusUART +: public IMiniportDMus, + public IMusicTechnology, + public IPowerNotify +{ +private: + LONG m_Ref; // Reference count + KSSTATE m_KSStateInput; // Miniport state (RUN/PAUSE/ACQUIRE/STOP) + PPORTDMUS m_pPort; // Callback interface. + PUCHAR m_pPortBase; // Base port address. + PINTERRUPTSYNC m_pInterruptSync; // Interrupt synchronization object. + PSERVICEGROUP m_pServiceGroup; // Service group for capture. + PMASTERCLOCK m_MasterClock; // for input data + REFERENCE_TIME m_InputTimeStamp; // capture data timestamp + USHORT m_NumRenderStreams; // Num active render streams. + USHORT m_NumCaptureStreams; // Num active capture streams. + ULONG m_MPUInputBufferHead; // Index of the newest byte in the FIFO. + ULONG m_MPUInputBufferTail; // Index of the oldest empty space in the FIFO. + GUID m_MusicFormatTechnology; + POWER_STATE m_PowerState; // Saved power state (D0 = full power, D3 = off) + BOOLEAN m_fMPUInitialized; // Is the MPU HW initialized. + BOOLEAN m_UseIRQ; // FALSE if no IRQ is used for MIDI. + UCHAR m_MPUInputBuffer[kMPUInputBufferSize]; // Internal SW FIFO. + + /************************************************************************* + * CMiniportDMusUART methods + * + * These are private member functions used internally by the object. + * See MINIPORT.CPP for specific descriptions. + */ + NTSTATUS ProcessResources + ( + IN PRESOURCELIST ResourceList + ); + NTSTATUS InitializeHardware(PINTERRUPTSYNC interruptSync,PUCHAR portBase); + public: STDMETHODIMP QueryInterface( REFIID InterfaceId, PVOID* Interface); @@ -29,107 +106,2584 @@ } return m_Ref; } - IMP_IMiniportDMus; - CMiniportDMus(IUnknown *OuterUnknown){} - virtual ~CMiniportDMus(){} - -protected: - LONG m_Ref; - + + CMiniportDMusUART(IUnknown * Unknown){} + ~CMiniportDMusUART(); + + /************************************************************************* + * IMiniport methods + */ + STDMETHODIMP_(NTSTATUS) + GetDescription + ( OUT PPCFILTER_DESCRIPTOR * OutFilterDescriptor + ); + STDMETHODIMP_(NTSTATUS) + DataRangeIntersection + ( IN ULONG PinId + , IN PKSDATARANGE DataRange + , IN PKSDATARANGE MatchingDataRange + , IN ULONG OutputBufferLength + , OUT PVOID ResultantFormat + , OUT PULONG ResultantFormatLength + ) + { + return STATUS_NOT_IMPLEMENTED; + } + + /************************************************************************* + * IMiniportDMus methods + */ + STDMETHODIMP_(NTSTATUS) Init + ( + IN PUNKNOWN UnknownAdapter, + IN PRESOURCELIST ResourceList, + IN PPORTDMUS Port, + OUT PSERVICEGROUP * ServiceGroup + ); + STDMETHODIMP_(NTSTATUS) NewStream + ( + OUT PMXF * Stream, + IN PUNKNOWN OuterUnknown OPTIONAL, + IN POOL_TYPE PoolType, + IN ULONG PinID, + IN DMUS_STREAM_TYPE StreamType, + IN PKSDATAFORMAT DataFormat, + OUT PSERVICEGROUP * ServiceGroup, + IN PAllocatorMXF AllocatorMXF, + IN PMASTERCLOCK MasterClock, + OUT PULONGLONG SchedulePreFetch + ); + STDMETHODIMP_(void) Service + ( void + ); + + /************************************************************************* + * IMusicTechnology methods + */ + IMP_IMusicTechnology; + + /************************************************************************* + * IPowerNotify methods + */ + IMP_IPowerNotify; + + /************************************************************************* + * Friends + */ + friend class CMiniportDMusUARTStream; + friend NTSTATUS + DMusMPUInterruptServiceRoutine(PINTERRUPTSYNC InterruptSync,PVOID DynamicContext); + friend NTSTATUS + SynchronizedDMusMPUWrite(PINTERRUPTSYNC InterruptSync,PVOID syncWriteContext); + friend VOID NTAPI + DMusUARTTimerDPC(PKDPC Dpc,PVOID DeferredContext,PVOID SystemArgument1,PVOID SystemArgument2); + friend NTSTATUS NTAPI PropertyHandler_Synth(IN PPCPROPERTY_REQUEST PropertyRequest); + friend STDMETHODIMP_(NTSTATUS) SnapTimeStamp(PINTERRUPTSYNC InterruptSync,PVOID pStream); }; -// IUnknown methods - +/***************************************************************************** + * CMiniportDMusUARTStream + ***************************************************************************** + * MPU-401 miniport stream. This object is associated with the pin and is + * created when the pin is instantiated. It inherits IMXF + * so it can expose this interface and CUnknown so it automatically gets + * reference counting and aggregation support. + */ +class CMiniportDMusUARTStream : public IMXF +{ +private: + LONG m_Ref; // Reference Count + CMiniportDMusUART * m_pMiniport; // Parent. + REFERENCE_TIME m_SnapshotTimeStamp; // Current snapshot of miniport's input timestamp. + PUCHAR m_pPortBase; // Base port address. + BOOLEAN m_fCapture; // Whether this is capture. + long m_NumFailedMPUTries; // Deadman timeout for MPU hardware. + PAllocatorMXF m_AllocatorMXF; // source/sink for DMus structs + PMXF m_sinkMXF; // sink for DMus capture + PDMUS_KERNEL_EVENT m_DMKEvtQueue; // queue of waiting events + ULONG m_NumberOfRetries; // Number of consecutive times the h/w was busy/full + ULONG m_DMKEvtOffset; // offset into the event + KDPC m_Dpc; // DPC for timer + KTIMER m_TimerEvent; // timer + BOOL m_TimerQueued; // whether a timer has been set + KSPIN_LOCK m_DpcSpinLock; // protects the ConsumeEvents DPC + + STDMETHODIMP_(NTSTATUS) SourceEvtsToPort(); + STDMETHODIMP_(NTSTATUS) ConsumeEvents(); + STDMETHODIMP_(NTSTATUS) PutMessageLocked(PDMUS_KERNEL_EVENT pDMKEvt); + +public: + STDMETHODIMP QueryInterface( REFIID InterfaceId, PVOID* Interface); + + STDMETHODIMP_(ULONG) AddRef() + { + InterlockedIncrement(&m_Ref); + return m_Ref; + } + STDMETHODIMP_(ULONG) Release() + { + InterlockedDecrement(&m_Ref); + + if (!m_Ref) + { + delete this; + return 0; + } + return m_Ref; + } + + ~CMiniportDMusUARTStream(); + + STDMETHODIMP_(NTSTATUS) Init + ( + IN CMiniportDMusUART * pMiniport, + IN PUCHAR pPortBase, + IN BOOLEAN fCapture, + IN PAllocatorMXF allocatorMXF, + IN PMASTERCLOCK masterClock + ); + + NTSTATUS HandlePortParams + ( + IN PPCPROPERTY_REQUEST Request + ); + + /************************************************************************* + * IMiniportStreamDMusUART methods + */ + IMP_IMXF; + + STDMETHODIMP_(NTSTATUS) Write + ( + IN PVOID BufferAddress, + IN ULONG BytesToWrite, + OUT PULONG BytesWritten + ); + + friend VOID NTAPI + DMusUARTTimerDPC + ( + IN PKDPC Dpc, + IN PVOID DeferredContext, + IN PVOID SystemArgument1, + IN PVOID SystemArgument2 + ); + friend NTSTATUS PropertyHandler_Synth(IN PPCPROPERTY_REQUEST); + friend STDMETHODIMP_(NTSTATUS) SnapTimeStamp(PINTERRUPTSYNC InterruptSync,PVOID pStream); +}; + +/***************************************************************************** + * miniport.cpp - UART miniport implementation + ***************************************************************************** + * Copyright (c) 1997-2000 Microsoft Corporation. All Rights Reserved. + * + * Feb 98 MartinP -- based on UART, began deltas for DirectMusic. + */ + +#define STR_MODULENAME "DMusUART:Miniport: " + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +#define UartFifoOkForWrite(status) ((status & MPU401_DRR) == 0) +#define UartFifoOkForRead(status) ((status & MPU401_DSR) == 0) + +typedef struct +{ + CMiniportDMusUART *Miniport; + PUCHAR PortBase; + PVOID BufferAddress; + ULONG Length; + PULONG BytesRead; +} +SYNCWRITECONTEXT, *PSYNCWRITECONTEXT; + +/***************************************************************************** + * PinDataRangesStreamLegacy + * PinDataRangesStreamDMusic + ***************************************************************************** + * Structures indicating range of valid format values for live pins. + */ +static +KSDATARANGE_MUSIC PinDataRangesStreamLegacy = +{ + { + { + sizeof(KSDATARANGE_MUSIC), + 0, + 0, + 0, + {STATICGUIDOF(KSDATAFORMAT_TYPE_MUSIC)}, + {STATICGUIDOF(KSDATAFORMAT_SUBTYPE_MIDI)}, + {STATICGUIDOF(KSDATAFORMAT_SPECIFIER_NONE)} + } + }, + {STATICGUIDOF(KSMUSIC_TECHNOLOGY_PORT)}, + 0, + 0, + 0xFFFF +}; +static +KSDATARANGE_MUSIC PinDataRangesStreamDMusic = +{ + { + { + sizeof(KSDATARANGE_MUSIC), + 0, + 0, + 0, + {STATICGUIDOF(KSDATAFORMAT_TYPE_MUSIC)}, + {STATICGUIDOF(KSDATAFORMAT_SUBTYPE_DIRECTMUSIC)}, + {STATICGUIDOF(KSDATAFORMAT_SPECIFIER_NONE)} + } + }, + {STATICGUIDOF(KSMUSIC_TECHNOLOGY_PORT)}, + 0, + 0, + 0xFFFF +}; + +/***************************************************************************** + * PinDataRangePointersStreamLegacy + * PinDataRangePointersStreamDMusic + * PinDataRangePointersStreamCombined + ***************************************************************************** + * List of pointers to structures indicating range of valid format values + * for live pins. + */ +static +PKSDATARANGE PinDataRangePointersStreamLegacy[] = +{ + PKSDATARANGE(&PinDataRangesStreamLegacy) +}; +static +PKSDATARANGE PinDataRangePointersStreamDMusic[] = +{ + PKSDATARANGE(&PinDataRangesStreamDMusic) +}; +static +PKSDATARANGE PinDataRangePointersStreamCombined[] = +{ + PKSDATARANGE(&PinDataRangesStreamLegacy) + ,PKSDATARANGE(&PinDataRangesStreamDMusic) +}; + +/***************************************************************************** + * PinDataRangesBridge + ***************************************************************************** + * Structures indicating range of valid format values for bridge pins. + */ +static +KSDATARANGE PinDataRangesBridge[] = +{ + { + { + sizeof(KSDATARANGE), + 0, + 0, + 0, + {STATICGUIDOF(KSDATAFORMAT_TYPE_MUSIC)}, + {STATICGUIDOF(KSDATAFORMAT_SUBTYPE_MIDI_BUS)}, + {STATICGUIDOF(KSDATAFORMAT_SPECIFIER_NONE)} + } + } +}; + +/***************************************************************************** + * PinDataRangePointersBridge + ***************************************************************************** + * List of pointers to structures indicating range of valid format values + * for bridge pins. + */ +static +PKSDATARANGE PinDataRangePointersBridge[] = +{ + &PinDataRangesBridge[0] +}; + +/***************************************************************************** + * SynthProperties + ***************************************************************************** + * List of properties in the Synth set. + */ +static +PCPROPERTY_ITEM +SynthProperties[] = +{ + // Global: S/Get synthesizer caps + { + &KSPROPSETID_Synth, + KSPROPERTY_SYNTH_CAPS, + KSPROPERTY_TYPE_GET | KSPROPERTY_TYPE_BASICSUPPORT, + PropertyHandler_Synth + }, + // Global: S/Get port parameters + { + &KSPROPSETID_Synth, + KSPROPERTY_SYNTH_PORTPARAMETERS, + KSPROPERTY_TYPE_GET | KSPROPERTY_TYPE_BASICSUPPORT, + PropertyHandler_Synth + }, + // Per stream: S/Get channel groups + { + &KSPROPSETID_Synth, + KSPROPERTY_SYNTH_CHANNELGROUPS, + KSPROPERTY_TYPE_SET | KSPROPERTY_TYPE_GET | KSPROPERTY_TYPE_BASICSUPPORT, + PropertyHandler_Synth + }, + // Per stream: Get current latency time + { + &KSPROPSETID_Synth, + KSPROPERTY_SYNTH_LATENCYCLOCK, + KSPROPERTY_TYPE_GET | KSPROPERTY_TYPE_BASICSUPPORT, + PropertyHandler_Synth + } +}; +DEFINE_PCAUTOMATION_TABLE_PROP(AutomationSynth, SynthProperties); +DEFINE_PCAUTOMATION_TABLE_PROP(AutomationSynth2, SynthProperties); + +#define kMaxNumCaptureStreams 1 +#define kMaxNumLegacyRenderStreams 1 +#define kMaxNumDMusicRenderStreams 1 + +/***************************************************************************** + * MiniportPins + ***************************************************************************** + * List of pins. + */ +static +PCPIN_DESCRIPTOR MiniportPins[] = +{ + { + kMaxNumLegacyRenderStreams,kMaxNumLegacyRenderStreams,0, // InstanceCount + NULL, // AutomationTable + { // KsPinDescriptor + 0, // InterfacesCount + NULL, // Interfaces + 0, // MediumsCount + NULL, // Mediums + SIZEOF_ARRAY(PinDataRangePointersStreamLegacy), // DataRangesCount + PinDataRangePointersStreamLegacy, // DataRanges + KSPIN_DATAFLOW_IN, // DataFlow + KSPIN_COMMUNICATION_SINK, // Communication + (GUID *) &KSCATEGORY_AUDIO, // Category + &KSAUDFNAME_MIDI, // Name + {0} // Reserved + } + }, + { + kMaxNumDMusicRenderStreams,kMaxNumDMusicRenderStreams,0, // InstanceCount + NULL, // AutomationTable + { // KsPinDescriptor + 0, // InterfacesCount + NULL, // Interfaces + 0, // MediumsCount + NULL, // Mediums + SIZEOF_ARRAY(PinDataRangePointersStreamDMusic), // DataRangesCount + PinDataRangePointersStreamDMusic, // DataRanges + KSPIN_DATAFLOW_IN, // DataFlow + KSPIN_COMMUNICATION_SINK, // Communication + (GUID *) &KSCATEGORY_AUDIO, // Category + &KSAUDFNAME_DMUSIC_MPU_OUT, // Name + {0} // Reserved + } + }, + { + 0,0,0, // InstanceCount + NULL, // AutomationTable + { // KsPinDescriptor + 0, // InterfacesCount + NULL, // Interfaces + 0, // MediumsCount + NULL, // Mediums + SIZEOF_ARRAY(PinDataRangePointersBridge), // DataRangesCount + PinDataRangePointersBridge, // DataRanges + KSPIN_DATAFLOW_OUT, // DataFlow + KSPIN_COMMUNICATION_NONE, // Communication + (GUID *) &KSCATEGORY_AUDIO, // Category + NULL, // Name + {0} // Reserved + } + }, + { + 0,0,0, // InstanceCount + NULL, // AutomationTable + { // KsPinDescriptor + 0, // InterfacesCount + NULL, // Interfaces + 0, // MediumsCount + NULL, // Mediums + SIZEOF_ARRAY(PinDataRangePointersBridge), // DataRangesCount + PinDataRangePointersBridge, // DataRanges + KSPIN_DATAFLOW_IN, // DataFlow + KSPIN_COMMUNICATION_NONE, // Communication + (GUID *) &KSCATEGORY_AUDIO, // Category + NULL, // Name + {0} // Reserved + } + }, + { + kMaxNumCaptureStreams,kMaxNumCaptureStreams,0, // InstanceCount + NULL, // AutomationTable + { // KsPinDescriptor + 0, // InterfacesCount + NULL, // Interfaces + 0, // MediumsCount + NULL, // Mediums + SIZEOF_ARRAY(PinDataRangePointersStreamCombined), // DataRangesCount + PinDataRangePointersStreamCombined, // DataRanges + KSPIN_DATAFLOW_OUT, // DataFlow + KSPIN_COMMUNICATION_SINK, // Communication + (GUID *) &KSCATEGORY_AUDIO, // Category + &KSAUDFNAME_DMUSIC_MPU_IN, // Name + {0} // Reserved + } + } +}; + +/***************************************************************************** + * MiniportNodes + ***************************************************************************** + * List of nodes. + */ +#define CONST_PCNODE_DESCRIPTOR(n) { 0, NULL, &n, NULL } +#define CONST_PCNODE_DESCRIPTOR_AUTO(n,a) { 0, &a, &n, NULL } +static +PCNODE_DESCRIPTOR MiniportNodes[] = +{ + CONST_PCNODE_DESCRIPTOR_AUTO(KSNODETYPE_SYNTHESIZER, AutomationSynth) + , CONST_PCNODE_DESCRIPTOR_AUTO(KSNODETYPE_SYNTHESIZER, AutomationSynth2) +}; + +/***************************************************************************** + * MiniportConnections + ***************************************************************************** + * List of connections. + */ +enum { + eSynthNode = 0 + , eInputNode +}; + +enum { + eFilterInputPinLeg = 0, + eFilterInputPinDM, + eBridgeOutputPin, + eBridgeInputPin, + eFilterOutputPin +}; + +static +PCCONNECTION_DESCRIPTOR MiniportConnections[] = +{ // From To + // Node pin Node pin + { PCFILTER_NODE, eFilterInputPinLeg, PCFILTER_NODE, eBridgeOutputPin } // Legacy Stream in to synth. + , { PCFILTER_NODE, eFilterInputPinDM, eSynthNode, KSNODEPIN_STANDARD_IN } // DM Stream in to synth. + , { eSynthNode, KSNODEPIN_STANDARD_OUT, PCFILTER_NODE, eBridgeOutputPin } // Synth to bridge out. + , { PCFILTER_NODE, eBridgeInputPin, eInputNode, KSNODEPIN_STANDARD_IN } // Bridge in to input. + , { eInputNode, KSNODEPIN_STANDARD_OUT, PCFILTER_NODE, eFilterOutputPin } // Input to DM/Legacy Stream out. +}; + +/***************************************************************************** + * MiniportCategories + ***************************************************************************** + * List of categories. + */ +static +GUID MiniportCategories[] = +{ + {STATICGUIDOF(KSCATEGORY_AUDIO)}, + {STATICGUIDOF(KSCATEGORY_RENDER)}, + {STATICGUIDOF(KSCATEGORY_CAPTURE)} +}; + +/***************************************************************************** + * MiniportFilterDescriptor + ***************************************************************************** + * Complete miniport filter description. + */ +static +PCFILTER_DESCRIPTOR MiniportFilterDescriptor = +{ + 0, // Version + NULL, // AutomationTable + sizeof(PCPIN_DESCRIPTOR), // PinSize + SIZEOF_ARRAY(MiniportPins), // PinCount + MiniportPins, // Pins + sizeof(PCNODE_DESCRIPTOR), // NodeSize + SIZEOF_ARRAY(MiniportNodes), // NodeCount + MiniportNodes, // Nodes + SIZEOF_ARRAY(MiniportConnections), // ConnectionCount + MiniportConnections, // Connections + SIZEOF_ARRAY(MiniportCategories), // CategoryCount + MiniportCategories // Categories +}; + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +BOOLEAN TryMPU(IN PUCHAR PortBase); +NTSTATUS WriteMPU(IN PUCHAR PortBase,IN BOOLEAN IsCommand,IN UCHAR Value); + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +// make sure we're in UART mode +NTSTATUS ResetHardware(PUCHAR portBase) +{ + PAGED_CODE(); + + return WriteMPU(portBase,COMMAND,MPU401_CMD_UART); +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +// +// We initialize the UART with interrupts suppressed so we don't +// try to service the chip prematurely. +// +NTSTATUS CMiniportDMusUART::InitializeHardware(PINTERRUPTSYNC interruptSync,PUCHAR portBase) +{ + PAGED_CODE(); + + NTSTATUS ntStatus; + if (m_UseIRQ) + { + ntStatus = interruptSync->CallSynchronizedRoutine(InitMPU,PVOID(portBase)); + } + else + { + ntStatus = InitMPU(NULL,PVOID(portBase)); + } + + if (NT_SUCCESS(ntStatus)) + { + // + // Start the UART (this should trigger an interrupt). + // + ntStatus = ResetHardware(portBase); + } + else + { + DPRINT("*** InitMPU returned with ntStatus 0x%08x ***", ntStatus); + } + + m_fMPUInitialized = NT_SUCCESS(ntStatus); + + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * InitMPU() + ***************************************************************************** + * Synchronized routine to initialize the MPU401. + */ NTSTATUS -NTAPI -CMiniportDMus::QueryInterface( - IN REFIID refiid, - OUT PVOID* Output) -{ - if (IsEqualGUIDAligned(refiid, IID_IMiniportDMus)) - { - *Output = PVOID(PUNKNOWN(this)); - PUNKNOWN(*Output)->AddRef(); - return STATUS_SUCCESS; - } - return STATUS_UNSUCCESSFUL; -} - -// IMiniport methods - +InitMPU +( + IN PINTERRUPTSYNC InterruptSync, + IN PVOID DynamicContext +) +{ + DPRINT("InitMPU"); + if (!DynamicContext) + { + return STATUS_INVALID_PARAMETER_2; + } + + PUCHAR portBase = PUCHAR(DynamicContext); + UCHAR status; + ULONGLONG startTime; + BOOLEAN success; + NTSTATUS ntStatus = STATUS_SUCCESS; + + // + // Reset the card (puts it into "smart mode") + // + ntStatus = WriteMPU(portBase,COMMAND,MPU401_CMD_RESET); + + // wait for the acknowledgement + // NOTE: When the Ack arrives, it will trigger an interrupt. + // Normally the DPC routine would read in the ack byte and we + // would never see it, however since we have the hardware locked (HwEnter), + // we can read the port before the DPC can and thus we receive the Ack. + startTime = PcGetTimeInterval(0); + success = FALSE; + while(PcGetTimeInterval(startTime) < GTI_MILLISECONDS(50)) + { + status = READ_PORT_UCHAR(portBase + MPU401_REG_STATUS); + + if (UartFifoOkForRead(status)) // Is data waiting? + { + READ_PORT_UCHAR(portBase + MPU401_REG_DATA); // yep.. read ACK + success = TRUE; // don't need to do more + break; + } + KeStallExecutionProcessor(25); // microseconds + } +#if (DBG) + if (!success) + { + DPRINT("First attempt to reset the MPU didn't get ACKed.\n"); + } +#endif // (DBG) + + // NOTE: We cannot check the ACK byte because if the card was already in + // UART mode it will not send an ACK but it will reset. + + // reset the card again + (void) WriteMPU(portBase,COMMAND,MPU401_CMD_RESET); + + // wait for ack (again) + startTime = PcGetTimeInterval(0); // This might take a while + BYTE dataByte = 0; + success = FALSE; + while (PcGetTimeInterval(startTime) < GTI_MILLISECONDS(50)) + { + status = READ_PORT_UCHAR(portBase + MPU401_REG_STATUS); + if (UartFifoOkForRead(status)) // Is data waiting? + { + dataByte = READ_PORT_UCHAR(portBase + MPU401_REG_DATA); // yep.. read ACK + success = TRUE; // don't need to do more + break; + } + KeStallExecutionProcessor(25); + } + + if ((0xFE != dataByte) || !success) // Did we succeed? If no second ACK, something is hosed + { + DPRINT("Second attempt to reset the MPU didn't get ACKed.\n"); + DPRINT("Init Reset failure error. Ack = %X", ULONG(dataByte)); + + ntStatus = STATUS_IO_DEVICE_ERROR; + } + + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * CMiniportDMusUARTStream::Write() + ***************************************************************************** + * Writes outgoing MIDI data. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUARTStream:: +Write +( + IN PVOID BufferAddress, + IN ULONG Length, + OUT PULONG BytesWritten +) +{ + DPRINT("Write\n"); + ASSERT(BytesWritten); + if (!BufferAddress) + { + Length = 0; + } + + NTSTATUS ntStatus = STATUS_SUCCESS; + + if (!m_fCapture) + { + PUCHAR pMidiData; + ULONG count; + + count = 0; + pMidiData = PUCHAR(BufferAddress); + + if (Length) + { + SYNCWRITECONTEXT context; + context.Miniport = (m_pMiniport); + context.PortBase = m_pPortBase; + context.BufferAddress = pMidiData; + context.Length = Length; + context.BytesRead = &count; + + if (m_pMiniport->m_UseIRQ) + { + ntStatus = m_pMiniport->m_pInterruptSync-> + CallSynchronizedRoutine(SynchronizedDMusMPUWrite,PVOID(&context)); + } + else // !m_UseIRQ + { + ntStatus = SynchronizedDMusMPUWrite(NULL,PVOID(&context)); + } // !m_UseIRQ + + if (count == 0) + { + m_NumFailedMPUTries++; + if (m_NumFailedMPUTries >= 100) + { + ntStatus = STATUS_IO_DEVICE_ERROR; + m_NumFailedMPUTries = 0; + } + } + else + { + m_NumFailedMPUTries = 0; + } + } // if we have data at all + *BytesWritten = count; + } + else // called write on the read stream + { + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * SynchronizedDMusMPUWrite() + ***************************************************************************** + * Writes outgoing MIDI data. + */ NTSTATUS -NTAPI -CMiniportDMus::DataRangeIntersection( - IN ULONG PinId, - IN PKSDATARANGE DataRange, - IN PKSDATARANGE MatchingDataRange, - IN ULONG OutputBufferLength, - OUT PVOID ResultantFormat OPTIONAL, - OUT PULONG ResultantFormatLength) -{ - return STATUS_UNSUCCESSFUL; -} - +SynchronizedDMusMPUWrite +( + IN PINTERRUPTSYNC InterruptSync, + IN PVOID syncWriteContext +) +{ + PSYNCWRITECONTEXT context; + context = (PSYNCWRITECONTEXT)syncWriteContext; + ASSERT(context->Miniport); + ASSERT(context->PortBase); + ASSERT(context->BufferAddress); + ASSERT(context->Length); + ASSERT(context->BytesRead); + + PUCHAR pChar = PUCHAR(context->BufferAddress); + NTSTATUS ntStatus,readStatus; + ntStatus = STATUS_SUCCESS; + // + // while we're not there yet, and + // while we don't have to wait on an aligned byte (including 0) + // (we never wait on a byte. Better to come back later) + readStatus = DMusMPUInterruptServiceRoutine(InterruptSync,PVOID(context->Miniport)); + while ( (*(context->BytesRead) < context->Length) + && ( TryMPU(context->PortBase) + || (*(context->BytesRead)%3) + ) ) + { + ntStatus = WriteMPU(context->PortBase,DATA,*pChar); + if (NT_SUCCESS(ntStatus)) + { + pChar++; + *(context->BytesRead) = *(context->BytesRead) + 1; +// readStatus = DMusMPUInterruptServiceRoutine(InterruptSync,PVOID(context->Miniport)); + } + else + { + DPRINT("SynchronizedDMusMPUWrite failed (0x%08x)",ntStatus); + break; + } + } + readStatus = DMusMPUInterruptServiceRoutine(InterruptSync,PVOID(context->Miniport)); + return ntStatus; +} + +#define kMPUPollTimeout 2 + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * TryMPU() + ***************************************************************************** + * See if the MPU401 is free. + */ +BOOLEAN +TryMPU +( + IN PUCHAR PortBase +) +{ + BOOLEAN success; + USHORT numPolls; + UCHAR status; + + DPRINT("TryMPU"); + numPolls = 0; + + while (numPolls < kMPUPollTimeout) + { + status = READ_PORT_UCHAR(PortBase + MPU401_REG_STATUS); + + if (UartFifoOkForWrite(status)) // Is this a good time to write data? + { + break; + } + numPolls++; + } + if (numPolls >= kMPUPollTimeout) + { + success = FALSE; + DPRINT("TryMPU failed"); + } + else + { + success = TRUE; + } + + return success; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * WriteMPU() + ***************************************************************************** + * Write a byte out to the MPU401. + */ NTSTATUS -NTAPI -CMiniportDMus::GetDescription( - OUT PPCFILTER_DESCRIPTOR *Description) -{ - return STATUS_UNSUCCESSFUL; -} - -HRESULT -NTAPI -CMiniportDMus::Init( - IN PUNKNOWN pUnknownAdapter, - IN PRESOURCELIST pResourceList, - IN PPORTDMUS pPort, - OUT PSERVICEGROUP *ppServiceGroup - ) -{ - return STATUS_UNSUCCESSFUL; -} - -HRESULT -NTAPI -CMiniportDMus::NewStream( - OUT PMXF *ppMXF, - IN PUNKNOWN pOuterUnknown OPTIONAL, - IN POOL_TYPE PoolType, - IN ULONG uPinId, - IN DMUS_STREAM_TYPE StreamType, - IN PKSDATAFORMAT pDataFormat, - OUT PSERVICEGROUP *ppServiceGroup, - IN PAllocatorMXF pAllocatorMXF, - IN PMASTERCLOCK pMasterClock, - OUT PULONGLONG puuSchedulePreFetch - ) -{ - return STATUS_UNSUCCESSFUL; -} - -VOID -NTAPI -CMiniportDMus::Service() -{ - -} +WriteMPU +( + IN PUCHAR PortBase, + IN BOOLEAN IsCommand, + IN UCHAR Value +) +{ + DPRINT("WriteMPU"); + NTSTATUS ntStatus = STATUS_IO_DEVICE_ERROR; + + if (!PortBase) + { + DPRINT("O: PortBase is zero\n"); + return ntStatus; + } + PUCHAR deviceAddr = PortBase + MPU401_REG_DATA; + + if (IsCommand) + { + deviceAddr = PortBase + MPU401_REG_COMMAND; + } + + ULONGLONG startTime = PcGetTimeInterval(0); + + while (PcGetTimeInterval(startTime) < GTI_MILLISECONDS(50)) + { + UCHAR status + = READ_PORT_UCHAR(PortBase + MPU401_REG_STATUS); + + if (UartFifoOkForWrite(status)) // Is this a good time to write data? + { // yep (Jon comment) + WRITE_PORT_UCHAR(deviceAddr,Value); + DPRINT("WriteMPU emitted 0x%02x",Value); + ntStatus = STATUS_SUCCESS; + break; + } + } + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * SnapTimeStamp() + ***************************************************************************** + * + * At synchronized execution to ISR, copy miniport's volatile m_InputTimeStamp + * to stream's m_SnapshotTimeStamp and zero m_InputTimeStamp. + * + */ +STDMETHODIMP_(NTSTATUS) +SnapTimeStamp(PINTERRUPTSYNC InterruptSync,PVOID pStream) +{ + CMiniportDMusUARTStream *pMPStream = (CMiniportDMusUARTStream *)pStream; + + // cache the timestamp + pMPStream->m_SnapshotTimeStamp = pMPStream->m_pMiniport->m_InputTimeStamp; + + // if the window is closed, zero the timestamp + if (pMPStream->m_pMiniport->m_MPUInputBufferHead == + pMPStream->m_pMiniport->m_MPUInputBufferTail) + { + pMPStream->m_pMiniport->m_InputTimeStamp = 0; + } + + return STATUS_SUCCESS; +} + +/***************************************************************************** + * CMiniportDMusUARTStream::SourceEvtsToPort() + ***************************************************************************** + * + * Reads incoming MIDI data, feeds into DMus events. + * No need to touch the hardware, just read from our SW FIFO. + * + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUARTStream::SourceEvtsToPort() +{ + NTSTATUS ntStatus; + + ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL); + DPRINT("SourceEvtsToPort"); + + if (m_fCapture) + { + ntStatus = STATUS_SUCCESS; + if (m_pMiniport->m_MPUInputBufferHead != m_pMiniport->m_MPUInputBufferTail) + { + PDMUS_KERNEL_EVENT aDMKEvt,eventTail,eventHead = NULL; + + while (m_pMiniport->m_MPUInputBufferHead != m_pMiniport->m_MPUInputBufferTail) + { + (void) m_AllocatorMXF->GetMessage(&aDMKEvt); + if (!aDMKEvt) + { + DPRINT("SourceEvtsToPort can't allocate DMKEvt"); + return STATUS_INSUFFICIENT_RESOURCES; + } + + // put this event at the end of the list + if (!eventHead) + { + eventHead = aDMKEvt; + } + else + { + eventTail = eventHead; + while (eventTail->pNextEvt) + { + eventTail = eventTail->pNextEvt; + } + eventTail->pNextEvt = aDMKEvt; + } + // read all the bytes out of the buffer, into event(s) + for (aDMKEvt->cbEvent = 0; aDMKEvt->cbEvent < sizeof(PBYTE); aDMKEvt->cbEvent++) + { + if (m_pMiniport->m_MPUInputBufferHead == m_pMiniport->m_MPUInputBufferTail) + { +// _DbgPrintF(DEBUGLVL_TERSE, ("SourceEvtsToPort m_MPUInputBufferHead met m_MPUInputBufferTail, overrun")); + break; + } + aDMKEvt->uData.abData[aDMKEvt->cbEvent] = m_pMiniport->m_MPUInputBuffer[m_pMiniport->m_MPUInputBufferHead]; + m_pMiniport->m_MPUInputBufferHead++; + if (m_pMiniport->m_MPUInputBufferHead >= kMPUInputBufferSize) + { + m_pMiniport->m_MPUInputBufferHead = 0; + } + } + } + + if (m_pMiniport->m_UseIRQ) + { + ntStatus = m_pMiniport->m_pInterruptSync->CallSynchronizedRoutine(SnapTimeStamp,PVOID(this)); + } + else // !m_UseIRQ + { + ntStatus = SnapTimeStamp(NULL,PVOID(this)); + } // !m_UseIRQ + aDMKEvt = eventHead; + while (aDMKEvt) + { + aDMKEvt->ullPresTime100ns = m_SnapshotTimeStamp; + aDMKEvt->usChannelGroup = 1; + aDMKEvt->usFlags = DMUS_KEF_EVENT_INCOMPLETE; + aDMKEvt = aDMKEvt->pNextEvt; + } + (void)m_sinkMXF->PutMessage(eventHead); + } + } + else // render stream + { + DPRINT("SourceEvtsToPort called on render stream"); + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * DMusMPUInterruptServiceRoutine() + ***************************************************************************** + * ISR. + */ +NTSTATUS +DMusMPUInterruptServiceRoutine +( + IN PINTERRUPTSYNC InterruptSync, + IN PVOID DynamicContext +) +{ + DPRINT("DMusMPUInterruptServiceRoutine"); + ULONGLONG startTime; + + ASSERT(DynamicContext); + + NTSTATUS ntStatus; + BOOL newBytesAvailable; + CMiniportDMusUART *that; + NTSTATUS clockStatus; + + that = (CMiniportDMusUART *) DynamicContext; + newBytesAvailable = FALSE; + ntStatus = STATUS_UNSUCCESSFUL; + + UCHAR portStatus = 0xff; + + // + // Read the MPU status byte. + // + if (that->m_pPortBase) + { + portStatus = + READ_PORT_UCHAR(that->m_pPortBase + MPU401_REG_STATUS); + + // + // If there is outstanding work to do and there is a port-driver for + // the MPU miniport... + // + if (UartFifoOkForRead(portStatus) && that->m_pPort) + { + startTime = PcGetTimeInterval(0); + while ( (PcGetTimeInterval(startTime) < GTI_MILLISECONDS(50)) + && (UartFifoOkForRead(portStatus)) ) + { + UCHAR uDest = READ_PORT_UCHAR(that->m_pPortBase + MPU401_REG_DATA); + if ( (that->m_KSStateInput == KSSTATE_RUN) + && (that->m_NumCaptureStreams) + ) + { + ULONG buffHead = that->m_MPUInputBufferHead; + if ( (that->m_MPUInputBufferTail + 1 == buffHead) + || (that->m_MPUInputBufferTail + 1 - kMPUInputBufferSize == buffHead)) + { + DPRINT("*****MPU Input Buffer Overflow*****"); + } + else + { + if (!that->m_InputTimeStamp) + { + clockStatus = that->m_MasterClock->GetTime(&that->m_InputTimeStamp); + if (STATUS_SUCCESS != clockStatus) + { + DPRINT("GetTime failed for clock 0x%08x",that->m_MasterClock); + } + } + newBytesAvailable = TRUE; + // ...place the data in our FIFO... + that->m_MPUInputBuffer[that->m_MPUInputBufferTail] = uDest; + ASSERT(that->m_MPUInputBufferTail < kMPUInputBufferSize); + + that->m_MPUInputBufferTail++; + if (that->m_MPUInputBufferTail >= kMPUInputBufferSize) + { + that->m_MPUInputBufferTail = 0; + } + } + } + // + // Look for more MIDI data. + // + portStatus = + READ_PORT_UCHAR(that->m_pPortBase + MPU401_REG_STATUS); + } // either there's no data or we ran too long + if (newBytesAvailable) + { + // + // ...notify the MPU port driver that we have bytes. + // + that->m_pPort->Notify(that->m_pServiceGroup); + } + ntStatus = STATUS_SUCCESS; + } + } + + return ntStatus; +} + +/***************************************************************************** + * CMiniportDMusUART::GetDescription() + ***************************************************************************** + * Gets the topology. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUART:: +GetDescription +( + OUT PPCFILTER_DESCRIPTOR * OutFilterDescriptor +) +{ + PAGED_CODE(); + + ASSERT(OutFilterDescriptor); + + DPRINT("GetDescription"); + + *OutFilterDescriptor = &MiniportFilterDescriptor; + + return STATUS_SUCCESS; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif NTSTATUS NewMiniportDMusUART( OUT PMINIPORT* OutMiniport, IN REFCLSID ClassId) { - CMiniportDMus * This; - - This = new(NonPagedPool, TAG_PORTCLASS)CMiniportDMus(NULL); + CMiniportDMusUART * This; + NTSTATUS Status; + + This= new(NonPagedPool, TAG_PORTCLASS) CMiniportDMusUART(NULL); if (!This) return STATUS_INSUFFICIENT_RESOURCES; - *OutMiniport = (PMINIPORT)This; - This->AddRef(); + Status = This->QueryInterface(IID_IMiniport, (PVOID*)OutMiniport); + + if (!NT_SUCCESS(Status)) + { + delete This; + } + + DPRINT("NewMiniportDMusUART %p Status %x\n", *OutMiniport, Status); + return Status; +} + + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +/***************************************************************************** + * CMiniportDMusUART::ProcessResources() + ***************************************************************************** + * Processes the resource list, setting up helper objects accordingly. + */ +NTSTATUS +CMiniportDMusUART:: +ProcessResources +( + IN PRESOURCELIST ResourceList +) +{ + PAGED_CODE(); + + DPRINT("ProcessResources"); + + ASSERT(ResourceList); + if (!ResourceList) + { + return STATUS_DEVICE_CONFIGURATION_ERROR; + } + // + // Get counts for the types of resources. + // + ULONG countIO = ResourceList->NumberOfPorts(); + ULONG countIRQ = ResourceList->NumberOfInterrupts(); + ULONG countDMA = ResourceList->NumberOfDmas(); + ULONG lengthIO = ResourceList->FindTranslatedPort(0)->u.Port.Length; + +#ifdef DBG + DPRINT("Starting MPU401 Port 0x%lx", ResourceList->FindTranslatedPort(0)->u.Port.Start.LowPart); +#endif + + NTSTATUS ntStatus = STATUS_SUCCESS; + + // + // Make sure we have the expected number of resources. + // + if ( (countIO != 1) + || (countIRQ > 1) + || (countDMA != 0) + || (lengthIO == 0) + ) + { + DPRINT("Unknown ResourceList configuraton"); + ntStatus = STATUS_DEVICE_CONFIGURATION_ERROR; + } + + if (NT_SUCCESS(ntStatus)) + { + // + // Get the port address. + // + m_pPortBase = + PUCHAR(ResourceList->FindTranslatedPort(0)->u.Port.Start.QuadPart); + + ntStatus = InitializeHardware(m_pInterruptSync,m_pPortBase); + } + + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUART::NonDelegatingQueryInterface() + ***************************************************************************** + * Obtains an interface. This function works just like a COM QueryInterface + * call and is used if the object is not being aggregated. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUART::QueryInterface +( + REFIID Interface, + PVOID * Object +) +{ + PAGED_CODE(); + + DPRINT("Miniport::NonDelegatingQueryInterface"); + ASSERT(Object); + + if (IsEqualGUIDAligned(Interface,IID_IUnknown)) + { + *Object = PVOID(PUNKNOWN(PMINIPORTDMUS(this))); + } + else + if (IsEqualGUIDAligned(Interface,IID_IMiniport)) + { + *Object = PVOID(PMINIPORT(this)); + } + else + if (IsEqualGUIDAligned(Interface,IID_IMiniportDMus)) + { + *Object = PVOID(PMINIPORTDMUS(this)); + } + else + if (IsEqualGUIDAligned(Interface,IID_IMusicTechnology)) + { + *Object = PVOID(PMUSICTECHNOLOGY(this)); + } + else + if (IsEqualGUIDAligned(Interface,IID_IPowerNotify)) + { + *Object = PVOID(PPOWERNOTIFY(this)); + } + else + { + *Object = NULL; + } + + if (*Object) + { + // + // We reference the interface for the caller. + // + PUNKNOWN(*Object)->AddRef(); + return STATUS_SUCCESS; + } + + return STATUS_INVALID_PARAMETER; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUART::~CMiniportDMusUART() + ***************************************************************************** + * Destructor. + */ +CMiniportDMusUART::~CMiniportDMusUART(void) +{ + PAGED_CODE(); + + DPRINT("~CMiniportDMusUART"); + + ASSERT(0 == m_NumCaptureStreams); + ASSERT(0 == m_NumRenderStreams); + + // reset the HW so we don't get anymore interrupts + if (m_UseIRQ && m_pInterruptSync) + { + (void) m_pInterruptSync->CallSynchronizedRoutine((PINTERRUPTSYNCROUTINE)InitMPU,PVOID(m_pPortBase)); + } + else + { + (void) InitMPU(NULL,PVOID(m_pPortBase)); + } + + if (m_pInterruptSync) + { + m_pInterruptSync->Release(); + m_pInterruptSync = NULL; + } + if (m_pServiceGroup) + { + m_pServiceGroup->Release(); + m_pServiceGroup = NULL; + } + if (m_pPort) + { + m_pPort->Release(); + m_pPort = NULL; + } +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUART::Init() + ***************************************************************************** + * Initializes a the miniport. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUART:: +Init +( + IN PUNKNOWN UnknownInterruptSync OPTIONAL, + IN PRESOURCELIST ResourceList, + IN PPORTDMUS Port_, + OUT PSERVICEGROUP * ServiceGroup +) +{ + PAGED_CODE(); + + ASSERT(ResourceList); + if (!ResourceList) + { + return STATUS_DEVICE_CONFIGURATION_ERROR; + } + + ASSERT(Port_); + ASSERT(ServiceGroup); + + DPRINT("Init"); + + *ServiceGroup = NULL; + m_pPortBase = 0; + m_fMPUInitialized = FALSE; + + // This will remain unspecified if the miniport does not get any power + // messages. + // + m_PowerState.DeviceState = PowerDeviceUnspecified; + + // + // AddRef() is required because we are keeping this pointer. + // + m_pPort = Port_; + m_pPort->AddRef(); + + // Set dataformat. + // + if (IsEqualGUIDAligned(m_MusicFormatTechnology, GUID_NULL)) + { + RtlCopyMemory( &m_MusicFormatTechnology, + &KSMUSIC_TECHNOLOGY_PORT, + sizeof(GUID)); + } + RtlCopyMemory( &PinDataRangesStreamLegacy.Technology, + &m_MusicFormatTechnology, + sizeof(GUID)); + RtlCopyMemory( &PinDataRangesStreamDMusic.Technology, + &m_MusicFormatTechnology, + sizeof(GUID)); + + for (ULONG bufferCount = 0;bufferCount < kMPUInputBufferSize;bufferCount++) + { + m_MPUInputBuffer[bufferCount] = 0; + } + m_MPUInputBufferHead = 0; + m_MPUInputBufferTail = 0; + m_InputTimeStamp = 0; + m_KSStateInput = KSSTATE_STOP; + + NTSTATUS ntStatus = STATUS_SUCCESS; + + m_NumRenderStreams = 0; + m_NumCaptureStreams = 0; + + m_UseIRQ = TRUE; + if (ResourceList->NumberOfInterrupts() == 0) + { + m_UseIRQ = FALSE; + } + + ntStatus = PcNewServiceGroup(&m_pServiceGroup,NULL); + if (NT_SUCCESS(ntStatus) && !m_pServiceGroup) // keep any error + { + ntStatus = STATUS_INSUFFICIENT_RESOURCES; + } + + if (NT_SUCCESS(ntStatus)) + { + *ServiceGroup = m_pServiceGroup; + m_pServiceGroup->AddRef(); + + // + // Register the service group with the port early so the port is + // prepared to handle interrupts. + // + m_pPort->RegisterServiceGroup(m_pServiceGroup); + } + + if (NT_SUCCESS(ntStatus) && m_UseIRQ) + { + // + // Due to a bug in the InterruptSync design, we shouldn't share + // the interrupt sync object. Whoever goes away first + // will disconnect it, and the other points off into nowhere. + // + // Instead we generate our own interrupt sync object. + // + UnknownInterruptSync = NULL; + + if (UnknownInterruptSync) + { + ntStatus = + UnknownInterruptSync->QueryInterface + ( + IID_IInterruptSync, + (PVOID *) &m_pInterruptSync + ); + + if (!m_pInterruptSync && NT_SUCCESS(ntStatus)) // keep any error + { + ntStatus = STATUS_INSUFFICIENT_RESOURCES; + } + if (NT_SUCCESS(ntStatus)) + { // run this ISR first + ntStatus = m_pInterruptSync-> + RegisterServiceRoutine(DMusMPUInterruptServiceRoutine,PVOID(this),TRUE); + } + + } + else + { // create our own interruptsync mechanism. + ntStatus = + PcNewInterruptSync + ( + &m_pInterruptSync, + NULL, + ResourceList, + 0, // Resource Index + InterruptSyncModeNormal // Run ISRs once until we get SUCCESS + ); + + if (!m_pInterruptSync && NT_SUCCESS(ntStatus)) // keep any error + { + ntStatus = STATUS_INSUFFICIENT_RESOURCES; + } + + if (NT_SUCCESS(ntStatus)) + { + ntStatus = m_pInterruptSync->RegisterServiceRoutine( + DMusMPUInterruptServiceRoutine, + PVOID(this), + TRUE); // run this ISR first + } + if (NT_SUCCESS(ntStatus)) + { + ntStatus = m_pInterruptSync->Connect(); + } + } + } + + if (NT_SUCCESS(ntStatus)) + { + ntStatus = ProcessResources(ResourceList); + } + + if (!NT_SUCCESS(ntStatus)) + { + // + // clean up our mess + // + + // clean up the interrupt sync + if( m_pInterruptSync ) + { + m_pInterruptSync->Release(); + m_pInterruptSync = NULL; + } + + // clean up the service group + if( m_pServiceGroup ) + { + m_pServiceGroup->Release(); + m_pServiceGroup = NULL; + } + + // clean up the out param service group. + if (*ServiceGroup) + { + (*ServiceGroup)->Release(); + (*ServiceGroup) = NULL; + } + + // release the port + m_pPort->Release(); + m_pPort = NULL; + } + + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUART::NewStream() + ***************************************************************************** + * Gets the topology. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUART:: +NewStream +( + OUT PMXF * MXF, + IN PUNKNOWN OuterUnknown OPTIONAL, + IN POOL_TYPE PoolType, + IN ULONG PinID, + IN DMUS_STREAM_TYPE StreamType, + IN PKSDATAFORMAT DataFormat, + OUT PSERVICEGROUP * ServiceGroup, + IN PAllocatorMXF AllocatorMXF, + IN PMASTERCLOCK MasterClock, + OUT PULONGLONG SchedulePreFetch +) +{ + PAGED_CODE(); + + DPRINT("NewStream"); + NTSTATUS ntStatus = STATUS_SUCCESS; + + // In 100 ns, we want stuff as soon as it comes in + // + *SchedulePreFetch = 0; + + // if we don't have any streams already open, get the hardware ready. + if ((!m_NumCaptureStreams) && (!m_NumRenderStreams)) + { + ntStatus = ResetHardware(m_pPortBase); + if (!NT_SUCCESS(ntStatus)) + { + DPRINT("CMiniportDMusUART::NewStream ResetHardware failed"); + return ntStatus; + } + } + + if ( ((m_NumCaptureStreams < kMaxNumCaptureStreams) + && (StreamType == DMUS_STREAM_MIDI_CAPTURE)) + || ((m_NumRenderStreams < kMaxNumLegacyRenderStreams + kMaxNumDMusicRenderStreams) + && (StreamType == DMUS_STREAM_MIDI_RENDER)) + ) + { + CMiniportDMusUARTStream *pStream = + new(PoolType) CMiniportDMusUARTStream(); + + if (pStream) + { + pStream->AddRef(); + + ntStatus = + pStream->Init(this,m_pPortBase,(StreamType == DMUS_STREAM_MIDI_CAPTURE),AllocatorMXF,MasterClock); + + if (NT_SUCCESS(ntStatus)) + { + *MXF = PMXF(pStream); + (*MXF)->AddRef(); + + if (StreamType == DMUS_STREAM_MIDI_CAPTURE) + { + m_NumCaptureStreams++; + *ServiceGroup = m_pServiceGroup; + (*ServiceGroup)->AddRef(); + } + else + { + m_NumRenderStreams++; + *ServiceGroup = NULL; + } + } + + pStream->Release(); + } + else + { + ntStatus = STATUS_INSUFFICIENT_RESOURCES; + } + } + else + { + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + if (StreamType == DMUS_STREAM_MIDI_CAPTURE) + { + DPRINT("NewStream failed, too many capture streams"); + } + else if (StreamType == DMUS_STREAM_MIDI_RENDER) + { + DPRINT("NewStream failed, too many render streams"); + } + else + { + DPRINT("NewStream invalid stream type"); + } + } + + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUART::SetTechnology() + ***************************************************************************** + * Sets pindatarange technology. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUART:: +SetTechnology +( + IN const GUID * Technology +) +{ + PAGED_CODE(); + + NTSTATUS ntStatus = STATUS_UNSUCCESSFUL; + + // Fail if miniport has already been initialized. + // + if (NULL == m_pPort) + { + RtlCopyMemory(&m_MusicFormatTechnology, Technology, sizeof(GUID)); + ntStatus = STATUS_SUCCESS; + } + + return ntStatus; +} // SetTechnology + +/***************************************************************************** + * CMiniportDMusUART::PowerChangeNotify() + ***************************************************************************** + * Handle power state change for the miniport. + */ +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +STDMETHODIMP_(void) +CMiniportDMusUART:: +PowerChangeNotify +( + IN POWER_STATE PowerState +) +{ + PAGED_CODE(); + + DPRINT("CMiniportDMusUART::PoweChangeNotify D%d", PowerState.DeviceState); + + switch (PowerState.DeviceState) + { + case PowerDeviceD0: + if (m_PowerState.DeviceState != PowerDeviceD0) + { + if (!NT_SUCCESS(InitializeHardware(m_pInterruptSync,m_pPortBase))) + { + DPRINT("InitializeHardware failed when resuming"); + } + } + break; + + case PowerDeviceD1: + case PowerDeviceD2: + case PowerDeviceD3: + default: + break; + } + m_PowerState.DeviceState = PowerState.DeviceState; +} // PowerChangeNotify + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUARTStream::NonDelegatingQueryInterface() + ***************************************************************************** + * Obtains an interface. This function works just like a COM QueryInterface + * call and is used if the object is not being aggregated. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUARTStream::QueryInterface +( + REFIID Interface, + PVOID * Object +) +{ + PAGED_CODE(); + + DPRINT("Stream::NonDelegatingQueryInterface"); + ASSERT(Object); + + if (IsEqualGUIDAligned(Interface,IID_IUnknown)) + { + *Object = PVOID(PUNKNOWN(this)); + } + else + if (IsEqualGUIDAligned(Interface,IID_IMXF)) + { + *Object = PVOID(PMXF(this)); + } + else + { + *Object = NULL; + } + + if (*Object) + { + // + // We reference the interface for the caller. + // + PUNKNOWN(*Object)->AddRef(); + return STATUS_SUCCESS; + } + + return STATUS_INVALID_PARAMETER; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUARTStream::~CMiniportDMusUARTStream() + ***************************************************************************** + * Destructs a stream. + */ +CMiniportDMusUARTStream::~CMiniportDMusUARTStream(void) +{ + PAGED_CODE(); + + DPRINT("~CMiniportDMusUARTStream"); + + KeCancelTimer(&m_TimerEvent); + + if (m_DMKEvtQueue) + { + if (m_AllocatorMXF) + { + m_AllocatorMXF->PutMessage(m_DMKEvtQueue); + } + else + { + DPRINT("~CMiniportDMusUARTStream, no allocator, can't flush DMKEvts"); + } + m_DMKEvtQueue = NULL; + } + if (m_AllocatorMXF) + { + m_AllocatorMXF->Release(); + m_AllocatorMXF = NULL; + } + + if (m_pMiniport) + { + if (m_fCapture) + { + m_pMiniport->m_NumCaptureStreams--; + } + else + { + m_pMiniport->m_NumRenderStreams--; + } + + m_pMiniport->Release(); + } +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUARTStream::Init() + ***************************************************************************** + * Initializes a stream. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUARTStream:: +Init +( + IN CMiniportDMusUART * pMiniport, + IN PUCHAR pPortBase, + IN BOOLEAN fCapture, + IN PAllocatorMXF allocatorMXF, + IN PMASTERCLOCK masterClock +) +{ + PAGED_CODE(); + + ASSERT(pMiniport); + ASSERT(pPortBase); + + DPRINT("Init"); + + m_NumFailedMPUTries = 0; + m_TimerQueued = FALSE; + KeInitializeSpinLock(&m_DpcSpinLock); + m_pMiniport = pMiniport; + m_pMiniport->AddRef(); + + pMiniport->m_MasterClock = masterClock; + + m_pPortBase = pPortBase; + m_fCapture = fCapture; + + m_SnapshotTimeStamp = 0; + m_DMKEvtQueue = NULL; + m_DMKEvtOffset = 0; + + m_NumberOfRetries = 0; + + if (allocatorMXF) + { + allocatorMXF->AddRef(); + m_AllocatorMXF = allocatorMXF; + m_sinkMXF = m_AllocatorMXF; + } + else + { + return STATUS_INVALID_PARAMETER; + } + + KeInitializeDpc + ( + &m_Dpc, + &::DMusUARTTimerDPC, + PVOID(this) + ); + KeInitializeTimer(&m_TimerEvent); return STATUS_SUCCESS; } - +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif +/***************************************************************************** + * CMiniportDMusUARTStream::SetState() + ***************************************************************************** + * Sets the state of the channel. + */ +STDMETHODIMP_(NTSTATUS) +CMiniportDMusUARTStream:: +SetState +( + IN KSSTATE NewState +) +{ + PAGED_CODE(); + + DPRINT("SetState %d",NewState); + + if (NewState == KSSTATE_RUN) + { + if (m_pMiniport->m_fMPUInitialized) + { + LARGE_INTEGER timeDue100ns; + timeDue100ns.QuadPart = 0; + KeSetTimer(&m_TimerEvent,timeDue100ns,&m_Dpc); + } + else + { + DPRINT("CMiniportDMusUARTStream::SetState KSSTATE_RUN failed due to uninitialized MPU"); + return STATUS_INVALID_DEVICE_STATE; + } + } + + if (m_fCapture) + { + m_pMiniport->m_KSStateInput = NewState; + if (NewState == KSSTATE_STOP) // STOPping + { + m_pMiniport->m_MPUInputBufferHead = 0; // Previously read bytes are discarded. + m_pMiniport->m_MPUInputBufferTail = 0; // The entire FIFO is available. + } + } + return STATUS_SUCCESS; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + + +/***************************************************************************** + * CMiniportDMusUART::Service() + ***************************************************************************** + * DPC-mode service call from the port. + */ +STDMETHODIMP_(void) +CMiniportDMusUART:: +Service +( void +) +{ + DPRINT("Service"); + if (!m_NumCaptureStreams) + { + // we should never get here.... + // if we do, we must have read some trash, + // so just reset the input FIFO + m_MPUInputBufferTail = m_MPUInputBufferHead = 0; + } +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +/***************************************************************************** + * CMiniportDMusUARTStream::ConnectOutput() + ***************************************************************************** + * Writes outgoing MIDI data. + */ +NTSTATUS +CMiniportDMusUARTStream:: +ConnectOutput(PMXF sinkMXF) +{ + PAGED_CODE(); + + if (m_fCapture) + { + if ((sinkMXF) && (m_sinkMXF == m_AllocatorMXF)) + { + DPRINT("ConnectOutput"); + m_sinkMXF = sinkMXF; + return STATUS_SUCCESS; + } + else + { + DPRINT("ConnectOutput failed"); + } + } + else + { + DPRINT("ConnectOutput called on renderer; failed"); + } + return STATUS_UNSUCCESSFUL; +} + +#ifdef _MSC_VER +#pragma code_seg("PAGE") +#endif + +/***************************************************************************** + * CMiniportDMusUARTStream::DisconnectOutput() + ***************************************************************************** + * Writes outgoing MIDI data. + */ +NTSTATUS +CMiniportDMusUARTStream:: +DisconnectOutput(PMXF sinkMXF) +{ + PAGED_CODE(); + + if (m_fCapture) + { + if ((m_sinkMXF == sinkMXF) || (!sinkMXF)) + { + DPRINT("DisconnectOutput"); + m_sinkMXF = m_AllocatorMXF; + return STATUS_SUCCESS; + } + else + { + DPRINT("DisconnectOutput failed"); + } + } + else + { + DPRINT("DisconnectOutput called on renderer; failed"); + } + return STATUS_UNSUCCESSFUL; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + + +/***************************************************************************** + * CMiniportDMusUARTStream::PutMessageLocked() + ***************************************************************************** + * Now that the spinlock is held, add this message to the queue. + * + * Writes an outgoing MIDI message. + * We don't sort a new message into the queue -- we append it. + * This is fine, since the sequencer feeds us sequenced data. + * Timestamps will ascend by design. + */ +NTSTATUS CMiniportDMusUARTStream::PutMessageLocked(PDMUS_KERNEL_EVENT pDMKEvt) +{ + NTSTATUS ntStatus = STATUS_SUCCESS; + PDMUS_KERNEL_EVENT aDMKEvt; + + ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL); + + if (!m_fCapture) + { + DPRINT("PutMessage to render stream"); + if (pDMKEvt) + { + // m_DpcSpinLock already held + + if (m_DMKEvtQueue) + { + aDMKEvt = m_DMKEvtQueue; // put pDMKEvt in event queue + + while (aDMKEvt->pNextEvt) + { + aDMKEvt = aDMKEvt->pNextEvt; + } + aDMKEvt->pNextEvt = pDMKEvt; // here is end of queue + } + else // currently nothing in queue + { + m_DMKEvtQueue = pDMKEvt; + if (m_DMKEvtOffset) + { + DPRINT("PutMessage Nothing in the queue, but m_DMKEvtOffset == %d",m_DMKEvtOffset); + m_DMKEvtOffset = 0; + } + } + + // m_DpcSpinLock already held + } + if (!m_TimerQueued) + { + (void) ConsumeEvents(); + } + } + else // capture + { + DPRINT("PutMessage to capture stream"); + ASSERT(NULL == pDMKEvt); + + SourceEvtsToPort(); + } + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * CMiniportDMusUARTStream::PutMessage() + ***************************************************************************** + * Writes an outgoing MIDI message. + * We don't sort a new message into the queue -- we append it. + * This is fine, since the sequencer feeds us sequenced data. + * Timestamps will ascend by design. + */ +NTSTATUS CMiniportDMusUARTStream::PutMessage(PDMUS_KERNEL_EVENT pDMKEvt) +{ + NTSTATUS ntStatus = STATUS_SUCCESS; + PDMUS_KERNEL_EVENT aDMKEvt; + + ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL); + + if (!m_fCapture) + { + DPRINT("PutMessage to render stream"); + if (pDMKEvt) + { + KeAcquireSpinLockAtDpcLevel(&m_DpcSpinLock); + + if (m_DMKEvtQueue) + { + aDMKEvt = m_DMKEvtQueue; // put pDMKEvt in event queue + + while (aDMKEvt->pNextEvt) + { + aDMKEvt = aDMKEvt->pNextEvt; + } + aDMKEvt->pNextEvt = pDMKEvt; // here is end of queue + } + else // currently nothing in queue + { + m_DMKEvtQueue = pDMKEvt; + if (m_DMKEvtOffset) + { + DPRINT("PutMessage Nothing in the queue, but m_DMKEvtOffset == %d", m_DMKEvtOffset); + m_DMKEvtOffset = 0; + } + } + + KeReleaseSpinLockFromDpcLevel(&m_DpcSpinLock); + } + if (!m_TimerQueued) + { + (void) ConsumeEvents(); + } + } + else // capture + { + DPRINT("PutMessage to capture stream"); + ASSERT(NULL == pDMKEvt); + + SourceEvtsToPort(); + } + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * CMiniportDMusUARTStream::ConsumeEvents() + ***************************************************************************** + * Attempts to empty the render message queue. + * Called either from DPC timer or upon IRP submittal. +// TODO: support packages right +// process the package (actually, should do this above. +// treat the package as a list fragment that shouldn't be sorted. +// better yet, go through each event in the package, and when +// an event is exhausted, delete it and decrement m_offset. + */ +NTSTATUS CMiniportDMusUARTStream::ConsumeEvents(void) +{ + PDMUS_KERNEL_EVENT aDMKEvt; + + NTSTATUS ntStatus = STATUS_SUCCESS; + ULONG bytesRemaining = 0,bytesWritten = 0; + LARGE_INTEGER aMillisecIn100ns; + + ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL); + KeAcquireSpinLockAtDpcLevel(&m_DpcSpinLock); + + m_TimerQueued = FALSE; + while (m_DMKEvtQueue) // do we have anything to play at all? + { + aDMKEvt = m_DMKEvtQueue; // event we try to play + if (aDMKEvt->cbEvent) + { + bytesRemaining = aDMKEvt->cbEvent - m_DMKEvtOffset; // number of bytes left in this evt + + ASSERT(bytesRemaining > 0); + if (bytesRemaining <= 0) + { + bytesRemaining = aDMKEvt->cbEvent; + } + + if (aDMKEvt->cbEvent <= sizeof(PBYTE)) // short message + { + DPRINT("ConsumeEvents(%02x%02x%02x%02x)", aDMKEvt->uData.abData[0], aDMKEvt->uData.abData[1], aDMKEvt->uData.abData[2], aDMKEvt->uData.abData[3]); + ntStatus = Write(aDMKEvt->uData.abData + m_DMKEvtOffset,bytesRemaining,&bytesWritten); + } + else if (PACKAGE_EVT(aDMKEvt)) + { + ASSERT(m_DMKEvtOffset == 0); + m_DMKEvtOffset = 0; + DPRINT("ConsumeEvents(Package)"); + + ntStatus = PutMessageLocked(aDMKEvt->uData.pPackageEvt); // we already own the spinlock + + // null this because we are about to throw it in the allocator + aDMKEvt->uData.pPackageEvt = NULL; + aDMKEvt->cbEvent = 0; + bytesWritten = bytesRemaining; + } + else // SysEx message + { + DPRINT("ConsumeEvents(%02x%02x%02x%02x)", aDMKEvt->uData.pbData[0], aDMKEvt->uData.pbData[1], aDMKEvt->uData.pbData[2], aDMKEvt->uData.pbData[3]); + + ntStatus = Write(aDMKEvt->uData.pbData + m_DMKEvtOffset,bytesRemaining,&bytesWritten); + } + } // if (aDMKEvt->cbEvent) + if (STATUS_SUCCESS != ntStatus) + { + DPRINT("ConsumeEvents: Write returned 0x%08x", ntStatus); + bytesWritten = bytesRemaining; // just bail on this event and try next time + } + + ASSERT(bytesWritten <= bytesRemaining); + if (bytesWritten == bytesRemaining) + { + m_DMKEvtQueue = m_DMKEvtQueue->pNextEvt; + aDMKEvt->pNextEvt = NULL; + + m_AllocatorMXF->PutMessage(aDMKEvt); // throw back in free pool + m_DMKEvtOffset = 0; // start fresh on next evt + m_NumberOfRetries = 0; + } // but wait ... there's more! + else // our FIFO is full for now. + { + // update our offset by that amount we did write + m_DMKEvtOffset += bytesWritten; + ASSERT(m_DMKEvtOffset < aDMKEvt->cbEvent); + + DPRINT("ConsumeEvents tried %d, wrote %d, at offset %d", bytesRemaining,bytesWritten,m_DMKEvtOffset); + aMillisecIn100ns.QuadPart = -(kOneMillisec); // set timer, come back later + m_TimerQueued = TRUE; + m_NumberOfRetries++; + ntStatus = KeSetTimer( &m_TimerEvent, aMillisecIn100ns, &m_Dpc ); + break; + } // we didn't write it all + } // go back, Jack, do it again (while m_DMKEvtQueue) + KeReleaseSpinLockFromDpcLevel(&m_DpcSpinLock); + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * CMiniportDMusUARTStream::HandlePortParams() + ***************************************************************************** + * Writes an outgoing MIDI message. + */ +NTSTATUS +CMiniportDMusUARTStream:: +HandlePortParams +( + IN PPCPROPERTY_REQUEST pRequest +) +{ + PAGED_CODE(); + + NTSTATUS ntStatus; + + if (pRequest->Verb & KSPROPERTY_TYPE_SET) + { + return STATUS_INVALID_DEVICE_REQUEST; + } + + ntStatus = ValidatePropertyRequest(pRequest, sizeof(SYNTH_PORTPARAMS), TRUE); + if (NT_SUCCESS(ntStatus)) + { + RtlCopyMemory(pRequest->Value, pRequest->Instance, sizeof(SYNTH_PORTPARAMS)); + + PSYNTH_PORTPARAMS Params = (PSYNTH_PORTPARAMS)pRequest->Value; + + if (Params->ValidParams & ~SYNTH_PORTPARAMS_CHANNELGROUPS) + { + Params->ValidParams &= SYNTH_PORTPARAMS_CHANNELGROUPS; + } + + if (!(Params->ValidParams & SYNTH_PORTPARAMS_CHANNELGROUPS)) + { + Params->ChannelGroups = 1; + } + else if (Params->ChannelGroups != 1) + { + Params->ChannelGroups = 1; + } + + pRequest->ValueSize = sizeof(SYNTH_PORTPARAMS); + } + + return ntStatus; +} + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/***************************************************************************** + * DMusTimerDPC() + ***************************************************************************** + * The timer DPC callback. Thunks to a C++ member function. + * This is called by the OS in response to the DirectMusic pin + * wanting to wakeup later to process more DirectMusic stuff. + */ +VOID +NTAPI +DMusUARTTimerDPC +( + IN PKDPC Dpc, + IN PVOID DeferredContext, + IN PVOID SystemArgument1, + IN PVOID SystemArgument2 +) +{ + ASSERT(DeferredContext); + + CMiniportDMusUARTStream *aStream; + aStream = (CMiniportDMusUARTStream *) DeferredContext; + if (aStream) + { + DPRINT("DMusUARTTimerDPC"); + if (false == aStream->m_fCapture) + { + (void) aStream->ConsumeEvents(); + } + // ignores return value! + } +} + +/***************************************************************************** + * DirectMusic properties + ****************************************************************************/ + +#ifdef _MSC_VER +#pragma code_seg() +#endif + +/* + * Properties concerning synthesizer functions. + */ +const WCHAR wszDescOut[] = L"DMusic MPU-401 Out "; +const WCHAR wszDescIn[] = L"DMusic MPU-401 In "; + +NTSTATUS PropertyHandler_Synth +( + IN PPCPROPERTY_REQUEST pRequest +) +{ + NTSTATUS ntStatus; + + PAGED_CODE(); + + if (pRequest->Verb & KSPROPERTY_TYPE_BASICSUPPORT) + { + ntStatus = ValidatePropertyRequest(pRequest, sizeof(ULONG), TRUE); + if (NT_SUCCESS(ntStatus)) + { + // if return buffer can hold a ULONG, return the access flags + PULONG AccessFlags = PULONG(pRequest->Value); + + *AccessFlags = KSPROPERTY_TYPE_BASICSUPPORT; + switch (pRequest->PropertyItem->Id) + { + case KSPROPERTY_SYNTH_CAPS: + case KSPROPERTY_SYNTH_CHANNELGROUPS: + *AccessFlags |= KSPROPERTY_TYPE_GET; + } + switch (pRequest->PropertyItem->Id) + { + case KSPROPERTY_SYNTH_CHANNELGROUPS: + *AccessFlags |= KSPROPERTY_TYPE_SET; + } + ntStatus = STATUS_SUCCESS; + pRequest->ValueSize = sizeof(ULONG); + + switch (pRequest->PropertyItem->Id) + { + case KSPROPERTY_SYNTH_PORTPARAMETERS: + if (pRequest->MinorTarget) + { + *AccessFlags |= KSPROPERTY_TYPE_GET; + } + else + { + pRequest->ValueSize = 0; + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + } + } + } + else + { + ntStatus = STATUS_SUCCESS; + switch(pRequest->PropertyItem->Id) + { + case KSPROPERTY_SYNTH_CAPS: + DPRINT("PropertyHandler_Synth:KSPROPERTY_SYNTH_CAPS"); + + if (pRequest->Verb & KSPROPERTY_TYPE_SET) + { + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + + if (NT_SUCCESS(ntStatus)) + { + ntStatus = ValidatePropertyRequest(pRequest, sizeof(SYNTHCAPS), TRUE); + + if (NT_SUCCESS(ntStatus)) + { + SYNTHCAPS *caps = (SYNTHCAPS*)pRequest->Value; + int increment; + RtlZeroMemory(caps, sizeof(SYNTHCAPS)); + // XXX Different guids for different instances! + // + if (pRequest->Node == eSynthNode) + { + increment = sizeof(wszDescOut) - 2; + RtlCopyMemory( caps->Description,wszDescOut,increment); + caps->Guid = CLSID_MiniportDriverDMusUART; + } + else + { + increment = sizeof(wszDescIn) - 2; + RtlCopyMemory( caps->Description,wszDescIn,increment); + caps->Guid = CLSID_MiniportDriverDMusUARTCapture; + } + + caps->Flags = SYNTH_PC_EXTERNAL; + caps->MemorySize = 0; + caps->MaxChannelGroups = 1; + caps->MaxVoices = 0xFFFFFFFF; + caps->MaxAudioChannels = 0xFFFFFFFF; + + caps->EffectFlags = 0; + + CMiniportDMusUART *aMiniport; + ASSERT(pRequest->MajorTarget); + aMiniport = (CMiniportDMusUART *)(PMINIPORTDMUS)(pRequest->MajorTarget); + WCHAR wszDesc2[16]; + int cLen; + cLen = swprintf(wszDesc2,L"[%03x]\0",PtrToUlong(aMiniport->m_pPortBase)); + + cLen *= sizeof(WCHAR); + RtlCopyMemory((WCHAR *)((DWORD_PTR)(caps->Description) + increment), + wszDesc2, + cLen); + + + pRequest->ValueSize = sizeof(SYNTHCAPS); + } + } + + break; + + case KSPROPERTY_SYNTH_PORTPARAMETERS: + DPRINT("PropertyHandler_Synth:KSPROPERTY_SYNTH_PORTPARAMETERS"); + { + CMiniportDMusUARTStream *aStream; + + aStream = (CMiniportDMusUARTStream*)(pRequest->MinorTarget); + if (aStream) + { + ntStatus = aStream->HandlePortParams(pRequest); + } + else + { + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + } + break; + + case KSPROPERTY_SYNTH_CHANNELGROUPS: + DPRINT("PropertyHandler_Synth:KSPROPERTY_SYNTH_CHANNELGROUPS"); + + ntStatus = ValidatePropertyRequest(pRequest, sizeof(ULONG), TRUE); + if (NT_SUCCESS(ntStatus)) + { + *(PULONG)(pRequest->Value) = 1; + pRequest->ValueSize = sizeof(ULONG); + } + break; + + case KSPROPERTY_SYNTH_LATENCYCLOCK: + DPRINT("PropertyHandler_Synth:KSPROPERTY_SYNTH_LATENCYCLOCK"); + + if(pRequest->Verb & KSPROPERTY_TYPE_SET) + { + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + else + { + ntStatus = ValidatePropertyRequest(pRequest, sizeof(ULONGLONG), TRUE); + if(NT_SUCCESS(ntStatus)) + { + REFERENCE_TIME rtLatency; + CMiniportDMusUARTStream *aStream; + + aStream = (CMiniportDMusUARTStream*)(pRequest->MinorTarget); + if(aStream == NULL) + { + ntStatus = STATUS_INVALID_DEVICE_REQUEST; + } + else + { + aStream->m_pMiniport->m_MasterClock->GetTime(&rtLatency); + *((PULONGLONG)pRequest->Value) = rtLatency; + pRequest->ValueSize = sizeof(ULONGLONG); + } + } + } + break; + + default: + DPRINT("Unhandled property in PropertyHandler_Synth"); + break; + } + } + return ntStatus; +} + +/***************************************************************************** + * ValidatePropertyRequest() + ***************************************************************************** + * Validates pRequest. + * Checks if the ValueSize is valid + * Checks if the Value is valid + * + * This does not update pRequest->ValueSize if it returns NT_SUCCESS. + * Caller must set pRequest->ValueSize in case of NT_SUCCESS. + */ +NTSTATUS ValidatePropertyRequest +( + IN PPCPROPERTY_REQUEST pRequest, + IN ULONG ulValueSize, + IN BOOLEAN fValueRequired +) +{ + NTSTATUS ntStatus; + + if (pRequest->ValueSize >= ulValueSize) + { + if (fValueRequired && NULL == pRequest->Value) + { + ntStatus = STATUS_INVALID_PARAMETER; + } + else + { + ntStatus = STATUS_SUCCESS; + } + } + else if (0 == pRequest->ValueSize) + { + ntStatus = STATUS_BUFFER_OVERFLOW; + } + else + { + ntStatus = STATUS_BUFFER_TOO_SMALL; + } + + if (STATUS_BUFFER_OVERFLOW == ntStatus) + { + pRequest->ValueSize = ulValueSize; + } + else + { + pRequest->ValueSize = 0; + } + + return ntStatus; +} // ValidatePropertyRequest + +#ifdef _MSC_VER +#pragma code_seg() +#endif + + Modified: trunk/reactos/drivers/wdm/audio/backpln/portcls/private.hpp URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/wdm/audio/backpln/… ============================================================================== --- trunk/reactos/drivers/wdm/audio/backpln/portcls/private.hpp [iso-8859-1] (original) +++ trunk/reactos/drivers/wdm/audio/backpln/portcls/private.hpp [iso-8859-1] Mon Nov 1 00:26:59 2010 @@ -22,6 +22,8 @@ #include "interfaces.hpp" #include <ks.h> #include <ksmedia.h> +#include <stdio.h> + //#include <intrin.h> #define TAG_PORTCLASS 'SLCP'

3 2

Re: [ros-dev] [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files
by Ged Murphy 01 Nov '10

01 Nov '10

I've just tried to build the cmake branch for the first time and hit the following error : -- xmllite has no base address -- win32csr has no base address -- Configuring done CMake Error in dll/ntdll/CMakeLists.txt: Cannot find source file "ntdll.def". Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx Reverting the changes in this revision fixed it. I know nothing about cmake, but this change appears to have broken the build? Ged. -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jgardou(a)svn.reactos.org Sent: 01 November 2010 09:32 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jgardou] 49396: [CMAKE] - put ntdll.def in source files Author: jgardou Date: Mon Nov 1 09:32:04 2010 New Revision: 49396 URL: http://svn.reactos.org/svn/reactos?rev=49396&view=rev Log: [CMAKE] - put ntdll.def in source files Modified: branches/cmake-bringup/dll/ntdll/CMakeLists.txt Modified: branches/cmake-bringup/dll/ntdll/CMakeLists.txt URL: http://svn.reactos.org/svn/reactos/branches/cmake-bringup/dll/ntdll/CMakeLi… ============================================================================== --- branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] (original) +++ branches/cmake-bringup/dll/ntdll/CMakeLists.txt [iso-8859-1] Mon Nov 1 09:32:04 2010 @@ -21,10 +21,8 @@ rtl/libsupp.c rtl/version.c def/ntdll.rc - def/ntdll.def) + ${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def) -set_source_files_properties(def/ntdll.def PROPERTIES EXTERNAL_OBJECT TRUE) - if(ARCH MATCHES i386) list(APPEND SOURCE dispatch/i386/dispatch.S) elseif(ARCH MATCHES amd64) @@ -48,7 +46,6 @@ endif() target_link_libraries(ntdll - ${CMAKE_CURRENT_BINARY_DIR}/def/ntdll.def ntdllsys libcntpr pseh)

2 1

Please revert changes to ClassPnp in CMAKE Branch
by Ros Arm 31 Oct '10

31 Oct '10

Hello, The jgardou changes add thousands of whitespace changes which make it extremely hard to understand what is going on. Please to not arbitrarily change whitespace across 18 files in a patch! Also, there is nothing wrong with the way ClassPNP was defined before. If you think "How on Earth did this work in trunk?", as quoted from the commit log, maybe you should ask others "Hey, how did this work?". Please revert the changes and come ask how it worked, I'll be happy to help. -r

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 49366: Merge ScmControlService() and ScmSendStartCommand() into ScmSendServiceCommand().
by Cameron Gutman 30 Oct '10

30 Oct '10

This commit breaks 2nd stage setup. It fails just before device enumeration with the message: "CMP_WaitNoPendingInstallEvents() failed". The official buildbot also exhibits this bug. Thanks, Cameron Gutman On Oct 30, 2010, at 3:25 PM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat Oct 30 19:25:23 2010 > New Revision: 49366 > > URL: http://svn.reactos.org/svn/reactos?rev=49366&view=rev > Log: > Merge ScmControlService() and ScmSendStartCommand() into ScmSendServiceCommand(). > > Modified: > trunk/reactos/base/system/services/database.c > trunk/reactos/base/system/services/rpcserver.c > trunk/reactos/base/system/services/services.h > > Modified: trunk/reactos/base/system/services/database.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/datab… > ============================================================================== > --- trunk/reactos/base/system/services/database.c [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/database.c [iso-8859-1] Sat Oct 30 19:25:23 2010 > @@ -678,66 +678,10 @@ > > > DWORD > -ScmControlService(PSERVICE Service, > - DWORD dwControl) > -{ > - PSCM_CONTROL_PACKET ControlPacket; > - SCM_REPLY_PACKET ReplyPacket; > - > - DWORD dwWriteCount = 0; > - DWORD dwReadCount = 0; > - DWORD TotalLength; > - DWORD dwError = ERROR_SUCCESS; > - > - DPRINT("ScmControlService() called\n"); > - > - TotalLength = wcslen(Service->lpServiceName) + 1; > - > - ControlPacket = (SCM_CONTROL_PACKET*)HeapAlloc(GetProcessHeap(), > - HEAP_ZERO_MEMORY, > - sizeof(SCM_CONTROL_PACKET) + (TotalLength * sizeof(WCHAR))); > - if (ControlPacket == NULL) > - return ERROR_NOT_ENOUGH_MEMORY; > - > - ControlPacket->dwControl = dwControl; > - ControlPacket->dwSize = TotalLength; > - ControlPacket->hServiceStatus = (SERVICE_STATUS_HANDLE)Service; > - wcscpy(&ControlPacket->szArguments[0], Service->lpServiceName); > - > - /* Send the control packet */ > - WriteFile(Service->ControlPipeHandle, > - ControlPacket, > - sizeof(SCM_CONTROL_PACKET) + (TotalLength * sizeof(WCHAR)), > - &dwWriteCount, > - NULL); > - > - /* Read the reply */ > - ReadFile(Service->ControlPipeHandle, > - &ReplyPacket, > - sizeof(SCM_REPLY_PACKET), > - &dwReadCount, > - NULL); > - > - /* Release the contol packet */ > - HeapFree(GetProcessHeap(), > - 0, > - ControlPacket); > - > - if (dwReadCount == sizeof(SCM_REPLY_PACKET)) > - { > - dwError = ReplyPacket.dwError; > - } > - > - DPRINT("ScmControlService() done\n"); > - > - return dwError; > -} > - > - > -static DWORD > -ScmSendStartCommand(PSERVICE Service, > - DWORD argc, > - LPWSTR *argv) > +ScmSendServiceCommand(PSERVICE Service, > + DWORD dwControl, > + DWORD argc, > + LPWSTR *argv) > { > PSCM_CONTROL_PACKET ControlPacket; > SCM_REPLY_PACKET ReplyPacket; > @@ -750,7 +694,7 @@ > DWORD dwError = ERROR_SUCCESS; > DWORD i; > > - DPRINT("ScmSendStartCommand() called\n"); > + DPRINT("ScmSendServiceCommand() called\n"); > > /* Calculate the total length of the start command line */ > TotalLength = wcslen(Service->lpServiceName) + 1; > @@ -774,7 +718,7 @@ > if (ControlPacket == NULL) > return ERROR_NOT_ENOUGH_MEMORY; > > - ControlPacket->dwControl = SERVICE_CONTROL_START; > + ControlPacket->dwControl = dwControl; > ControlPacket->hServiceStatus = (SERVICE_STATUS_HANDLE)Service; > ControlPacket->dwSize = TotalLength; > Ptr = &ControlPacket->szArguments[0]; > @@ -819,7 +763,7 @@ > dwError = ReplyPacket.dwError; > } > > - DPRINT("ScmSendStartCommand() done\n"); > + DPRINT("ScmSendServiceCommand() done\n"); > > return dwError; > } > @@ -998,7 +942,10 @@ > DPRINT("Received service process ID %lu\n", dwProcessId); > > /* Send start command */ > - dwError = ScmSendStartCommand(Service, argc, argv); > + dwError = ScmSendServiceCommand(Service, > + SERVICE_CONTROL_START, > + argc, > + argv); > } > } > else > @@ -1227,7 +1174,10 @@ > CurrentService->Status.dwCurrentState == SERVICE_START_PENDING) > { > /* shutdown service */ > - ScmControlService(CurrentService, SERVICE_CONTROL_STOP); > + ScmSendServiceCommand(CurrentService, > + SERVICE_CONTROL_STOP, > + 0, > + NULL); > } > > ServiceEntry = ServiceEntry->Flink; > > Modified: trunk/reactos/base/system/services/rpcserver.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/rpcse… > ============================================================================== > --- trunk/reactos/base/system/services/rpcserver.c [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/rpcserver.c [iso-8859-1] Sat Oct 30 19:25:23 2010 > @@ -699,8 +699,10 @@ > } > > /* Send control code to the service */ > - dwError = ScmControlService(lpService, > - dwControl); > + dwError = ScmSendServiceCommand(lpService, > + dwControl, > + 0, > + NULL); > > /* Return service status information */ > RtlCopyMemory(lpServiceStatus, > @@ -2864,7 +2866,10 @@ > } > > /* Start the service */ > - dwError = ScmStartService(lpService, argc, (LPWSTR *)argv); > + dwError = ScmSendServiceCommand(lpService, > + SERVICE_CONTROL_START, > + argc, > + (LPWSTR *)argv); > > return dwError; > } > @@ -4072,7 +4077,10 @@ > /* FIXME: Convert argument vector to Unicode */ > > /* Start the service */ > - dwError = ScmStartService(lpService, 0, NULL); > + dwError = ScmSendServiceCommand(lpService, > + SERVICE_CONTROL_START, > + 0, > + NULL); > > /* FIXME: Free argument vector */ > > > Modified: trunk/reactos/base/system/services/services.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/servi… > ============================================================================== > --- trunk/reactos/base/system/services/services.h [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/services.h [iso-8859-1] Sat Oct 30 19:25:23 2010 > @@ -104,9 +104,10 @@ > VOID ScmGetBootAndSystemDriverState(VOID); > VOID ScmAutoStartServices(VOID); > VOID ScmAutoShutdownServices(VOID); > -DWORD ScmStartService(PSERVICE Service, > - DWORD argc, > - LPWSTR *argv); > +DWORD ScmSendServiceCommand(PSERVICE Service, > + DWORD dwControl, > + DWORD argc, > + LPWSTR *argv); > > PSERVICE ScmGetServiceEntryByName(LPCWSTR lpServiceName); > PSERVICE ScmGetServiceEntryByDisplayName(LPCWSTR lpDisplayName); > @@ -115,9 +116,6 @@ > PSERVICE *lpServiceRecord); > VOID ScmDeleteServiceRecord(PSERVICE lpService); > DWORD ScmMarkServiceForDelete(PSERVICE pService); > - > -DWORD ScmControlService(PSERVICE Service, > - DWORD dwControl); > > BOOL ScmLockDatabaseExclusive(VOID); > BOOL ScmLockDatabaseShared(VOID); > >

1 0

Static - dynamic generation of reactos.dff
by Jérôme Gardou 30 Oct '10

30 Oct '10

Hi reactos developers. As many of you know, the cmake branch development is going along and is the occasion of many innovations in the way reactos is built. One of this way is the reactos.dff file. Currently, it is a static file, meaning that each time you want to add a module to reactos, you have to edit this file. What I propose is to create this file dynamically, when parsing the build system file. Adding a reactos module twould then be as simple as (!) creating a new build file for this module. For those who are concerned about slipstreaming or optional files like wallpapers or whatever hacking they do with the current reactos.dff, it will be as easy as before. There will be a file to edit, which will be the "static" part of it. Whatever you'll write in this file will be written back to reactos.dff, so there is no need to worry about that. What do you think? Regards. Jérôme. PS : The patch is there. It waits for your approval :-)

5 6

Re: [ros-dev] True multiuser support?
by WaxDragon 28 Oct '10

28 Oct '10

Where is my Server core style command prompt login? Screw explorer. Oh, and I want RDP. ;0p On Oct 27, 2010 4:18 PM, "Adam Kachwalla" <geekdundee(a)gmail.com> wrote: We need to first fix up the logon screen. I have tried this, except the problem lies with CreateDesktop() not wanting to create more than one desktop within the Winlogon process. At this stage, the logon/logoff functionality does not work at all, and some processes still linger about. It appears explorer shell is one of them. On Thu, 28 Oct 2010 02:22:36 +1100, Javier Agustìn Fernàndez Arroyo < elhoir(a)gmail.com> wrote: > H... -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish. _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://ww...

3 3

True multiuser support?
by Javier Agustìn Fernàndez Arroyo 27 Oct '10

27 Oct '10

Hello, devs! ok, lets stop flaming and lets do anything useful 3:> For the future: will ReactOS support "true" multiuser sessions (that is, *simultaneously*)? Is it possible? that would be a big enhancement over Windows :)

5 5

Wine Gecko
by Adam Kachwalla 27 Oct '10

27 Oct '10

I think that Wine Gecko should be integrated in the ReactOS releases. It is needed IIRC for things like Winhlp32 (I think) and HTML Help (defiitely) and applications which use IE browser controls.

6 11

Short summary of our September meeting in Sweden, jointly written by JaixBly and Fireball
by Aleksey Bragin 27 Oct '10

27 Oct '10

Hi ReactOS friends and colleagues. There have been exciting years, I first started to have an eye on the freewin95 project. When I first found the ReactOS project and saw that they actually gave away free zip-files with files to try it out I was eager to test it my self, I first downloaded my first “bochs-1.3-reactos-images.zip” the third april 2002, and it worked! I was amazed, so I downloaded and tested everything that I could test. A long time has gone since that time and I have seen a lot of progress during the years, however it's a lot of years, for me about nine years of downloading, compiling, testing and reading svn- messages. For many people it has been too many years and many have fallen away, now however we are close to something that can actually be used, the kernel is pretty stable other parts of the OS is improving and getting there too. During the last many years we have had about 100 individuals in the IRC channel at all time, it indicates in my mind that we attract as many people as we loose, I guess that is kind of the status for our project, we should be able to change that in a short while I think. If we can release a some real-life applications for our OS we could draw some attention that could be permanent and the project could really start to grow for real. I and Aleksey met in Björkvik, Sweden for a discussion on how to get the ball rolling, we have some suggestions that could serve as step stones for such development. The key is to release a package of the project and see to that it can really do that but not everything else, for example, a web server, it doesn't need all the OS but the ones it needs it has to do really good. Even with this in mind ReactOS isn't well suited for many real applications, so we just looked at a few to see if it would be a way to go, you could perhaps suggest some more, and we would welcome that, we only have to ensure there isn't too much work to actually come to the finish line. Here we present some ideas and what needs to get in place to actually make it work. Webserver - Network subsystem (mainly tcpip.sys driver, and some winsock improvement) - VNC support (future RDP support) - Apache/MySQL/PHP support - XAMPP with toolbox - WEBMIN Thin Client (LiveCD or BootCD) - Re-port our MSTSC.EXE - Local printing (USB/LPT printer support?) Please give us your opinion and please also add possible ideas that you have and think through what needs to get in place to see it come to pass. Yours sincerely, Aleksey & Jan (Jaix) through Jan

7 8

Re: [ros-dev] [ros-diffs] [jgardou] 49281: [PSDK] - Add MIDL_user_allocate and MIDL_user_free definitions - #ifdef a GCC hack
by Timo Kreuzer 26 Oct '10

26 Oct '10

Am 26.10.2010 18:01, schrieb jgardou(a)svn.reactos.org: > +#ifdef __GCC__ > /* Note: this should return a CLIENT_CALL_RETURN, but calling convention for > * returning structures/unions is different between Windows and gcc on i386. */ > LONG_PTR RPC_VAR_ENTRY > @@ -659,6 +663,13 @@ > NdrAsyncClientCall( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING pFormat, ... ); > LONG_PTR RPC_VAR_ENTRY > NdrDcomAsyncClientCall( PMIDL_STUB_DESC pStubDescriptor, PFORMAT_STRING pFormat, ... ); > +#else > +CLIENT_CALL_RETURN RPC_VAR_ENTRY NdrClientCall2( > + PMIDL_STUB_DESC pStubDescriptor, > + PFORMAT_STRING pFormat, > + ... > +); > +#endif > Is this hack even neccessary? I couldn't see any difference between gcc and msvc with the correct prototype. Both return the result in eax.

2 1

Yarotows trunk integration
by Gregor Schneider 26 Oct '10

26 Oct '10

Hi, good to see the branch work back in trunk, I suspected this work would be left to rot and finally be forgotten (like in most other experimental branches). Altogether this looks like a huge step forward, got to test those mode switches it once I have enough time. One thing I noticed from the diffs is the eng/mem.c file, which exceeded my EVIL / HACK threshold. Is this supposed to stay - especially in the context of ARM3's to be proven awesomeness? --- snippet --- EngSecureMem(PVOID Address, ULONG Length) { return (HANDLE)-1; // HACK!!! } EngUnsecureMem(HANDLE Mem) { if (Mem == (HANDLE)-1) return; // HACK!!! } --- snippet --- Good work anyway, thanks to the people involved! Regards, Gregor

6 6

Re: [ros-dev] Please tell me
by WaxDragon 25 Oct '10

25 Oct '10

You could always run two installs in different directories. On Oct 25, 2010 10:51 AM, "Bernd Blaauw" <bblaauw(a)home.nl> wrote: Op 25-10-2010 16:09, Fan Zhang schreef: > > Thanks. But I don't know if i run ReactOS, how could I replace the kernel file, such as ntoskrl... So basicly running a ReactOS installation with RosBE installed as application, sources downloaded and modified, and then you want a way to update files from this ReactOS installation itself? As long as ReactOS installs only on FAT filesystem, I guess you could use a DOS bootdisk/installation to overwrite any files. It's not entirely convenient. Is there basicly a set of lists of ReactOS files for the following: * which ReactOS files can be overwritten by a new file while you're still running in ReactOS? .inf files? small games like solitaire? * which ReactOS files can be overwritten, but require a reboot to be properly noticed? some drivers perhaps? * which ReactOS files require you to be outside of ReactOS in order to replace them? ntoskrnl comes to mind, explorer I guess All in all, mr Fan Zhang might be asking for some kind of update mechanism. If you had an old machine which you run ReactOS on, together with same casual data (audio files perhaps), do you need to reformat the disk to update ReactOS? or only remove the installation directory? or pick a different installation directory? or same directory? After all, you don't want to lose any user data. _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://ww...

1 0

Please tell me
by Fan Zhang 25 Oct '10

25 Oct '10

Hi guys, I want to know how do you debug ReactOS. For example, when I change the code, I used to execute 'Make bootcd'. After that, I will install the ReactOS system by ReactOS.iso. So I'm confused if I have to install the whoe system after compiling. Do you have some easy way? Thanks. Fan

7 8

(no subject)
by Mikhail Zuev 25 Oct '10

25 Oct '10

-- С уважением Михаил

3 2

Introduction
by Oleg Baikalow 25 Oct '10

25 Oct '10

Hi, I thought I would drop a line here finally :) My name is Oleg, I am from Russia (some 180km from Moscow :)). I worked with Aleksey many years ago on some kernelmode networking-related tasks for Windows NT 4.0 and later Windows 2000. Your recent 0.3.12 release news was all over the place here on Russian news sites, my congratulations! ReactOS is a great project, though I never had enough time to actually start hacking, but recent achievements seems to motivate me more. What is situation with networking in ReactOS? I think this could be my main direction of work. I would glad if someone writes a current state of networking in ROS, so I would know where to start. // Oleg Baikalow.

1 0

yarotows
by Timo Kreuzer 24 Oct '10

24 Oct '10

Hi everyone, I'd like to announce that I'm soon going to merge yarotows back into trunk, if no other regressions are found. The current issues (red icons and blue text on disabled buttons will be fixed, Kamil has already a fix.) Last chance to test and object ;-) Regards, Timo

1 0

0.3.12 milestones status
by victor martinez 11 Oct '10

11 Oct '10

I am currently checking our 0.3.12 milestones. And the milestones status is: **********(Bug 5517)Some icons look wrong (blue background)********** There is a Hack for the release. **********(Bug5560): Adobe Acrobat Reader 7.1 throws exception at start**** This is a Wine regression. It is not in our hands.We have to wait for a Fix. **********(Bug 5472) comctl32: Keyboard shortcuts don't work after winesync*** Not as bad as it sounds. It does not work just in 2nd Installation Stage. Anyway, there is a Hack for this issue too. **********(Bug 5314) REGRESSION: Acrobat Reader: pen leak******* It is supposed to be fixed, but it is Bug5560 dependant so it is impossible to confirm the Fixed status. **********(Bug 5598) PATCH: Opera 9.64, FireFox 3.0+ crash when using Russian/Lithuanin/Ukrainian locale**** Reverting the *.nls changes solves the issue. There is a Hack attached. **********(Bug 5482)REGRESSION: ExplorerXP: black background on treeview area***** This is a Wine regression. It is not in our hands. We have to wait for a Fix. **********(Bug 4106) REGRESSION: Wrong text spacing in popup menus / icons after show a font in control applet / Remote Desktop******* It is a minor regression since it has been there for a while. Also Yarotows seems to fix some of the issues. **********(Bug 5591) REGRESSION: devmgr: wrong icons in the TreeView ***** Updating comctl32 will fix the issues. Or we can revert the comctl32 changes. ************** * Summing up * ************** There are 8 regressions. 4 has different options to be solved (Hack or Wine update/revert) 2 are current Wine regressions (we have to wait for a fix or revert Ole32/Comctl32 changes) 1 could be fixed (the Acrobar Reader leakage) but we need to fix Acrobat first(reverting?) 1 is a minor regression without a solution ( "Bug 4106") So we can solve 7/8 regressions. Is it time to think about a 0.3.12 release? It is time to take decisions (reverting/updating/waiting Fixes) since there are solutions. I don't think having the Trunk frozen is good for the project. So, opinions?

8 15

ReactOS development cycle
by Olaf Siejka 11 Oct '10

11 Oct '10

I think its a good time to discuss current development cycle. It become clear to me, that there is no way we can currently adhere to 3 months development cycle. Its pointless to stick to something we managed to succeed only once or twice. Agreeing with the fact we do need releases, for various reasons, i would like to propose a new, longer cycle. The most apparent choices to me are 4 and 6 month ones. At least half of the cycle would be spent on all out development, with the following half turning its concentration to stabilizing trunk, searching for regressions and bugs, fixing them. The cycles would be separated by branching the release version. The actual release would be taking place on the first month of the NEXT DEVELOPMENT cycle. The actual emergency hacking, writing changelog etc. One month is more than enough, to release two RC (at the branching and next one - after two weeks). End of the month must result in final release. RC should be rather released internally for testing purposes on a default iso. The actual proposals are: 4 months: month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 3: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 4; No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x; 6 months: month 1: Development on version x. At the same time, the Release x-1 is to be final-tested, emergency-hacked, changelogged and shipped. The deadline is end of month 1. month 2: Development on version x; month 3: Development on version x. All development that can affect trunk stability, but also will not be shipped with the release X should end or be limited to branch only by the end of this month; month 4: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Ongoing development work only for features that are to be shipped with release x; month 5: Switching from development more to stabilizing trunk, searching for regressions, fixing bugs. Finalizing sub-projects that are to be included in release x; month 6: No new functionality/code, bug-fixing and hunting regressions. This month should end with branching for release x;

8 15

Goodbye Window Object
by James Tabor 09 Oct '10

09 Oct '10

Hi! Since I'm starting to move around now and fell better. Let's just say, I guess it's time to move from the window object and move to the wnd one. I have two local branches here on the portable system, one for Right to Left support (wine sync) I've started and the standard test one. I would like to have all the available Win32 developers help out. You too Ged! Try to get this done before to much goes into CMAKE and have to rework it all. >From window.h: /* Scrollbar info */ PSBINFOEX pSBInfo; // convert to PSBINFO /* Entry in the list of thread windows. */ LIST_ENTRY ThreadListEntry; } WINDOW_OBJECT; /* PWINDOW_OBJECT already declared at top of file */ /* Window flags. */ #define WINDOWOBJECT_NEED_SIZE WNDS_SENDSIZEMOVEMSGS #define WINDOWOBJECT_NEED_ERASEBKGND WNDS_ERASEBACKGROUND #define WINDOWOBJECT_NEED_NCPAINT WNDS_SENDNCPAINT #define WINDOWOBJECT_RESTOREMAX (0x00000020) // Set/Clr WS_MAXIMIZE & #define WINDOWSTATUS_DESTROYING WNDS2_INDESTROY <----- "WNDS2" state2 flag #define WINDOWSTATUS_DESTROYED WNDS_DESTROYED <----- "WNDS" state flag Move this to ntuser.h including the SBINFOEX too, not sure I did that one yet, and start hacking it then test the hell out of it. The flags just convert them to the correct ones, _RESTOREMAX may need more research (another word for HAX). Just writing this and it looks simple, but this is one file that effects the whole w32k tree. Thanks, James

2 3

Re: [ros-dev] [ros-diffs] [sir_richard] 49000: [NTOS]: Fix whitespace typo in comment (two spaces instead of one). That's right. I'm not a fun person.
by Timo Kreuzer 06 Oct '10

06 Oct '10

That will be hard to beat for r50000... > Author: sir_richard > Date: Tue Oct 5 15:59:47 2010 > New Revision: 49000 > > URL: http://svn.reactos.org/svn/reactos?rev=49000&view=rev > Log: > [NTOS]: Fix whitespace typo in comment (two spaces instead of one). > That's right. I'm not a fun person. >

1 0

Patch: Win32k Initialization Sequence Bug.
by James Tabor 04 Oct '10

04 Oct '10

This is a possible fix for the initialization problem reactos suffers from. Just let me know, how it goes with testing. ATM QEmu works okay and no hardware test was run. Thanks, James

2 4

[ros-diffs] [sir_richard] 48712: [WIN32K]: Fix large amount of set-but-unused variables.
by James Tabor 03 Oct '10

03 Oct '10

LOL! Keeping it from running off the side of the page! Know one told you!? The screen is flat! If you go out to far, the characters will fall off! @@ -217,7 +216,8 @@ !(pEH->Flags & WINEVENT_SKIPOWNPROCESS)) || !pEH->idProcess ) ) { - Result = co_IntCallEventProc( UserHMGetHandle(pEH), + // What in the deuce is this right-aligned formatting? + co_IntCallEventProc( UserHMGetHandle(pEH), Event, UserHMGetHandle(pWnd), idObject, I'll audit your code and commit ass cocking comments too........ James

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev