- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [mnordell] 57198: Silence compiler warning
by Thomas Faber 12 Sep '12

12 Sep '12

Hi, On 2012-08-29 14:28, mnordell(a)svn.reactos.org wrote: > --- trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] Wed Aug 29 12:28:35 2012 > @@ -1211,7 +1211,7 @@ > BOOLEAN FirstTry; > ULONG i; > PCSR_SERVER_DLL ServerDll; > - ULONG Result; > + ULONG Result = 0; > > /* Acquire process lock */ > CsrAcquireProcessLock(); > > zero doesn't look like a valid value for this variable. Shouldn't it be one of CsrShutdownCsrProcess, CsrShutdownNonCsrProcess, CsrShutdownCancelled? -Thomas

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 57260: [CMAKE] * Refer to the PSEH lib using its variable.
by Timo Kreuzer 10 Sep '12

10 Sep '12

Can't we get rid of that completely? Afaicr it expands to pseh for both gcc and msvc Am 10.09.2012 01:59, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Sep 9 23:59:16 2012 > New Revision: 57260 > > URL: http://svn.reactos.org/svn/reactos?rev=57260&view=rev > Log: > [CMAKE] > * Refer to the PSEH lib using its variable. > > Modified: > trunk/reactos/base/services/eventlog/CMakeLists.txt > trunk/reactos/base/services/wlansvc/CMakeLists.txt > trunk/reactos/base/system/services/CMakeLists.txt > trunk/reactos/base/system/smss/CMakeLists.txt > > Modified: trunk/reactos/base/services/eventlog/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/eventlog/CMa… > ============================================================================== > --- trunk/reactos/base/services/eventlog/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/services/eventlog/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -17,7 +17,7 @@ > add_executable(eventlog ${SOURCE}) > > if(NOT MSVC) > - target_link_libraries(eventlog pseh) > + target_link_libraries(eventlog ${PSEH_LIB}) > endif() > > set_module_type(eventlog win32cui UNICODE) > > Modified: trunk/reactos/base/services/wlansvc/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/wlansvc/CMak… > ============================================================================== > --- trunk/reactos/base/services/wlansvc/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/services/wlansvc/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -10,7 +10,7 @@ > ${CMAKE_CURRENT_BINARY_DIR}/wlansvc_s.c) > > if(NOT MSVC) > - target_link_libraries(wlansvc pseh) > + target_link_libraries(wlansvc ${PSEH_LIB}) > endif() > > set_module_type(wlansvc win32cui UNICODE) > > Modified: trunk/reactos/base/system/services/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/CMake… > ============================================================================== > --- trunk/reactos/base/system/services/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -22,7 +22,7 @@ > add_executable(services ${SOURCE}) > > if(NOT MSVC) > - target_link_libraries(services pseh) > + target_link_libraries(services ${PSEH_LIB}) > endif() > > set_module_type(services win32cui UNICODE) > > Modified: trunk/reactos/base/system/smss/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/smss/CMakeList… > ============================================================================== > --- trunk/reactos/base/system/smss/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/system/smss/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -2,23 +2,20 @@ > include_directories(${REACTOS_SOURCE_DIR}/include/reactos/subsys) > > list(APPEND SOURCE > - crashdmp.c > - pagefile.c > - sminit.c > - smloop.c > - smsbapi.c > - smsessn.c > - smsubsys.c > - smutil.c > - smss.c > - smss.rc) > + crashdmp.c > + pagefile.c > + sminit.c > + smloop.c > + smsbapi.c > + smsessn.c > + smsubsys.c > + smutil.c > + smss.c > + smss.rc) > > add_executable(smss WIN32 ${SOURCE}) > - > -target_link_libraries(smss nt pseh smlib) > - > +target_link_libraries(smss nt ${PSEH_LIB} smlib) > add_pch(smss smss.h) > - > set_module_type(smss nativecui) > add_importlibs(smss ntdll) > add_cd_file(TARGET smss DESTINATION reactos/system32 FOR all) > > >

1 0

PSEH3
by Timo Kreuzer 09 Sep '12

09 Sep '12

Hi, I am pleased to announce the long awaited (or absolutely surprising) release of PSEH3. This complete from scratch rewrite takes reactos exception handling to a new level. It comprises the following advancements: - Use of enums instead of const variables for internal trylevel counting and other mechanisms. enums can be declared in a nested manner as well and only enums are treated by gcc as full compile time constants, while const variables are treated as dynamic and are only optimized away by the compiler later. This generally results in better optimized code. - No more use of dynamic sized arrays. Those make the compiler emit a slow call to _chkstk. It could have been prevented in PSEH2, if enums had been used instead of consts. The new code uses the same registration frame for the top level and nested levels, which also simplifies the code. - No more use of nested function stack trampolines. These are small code chunks that are being dynamically put on the stack, when the address of a nested function is taken. The address of the nested function then points to this trampoline, which sets up a pointer for nested variable access (nested function can access variables in the parent frame). These were parsed by PSEH2 to calculate the neccessary nested frame pointer. PSEH3 uses a static scope table instead that contains the address of the nested function. this is only possible by first declaring the function and putting the implementation after the address is stored in the static table. This is because nested functions that do not access any variables in the parent frame do not need a stack trampoline and their addresses are thus considered compiler constants. GCC doesn't notice that a nested function uses variables of the parent frame, before the function is actually implemented, so with only a prototype, it assumes a constant address. To get the value of the parent frame pointer, PSEH2 calls the nested function 2 times: The first time with a bogus frame pointer and a parameter that tells the function to return the (assumed) address of the current registration frame. Without a proper parent frame pointer the nested function will return an offset that we can use together with the real address of the registration frame (which we know, when calling the filter of finally functions) to calculate the proper parent frame pointer. The 2nd call passes a different parameter and allows the function to do the actual work and access variables in the parent frame. - Improved performance due to use of "asm goto". This construct allows to get away with having labels, that are never accessed by any C code. The compiler doesn't remove them. So we do not need the old hack, of comparing a "volatile" 0 against 0, just to confuse GCC to not optimize away a label. Even though there is a bug/defficiency/limitation in asm goto, that would usually not allow the combination with static C jump labels, we can still do that due to some tricks that force GCC to do the right thing. More information: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840 - Improved performance due to faster registration. The new registration code is smaller and saves only esp and ebp. Due to some tricks in PSEH3, GCC is forced to assume all registers are being clobbered when the __except block is run. Filter function and __finally function don't make use of registers from the previous code. So all neccessary register save and restore is now fully done by GCC. - The trick to make GCC assume all registers are clobbered at the beginning of the __except block has one additional huge advantage. Now all variables that are accessed by the __except block will be stored in memory locations, so that modifications in the __try block will be available in the __except block, something that doesn't work with PSEH2. This does not prevent the compiler from doing constant expression elimination! So when you try to do 2 different, constant assignments to a variable in the __try block, expect that this will be reduced to only the later assignment. GCC does not know, that the execution can be interrupted in the middle of the __try block between those 2 assignments. If you need such stuff, you must use a volatile variable. - Less stack usage. PSEH3 stores much less data on the stack. No trampolines, only esp and ebp are saved, registration frames are smaller. - No more need for _SEH2_YIELD(). This macro was used to make sure the registration frames are properly unregistered, when leaving the try or except block using goto or return. This is not neccessary anymore due to the use of __attribute__((cleanup)). This attribute is attached to the registration frame and causes the cleanup function to be called automatically, whenever the variable goes out of scope. This happens when a goto or return is used in the code. - Human readable warnings, when special SEH instriniscs, like _exception_info() or _abnormal_termination() are used outside of their valid context. - Cleaner and better readable code, so you won't get braindead, when trying to figure out what's going on. Header: < 300 lines commented code, instead of 370 lines uncommented code, lib: < 250 lines of commented C code + < 70 lines commented asm code, instead of 290 lines of uncommented C code + 120 lines uncommented asm code) I also promised Amine to take a look into implementing a version that is compatible with clang. Initially I planned to include this into this release, but it turns out that clang massivley lacks features to do so and a completely different approach will probably be used for that. The new code is only compatible with GCC 4.7 and later, and it's also currently disabled (cmake option USE_PSEH3). Tesbot showed no noticable regressions. Have fun. Timo

1 0

Bugzilla outage
by Aleksey Bragin 08 Sep '12

08 Sep '12

Hello, I turned off Bugzilla now in favor of finishing the switch to JIRA. Once the work is done, I will announce either return to Bugzilla or introduce JIRA. Hopefully, it'll be the latter option. Best regards, Aleksey.

1 0

Fwd: buildbot failure in ReactOS on CMake_x86_MSVCWin Debug
by caemyr＠myopera.com 04 Sep '12

04 Sep '12

This commit breaks msvc compilation. Best regards ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on CMake_x86_MSVCWin Debug Date: Tue, 04 Sep 2012 03:10:09 +0000 The Buildbot has finished a build on builder CMake_x86_MSVCWin Debug while building ReactOS. Full details are available at: http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/1908 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_1 Build Reason: scheduler Build Source Stamp: 57233 Blamelist: cgutman BUILD FAILED: failed building bootcd sincerely, -The Buildbot -- With best regards Caemyr

1 0

Re: [ros-dev] buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 03 Sep '12

03 Sep '12

Currently, we experience random crashes in 2nd stage. I was unable to catch any first exception bar the one with vmware detection code (which is outdated and should be removed). After forcing build again, test run failed at Cleanup, due to previously unresolved issue of repeating whole testrun when crash occurs in APItests. On Mon, Sep 3, 2012, at 10:21 AM, buildbot(a)reactos.org wrote: > The Buildbot has finished a build on builder Windows_AMD64_1 VBox-Test > while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6496 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_2 > > Build Reason: The web-page 'force build' button was pressed by 'osiejka': > > Build Source Stamp: 57227 > Blamelist: > > BUILD FAILED: failed Cleanup > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 02 Sep '12

02 Sep '12

This one is caused by rev 57225: Backtrace: http://www.reactos.org/paste/index.php/10472/ Please fix ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Sun, 02 Sep 2012 22:50:06 +0000 The Buildbot has finished a build on builder Windows_AMD64_1 VBox-Test while building ReactOS. Full details are available at: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6492 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) Build Source Stamp: 57225 Blamelist: ion BUILD FAILED: failed test sincerely, -The Buildbot -- With best regards Caemyr

1 0

Problem with dbgwin revisions from Windows builder
by caemyr＠myopera.com 02 Sep '12

02 Sep '12

Hiya R3ddr4g0n reported to me that all recent revisions uploaded to iso.reactos.org are not correct. Instead of given revision, all the builds are reporting to be rev 57150. After a quick check, i downloaded bootcd-57221-dbgwin.iso and checked its SHA1: should be 56d2190610e8a1f650faa3c6a6a8348f89d1fa1b but happened to be: f97ac4aba0e5ceed3b5beae3d7ab2bc2c7600fab - which is indeed the same checksum as for x86_CMake-57150 The possible clue from the upload script: bash: rsync: command not found rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /home/lapo/package/rsync-3.0.8-1/src/rsync-3.0.8/io.c(601) [sender=3.0.8] * Done. * Remotely compressing bootcd-57219-dbgwin... Now, Colin may recall that i was strongly against using fancy tricks for sending the revs instead of simply archiving them locally and uploading afterwards. This way with rsync was supposed to be saving bit of bandwidth. Now we have to reupload at least all since 57150, unless you can use the fancy tricks to spot the same iso files. Great thing we can save a little bit of bandwidth but waste time to fix it afterwards. Accoring to the reporter: [21:45:37] <r3ddr4g0n> for sure from 57115 to 57221 If you still think this methode is saving us anything, please reckon that a single view of testbot log means downloading a few megabytes of text at least. I`m stopping the uploads until the problem is resolved in a way to prevent it from happening again. -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-diffs] [ion] 57215: [NTOSKRNL]: Do not return data in failure cases in NtProtectVirtualMemory. [NTOSKRNL]: No longer support non-ARM3 sections in NtProtectVirtualMemory, as the only OS calls were already ...
by Thomas Faber 02 Sep '12

02 Sep '12

Hi! On 02.09.2012 03:17, ion(a)svn.reactos.org wrote: > Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Sun Sep 2 01:17:42 2012 > @@ -3668,15 +3795,50 @@ > } > > // > - // Assert on the things we don't yet support > - // > - ASSERT(ZeroBits == 0); > - ASSERT((AllocationType& MEM_LARGE_PAGES) == 0); > - ASSERT((AllocationType& MEM_PHYSICAL) == 0); > - ASSERT((AllocationType& MEM_WRITE_WATCH) == 0); > - ASSERT((AllocationType& MEM_TOP_DOWN) == 0); > - ASSERT((AllocationType& MEM_RESET) == 0); > - ASSERT(Process->VmTopDown == 0); > + // Fail on the things we don't yet support > + // > + if (ZeroBits != 0) > + { > + DPRINT1("Zero bits not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_LARGE_PAGES) == 1) > + { > + DPRINT1("MEM_LARGE_PAGES not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_PHYSICAL) == 1) > + { > + DPRINT1("MEM_PHYSICAL not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_WRITE_WATCH) == 1) > + { > + DPRINT1("MEM_WRITE_WATCH not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_TOP_DOWN) == 1) > + { > + DPRINT1("MEM_TOP_DOWN not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_RESET) == 1) > + { > + DPRINT1("MEM_RESET not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } These guys won't work, you need != 0 or == MEM_BLAH -Thomas

1 0

Monthly meeting - August 2012
by Aleksey Bragin 30 Aug '12

30 Aug '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 30th of August, 19:00 UTC. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting, if the server works. If not, then an alternative place will be announced here. Note that the IRC service will only be started shortly before the meeting. Your participation passwords will be emailed to you shortly before the meeting starts. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. In order to save time, let's choose who is going to be the minute taker on the upcoming meeting. As usual, Z98 is welcome to volunteer. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). With the best regards, Aleksey Bragin.

7 6

Re: [ros-dev] [ros-diffs] [jgardou] 57171: [MINGWEX] - mark DllMain as a weak symbol for GCC. - supply a stubbed DllMain for MSVC. - DllMain is optional, and some DLLs don't implement it. That doesn't mean that they have no...
by Timo Kreuzer 27 Aug '12

27 Aug '12

Hi, I don't agree with these changes. If we need a DllEntry in the lib, then we should use the one that is provided by mingw-w64 (all this code is 100% mingw-w64). It simply returns true (thats exactly what the one in MS CRT does) and works for gcc and MSVC. Also what's the point of DisableThreadLibraryCalls() here? As you wrote yourself, no DllMain only means "I have nothing more to initialize than the CRT". But this disables the CRT thread initializion, too. There is also no need for weak symbols, we can simply call the stub DllMain, since it doesn't (shouldn't) do anything. Regards, Timo Am 27.08.2012 01:31, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Sun Aug 26 23:31:49 2012 > New Revision: 57171 > > URL: http://svn.reactos.org/svn/reactos?rev=57171&view=rev > Log: > [MINGWEX] > - mark DllMain as a weak symbol for GCC. > - supply a stubbed DllMain for MSVC. > - DllMain is optional, and some DLLs don't implement it. That doesn't mean that they have no entry point, it means "I have nothing more to initialize than the CRT". > > Added: > trunk/reactos/lib/sdk/crt/startup/mscdllmain.c (with props) > Modified: > trunk/reactos/lib/sdk/crt/msvcrtex.cmake > trunk/reactos/lib/sdk/crt/startup/crtdll.c > > Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Aug 26 23:31:49 2012 > @@ -66,7 +66,9 @@ > endif() > > if(MSVC) > - list(APPEND MSVCRTEX_SOURCE startup/mscmain.c) > + list(APPEND MSVCRTEX_SOURCE > + startup/mscmain.c > + startup/mscdllmain.c) > else() > list(APPEND MSVCRTEX_SOURCE startup/gccmain.c) > endif() > > Modified: trunk/reactos/lib/sdk/crt/startup/crtdll.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/crtdll… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] Sun Aug 26 23:31:49 2012 > @@ -50,7 +50,19 @@ > > extern int mingw_app_type; > > +/* > + * It is possible that a DLL provides no DllMain entry point. > + * Mark it as a weak symbol for GCC. > + * Tests show that at link time, MSVC looks for a function first in the object files provided, and then > + * in the libraries. This means that we must provide a basic implementation in msvcrtex, which will be used > + * if none is found in the object files provided to link.exe. > + * This also means that we can't rely on a DllMain function implemented in a static library when linking a DLL. > + */ > +#ifdef __GNUC__ > +extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved) __attribute__((weak)); > +#else > extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved); > +#endif > > extern WINBOOL WINAPI DllEntryPoint (HANDLE, DWORD, LPVOID); > > @@ -198,10 +210,12 @@ > } > if (dwReason == DLL_PROCESS_ATTACH) > __main (); > - retcode = DllMain(hDllHandle,dwReason,lpreserved); > + if(DllMain) > + retcode = DllMain(hDllHandle,dwReason,lpreserved); > if (dwReason == DLL_PROCESS_ATTACH && ! retcode) > { > - DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > + if(DllMain) > + DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > DllEntryPoint (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > _CRT_INIT (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > } > > Added: trunk/reactos/lib/sdk/crt/startup/mscdllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/mscdll… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/startup/mscdllmain.c (added) > +++ trunk/reactos/lib/sdk/crt/startup/mscdllmain.c [iso-8859-1] Sun Aug 26 23:31:49 2012 > @@ -1,0 +1,11 @@ > +#include <oscalls.h> > +#define _DECL_DLLMAIN > +#include <process.h> > + > +WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved) > +{ > + /* If the DLL provides no DllMain, then chances are that it doesn't bother with thread initialization */ > + if(dwReason == DLL_PROCESS_ATTACH) > + DisableThreadLibraryCalls(hDllHandle); > + return TRUE; > +} > > Propchange: trunk/reactos/lib/sdk/crt/startup/mscdllmain.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > >

2 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 57141: [FREELDR] Improve readability of sector calculation
by Timo Kreuzer 27 Aug '12

27 Aug '12

Btw, we are using a lot of hardcoded 512 values here for sector size even though there is a field in fthe Volume structure for that. Is that correct? Am 23.08.2012 14:02, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Thu Aug 23 12:02:30 2012 > New Revision: 57141 > > URL: http://svn.reactos.org/svn/reactos?rev=57141&view=rev > Log: > [FREELDR] > Improve readability of sector calculation > > Modified: > trunk/reactos/boot/freeldr/freeldr/fs/fat.c > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/fat.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/fa… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] Thu Aug 23 12:02:30 2012 > @@ -1338,8 +1338,7 @@ > // > // Seek to right position > // > - Position.HighPart = SectorNumber >> 23; > - Position.LowPart = SectorNumber << 9; > + Position.QuadPart = (ULONGLONG)SectorNumber * 512; > ret = ArcSeek(Volume->DeviceId, &Position, SeekAbsolute); > if (ret != ESUCCESS) > { > > >

3 2

Re: [ros-dev] [ros-diffs] [jgardou] 57160: [OPENGL32_WINETEST] - Sync with wine
by Thomas Faber 26 Aug '12

26 Aug '12

Hi, On 2012-08-26 11:17, jgardou(a)svn.reactos.org wrote: > Log: > [OPENGL32_WINETEST] > - Sync with wine speaking from previous experience, it'd be very nice if the commit message would allow finding the correctly matched Wine version for this easily (i.e. without tedious look-up of what was HEAD on whatever date the commit was). Thanks! Best regards, Thomas

1 0

Good bye RBuild
by Pierre Schweitzer 25 Aug '12

25 Aug '12

Hi, after having finished its 11405th build, the last official RBuild builder has gone offline, forever. The Linux CMake builder has now turned as being the official builder. Thanks RBuild, you served us well :-). Also, the other RBuild builder, the release builder has also gone offline forever. Its hardware was not able to properly handle a ReactOS build, and was hardly upgradable. Daily release builds should replace it any time soon. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

4 4

Re: [ros-dev] [ros-diffs] [akhaldi] 57151: [CMAKE/MSVC] Hermès Bélusca: * Fix a bug in the way we compiled the boot sectors on the x64 build. * Consistently set the mc compiler, like gcc builds. * Use proper variables when ...
by Timo Kreuzer 24 Aug '12

24 Aug '12

What was the bug? I can't figure it out from the changes. Am 24.08.2012 17:36, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Fri Aug 24 15:36:17 2012 > New Revision: 57151 > > URL: http://svn.reactos.org/svn/reactos?rev=57151&view=rev > Log: > [CMAKE/MSVC] > Hermès Bélusca: > * Fix a bug in the way we compiled the boot sectors on the x64 build. > * Consistently set the mc compiler, like gcc builds. > * Use proper variables when referring to the compilers. > See issue #7297 for more details. > > Modified: > trunk/reactos/cmake/msvc.cmake > trunk/reactos/toolchain-msvc.cmake > > Modified: trunk/reactos/cmake/msvc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/msvc.cmake?rev=57151… > ============================================================================== > --- trunk/reactos/cmake/msvc.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/msvc.cmake [iso-8859-1] Fri Aug 24 15:36:17 2012 > @@ -53,12 +53,12 @@ > # We may temporarily use just the global defines, but this is not a solution as some modules (minihal for example) apply additional definitions to source files, so we get an incorrect build of such targets. > get_directory_property(definitions DEFINITIONS) > set(CMAKE_ASM_COMPILE_OBJECT > - "cl /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> ${definitions} /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > + "<CMAKE_C_COMPILER> /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> ${definitions} /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > "<CMAKE_ASM_COMPILER> /nologo /Cp /Fo<OBJECT> /c /Ta <OBJECT>.tmp") > else() > # NMake Makefiles > set(CMAKE_ASM_COMPILE_OBJECT > - "cl /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> <DEFINES> /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > + "<CMAKE_C_COMPILER> /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> <DEFINES> /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > "<CMAKE_ASM_COMPILER> /nologo /Cp /Fo<OBJECT> /c /Ta <OBJECT>.tmp") > endif() > > @@ -67,14 +67,14 @@ > add_compile_flags("/analyze") > elseif(_PREFAST_) > message("PREFAST enabled!") > - set(CMAKE_C_COMPILE_OBJECT "prefast cl ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > + set(CMAKE_C_COMPILE_OBJECT "prefast <CMAKE_C_COMPILER> ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > "prefast LIST") > - set(CMAKE_CXX_COMPILE_OBJECT "prefast cl ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /TP /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > + set(CMAKE_CXX_COMPILE_OBJECT "prefast <CMAKE_CXX_COMPILER> ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /TP /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > "prefast LIST") > set(CMAKE_C_LINK_EXECUTABLE > - "cl ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > + "<CMAKE_C_COMPILER> ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > set(CMAKE_CXX_LINK_EXECUTABLE > - "cl ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > + "<CMAKE_CXX_COMPILER> ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > endif() > > set(CMAKE_RC_CREATE_SHARED_LIBRARY ${CMAKE_C_CREATE_SHARED_LIBRARY}) > @@ -143,7 +143,7 @@ > # Compile the generated asm stub file > add_custom_command( > OUTPUT ${_asm_stubs_file}.obj > - COMMAND ml /Cp /Fo${_asm_stubs_file}.obj /c /Ta ${_asm_stubs_file} > + COMMAND ${CMAKE_ASM_COMPILER} /Cp /Fo${_asm_stubs_file}.obj /c /Ta ${_asm_stubs_file} > DEPENDS ${_asm_stubs_file}) > else() > # be clear about the "language" > @@ -202,27 +202,28 @@ > endfunction() > > macro(macro_mc FLAG FILE) > - set(COMMAND_MC mc ${FLAG} -r ${REACTOS_BINARY_DIR}/include/reactos -h ${REACTOS_BINARY_DIR}/include/reactos ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc) > + set(COMMAND_MC ${CMAKE_MC_COMPILER} ${FLAG} -r ${REACTOS_BINARY_DIR}/include/reactos -h ${REACTOS_BINARY_DIR}/include/reactos ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc) > endmacro() > > #pseh workaround > set(PSEH_LIB "pseh") > > -# Use full path for ml when using x64 VS > -if((ARCH MATCHES amd64) AND ($ENV{VCINSTALLDIR})) > +# Use a full path for the x86 version of ml when using x64 VS. > +# It's not a problem when using the DDK/WDK because, in x64 mode, > +# both the x86 and x64 versions of ml are available. > +if((ARCH MATCHES amd64) AND (DEFINED ENV{VCINSTALLDIR})) > set(CMAKE_ASM16_COMPILER $ENV{VCINSTALLDIR}/bin/ml.exe) > else() > set(CMAKE_ASM16_COMPILER ml.exe) > endif() > > function(CreateBootSectorTarget _target_name _asm_file _binary_file _base_address) > - > set(_object_file ${_binary_file}.obj) > set(_temp_file ${_binary_file}.tmp) > > add_custom_command( > OUTPUT ${_temp_file} > - COMMAND cl /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm /D__ASM__ /D_USE_ML /EP /c ${_asm_file} > ${_temp_file} > + COMMAND ${CMAKE_C_COMPILER} /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm /D__ASM__ /D_USE_ML /EP /c ${_asm_file} > ${_temp_file} > DEPENDS ${_asm_file}) > > add_custom_command( > > Modified: trunk/reactos/toolchain-msvc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-msvc.cmake?rev=5… > ============================================================================== > --- trunk/reactos/toolchain-msvc.cmake [iso-8859-1] (original) > +++ trunk/reactos/toolchain-msvc.cmake [iso-8859-1] Fri Aug 24 15:36:17 2012 > @@ -6,6 +6,7 @@ > # which compilers to use for C and C++ > set(CMAKE_C_COMPILER cl) > set(CMAKE_CXX_COMPILER cl) > +set(CMAKE_MC_COMPILER mc) > set(CMAKE_RC_COMPILER rc) > if(${ARCH} MATCHES amd64) > set(CMAKE_ASM_COMPILER ml64) > > >

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 57124: [WINED3D] - MSVC needs INFINITY and NAN from wine/port.h. It can't be included from a header Will be sent upstream
by Thomas Faber 24 Aug '12

24 Aug '12

Hi, On 2012-08-21 15:38, jgardou(a)svn.reactos.org wrote: > URL:http://svn.reactos.org/svn/reactos?rev=57124&view=rev > Log: > [WINED3D] > - MSVC needs INFINITY and NAN from wine/port.h. > It can't be included from a header > Will be sent upstream can you explain what's wrong with including it from a header? I was under the impression we had fixed the infinity/nan stuff properly on Wine's side by adding it all to port.h. Thanks! -Thomas

3 3

Re: [ros-dev] [ros-diffs] [jgardou] 57129: [WIN32K] - Use the right surface for direct DCs in DIB transfer functions It could have changed with a display settings change
by Timo Kreuzer 22 Aug '12

22 Aug '12

Hmmmmmmm.... I don't think that this is a good idea. We must call DC_vPrepareForBlit to lock the surfaces, otherwise we run into race conditions. And we should really also care for the mouse cursor, otherwise we might make it unhappy. Anyway, I don't care about this code, since I already rewrote it :D Anyway, I think it's time to ASSERT device locks. Am 22.08.2012 18:45, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Aug 22 16:45:49 2012 > New Revision: 57129 > > URL: http://svn.reactos.org/svn/reactos?rev=57129&view=rev > Log: > [WIN32K] > - Use the right surface for direct DCs in DIB transfer functions > It could have changed with a display settings change > > Modified: > trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Aug 22 16:45:49 2012 > @@ -447,8 +447,16 @@ > DC_UnlockDc(pDC); > goto Exit2; > } > - > - pSurf = pDC->dclevel.pSurface; > + > + /* > + * Select the right surface. > + * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't > + * care about mouse, visible region or brushes in this API. > + */ > + if(pDC->dctype == DCTYPE_DIRECT) > + pSurf = pDC->ppdev->pSurface; > + else > + pSurf = pDC->dclevel.pSurface; > if (!pSurf) > { > DC_UnlockDc(pDC); > @@ -1113,7 +1121,15 @@ > goto cleanup; > } > > - psurfDst = pdc->dclevel.pSurface; > + /* > + * Select the right surface. > + * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't > + * care about mouse, visible region or brushes in this API. > + */ > + if(pdc->dctype == DCTYPE_DIRECT) > + psurfDst = pdc->ppdev->pSurface; > + else > + psurfDst = pdc->dclevel.pSurface; > if (!psurfDst) > { > // CHECKME > > >

2 1

Re: [ros-dev] [ros-diffs] [fireball] 57119: [CRT] - Use wine's wctype table in CRT for iswctype() function. Previous implementation was returning incorrect information for non-Latin characters. Problem found and fixed by Se...
by Timo Kreuzer 22 Aug '12

22 Aug '12

For me it looks like _pwctype, __p__pwctype and __pwctype_func also need to be fixed. Am 20.08.2012 19:20, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Mon Aug 20 17:20:48 2012 > New Revision: 57119 > > URL: http://svn.reactos.org/svn/reactos?rev=57119&view=rev > Log: > [CRT] > - Use wine's wctype table in CRT for iswctype() function. Previous implementation was returning incorrect information for non-Latin characters. Problem found and fixed by Sergey Shamanaev (seven_ro). > - Move wctype.c from libwine to lib/sdk/crt instead of making yet another copy of it (currently there is one more in tools/unicode). Suggested by Amine Khaldi. > See issue #5090 for more details. > > Added: > trunk/reactos/lib/sdk/crt/string/wctype.c > - copied unchanged from r57101, trunk/reactos/lib/3rdparty/libwine/wctype.c > Removed: > trunk/reactos/lib/3rdparty/libwine/wctype.c > Modified: > trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt > trunk/reactos/lib/sdk/crt/crt.cmake > trunk/reactos/lib/sdk/crt/string/ctype.c > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/CMake… > > Removed: trunk/reactos/lib/3rdparty/libwine/wctype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/wctyp… > > Modified: trunk/reactos/lib/sdk/crt/crt.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/crt.cmake?rev=… > > Modified: trunk/reactos/lib/sdk/crt/string/ctype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/string/ctype.c… > > >

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 57101: [NtUser] - Stop spurious window handle errors and code fixes.
by Thomas Faber 20 Aug '12

20 Aug '12

Hey, On 2012-08-18 23:40, jimtabor(a)svn.reactos.org wrote: > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/ca… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/caret.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/caret.c [iso-8859-1] Sat Aug 18 21:40:49 2012 > @@ -42,14 +42,17 @@ > if(!ThreadQueue || !ThreadQueue->CaretInfo) > return FALSE; > > - pWnd = UserGetWindowObject(ThreadQueue->CaretInfo->hWnd); > co_IntHideCaret(ThreadQueue->CaretInfo); > ThreadQueue->CaretInfo->Bitmap = (HBITMAP)0; > ThreadQueue->CaretInfo->hWnd = (HWND)0; > ThreadQueue->CaretInfo->Size.cx = ThreadQueue->CaretInfo->Size.cy = 0; > ThreadQueue->CaretInfo->Showing = 0; > ThreadQueue->CaretInfo->Visible = 0; > - IntNotifyWinEvent(EVENT_OBJECT_DESTROY, pWnd, OBJID_CARET, CHILDID_SELF, 0); > + if (ThreadQueue->CaretInfo->hWnd) this can never be true, as it was set to 0 above. > + { > + pWnd = UserGetWindowObject(ThreadQueue->CaretInfo->hWnd); > + IntNotifyWinEvent(EVENT_OBJECT_DESTROY, pWnd, OBJID_CARET, CHILDID_SELF, 0); > + } > return TRUE; > } > Best, Thomas

2 1

ReactOS Services partial downtime
by Pierre Schweitzer 19 Aug '12

19 Aug '12

Hi, today, many of our services encountered a long downtime due to an air conditioning issue in the datacenter their running hypervisor is located (you can find more info there: http://hetzner-status.de/ - german). A safety shutdown has been done to preserve our server hardware integrity. The other hypervisor and the other services being in other datacenters, they were not concerned by the issue. Services being concerned: - Mail - SVN - git - web - build master They are now fully back online and operational. Sorry for the inconvenience. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Bug 7247: msvcrt Should Uses SEH and crtdll Does Not
by James Tabor 18 Aug '12

18 Aug '12

Hi, Has anyone seen this bug report? James Bug 7247

1 0

Old bootcd ISO files
by caemyr＠myopera.com 16 Aug '12

16 Aug '12

Dear All Some time ago, due to lack of space on ROS servers, a large number of old ISO files for prebuilt revisions had to be deleted. I was only able to pull a limited number of them. Right now, while hunting a regression in late rev 3xxxx, i`m heavily limited due to lack of ISOs. For a long-term plan, i intend to add a legacy builder, containing all the previous, rbuild-based Build environments, allowing me to build some really old revs. Right now i need to ask for your assistance. If you have any older, OFFICIAL Bootcd ISO files, of revision earlier than 44000, please let me know, be it on irc or by forum PM. We need to compare the revisions first, to avoid duplicates, then i`ll pull them from you onto my server, which will effectively allow our Team to use them if needed. Thanks in advance. -- With best regards Caemyr

1 0

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 16 Aug '12

16 Aug '12

It seems that any crash in APITESTS on vbox testbot is causing rosautotest to redo from start. We can see this in stdio log: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6323/s… (just search for "restarting" word). APITESTS are repated and such log as a whole is messing up testman, which is treating it like two submissions for the same revision. It accepts the first one (incomplete due to crash) and rejects the second one, reporting a duplicate: "ERROR! submit(13111, 518, ...) - We already have a result for this test suite in this test run! "Windows_AMD64_1 VBox-Test"" As we all know, we should expect tests to fail and even crash (this is what they are designed for), hence the error is in rosautotest and testman. Rosautotest, strangely, is affected only on vbox, on kvm the apitest crash is not causing a restart of test run. Winetests, if i recall correctly, were never affected in such way. Testman should not reject a submission after its saved up and revision - blocked. I am aware that some will be tempted to comment out the test in question, but this is not a proper solution to this situation. Other apitest will crash in the future, bringing the whole thing back. Same as with regressions, lack of tests due to such issue, will bite us back in the future, when least expected and most needed. This is why I humbly request this issue to be solved properly, once and for all. With best regards ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Tue, 14 Aug 2012 00:23:24 +0000 The Buildbot has finished a build on builder Windows_AMD64_1 VBox-Test while building ReactOS. Full details are available at: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6324 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) Build Source Stamp: 57075 Blamelist: akhaldi BUILD FAILED: failed Cleanup sincerely, -The Buildbot -- With best regards Caemyr

4 7

(no subject)
by saeid 10 Aug '12

10 Aug '12

i cant make the code

4 3

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text
by thomas＠parker.iz34.com 09 Aug '12

09 Aug '12

http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 hbelusca <hermes.belusca(a)sfr.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |terminedijs(a)yahoo.com -- Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev