- Ros-dev - ReactOS.org

by Colin Finck

Hi all, I've added the "project-tools" and "web" repositories to FishEye today, so you can browse through their changes as well now. My ultimate plan is to remove "CORE", "ROSAPPS" and "ROSTESTS" too and replace all of them by the already existing "reactos" repository. This resembles our SVN counterparts exactly. I was told this has already been tried in the past with no success due to severe performance issues. As FishEye is running on a more powerful server now, please try again and tell me if there are any problems with using "reactos" instead of "CORE". If not, I will get rid of the redundant repositories soon. Apart from this, we're now also using post-commit hooks to update the repositories in FishEye. This gives you instant information about new commits and reduces the server load a bit. Cheers, Colin

11 years, 6 months

5
4
0 0

Commit 62283

by Hermès BÉLUSCA - MAÏTO

Sorry for IRC channel flood because of the huge commit log of r62283. As someone just suggested, I could have used indeed a Jira task for that /me apologises. Hermès.

11 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 62266: [CRT] - Force the use of memory operands in bit test intrinsics. Bit offsets above 31 (or 63) can't behave correctly with registers (the constant case is fine because it ensures low...

by Timo Kreuzer

While the bug was definately on our side, I still think there is a GCC/CLANG bug here as well. Memory operands larger than register size are a rare case (probably limited to the bittest instructions) but allowing a register operand here should cause the compiler to either error out or in the worst case emit something like "mov eax, [BaseAddress]; bt eax, cl;" or "mov eax, [PointerToBaseAddress]; mov eax, [eax]; bt eax, cl;" rather than "bt [PointerToBaseAddress], cl;", which it actually did. Changing the constraint to something that wasn't working changed the behaviour in a way that changed the level of dereference! The operation was done on the pointer instead of on the memory pointed to by the pointer! Maybe we should file a bugreport. Am 20.02.2014 20:28, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Thu Feb 20 19:28:27 2014 > New Revision: 62266 > > URL: http://svn.reactos.org/svn/reactos?rev=62266&view=rev > Log: > [CRT] > - Force the use of memory operands in bit test intrinsics. Bit offsets above 31 (or 63) can't behave correctly with registers (the constant case is fine because it ensures low offsets). Thanks to Timo Kreuzer and Alex Radocea. > > Modified: > trunk/reactos/include/crt/mingw32/intrin_x86.h > > Modified: trunk/reactos/include/crt/mingw32/intrin_x86.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/mingw32/intrin… > ============================================================================== > --- trunk/reactos/include/crt/mingw32/intrin_x86.h [iso-8859-1] (original) > +++ trunk/reactos/include/crt/mingw32/intrin_x86.h [iso-8859-1] Thu Feb 20 19:28:27 2014 > @@ -1032,7 +1032,7 @@ > if(__builtin_constant_p(b)) > __asm__("bt %[b], %[a]; setb %b[retval]" : [retval] "=q" (retval) : [a] "mr" (*(a + (b / 32))), [b] "Ir" (b % 32)); > else > - __asm__("bt %[b], %[a]; setb %b[retval]" : [retval] "=q" (retval) : [a] "mr" (*a), [b] "r" (b)); > + __asm__("bt %[b], %[a]; setb %b[retval]" : [retval] "=q" (retval) : [a] "m" (*a), [b] "r" (b)); > > return retval; > } > @@ -1045,7 +1045,7 @@ > if(__builtin_constant_p(b)) > __asm__("bt %[b], %[a]; setb %b[retval]" : [retval] "=q" (retval) : [a] "mr" (*(a + (b / 64))), [b] "Ir" (b % 64)); > else > - __asm__("bt %[b], %[a]; setb %b[retval]" : [retval] "=q" (retval) : [a] "mr" (*a), [b] "r" (b)); > + __asm__("bt %[b], %[a]; setb %b[retval]" : [retval] "=q" (retval) : [a] "m" (*a), [b] "r" (b)); > > return retval; > } > @@ -1058,7 +1058,7 @@ > if(__builtin_constant_p(b)) > __asm__("btc %[b], %[a]; setb %b[retval]" : [a] "+mr" (*(a + (b / 32))), [retval] "=q" (retval) : [b] "Ir" (b % 32)); > else > - __asm__("btc %[b], %[a]; setb %b[retval]" : [a] "+mr" (*a), [retval] "=q" (retval) : [b] "r" (b)); > + __asm__("btc %[b], %[a]; setb %b[retval]" : [a] "+m" (*a), [retval] "=q" (retval) : [b] "r" (b)); > > return retval; > } > @@ -1070,7 +1070,7 @@ > if(__builtin_constant_p(b)) > __asm__("btr %[b], %[a]; setb %b[retval]" : [a] "+mr" (*(a + (b / 32))), [retval] "=q" (retval) : [b] "Ir" (b % 32)); > else > - __asm__("btr %[b], %[a]; setb %b[retval]" : [a] "+mr" (*a), [retval] "=q" (retval) : [b] "r" (b)); > + __asm__("btr %[b], %[a]; setb %b[retval]" : [a] "+m" (*a), [retval] "=q" (retval) : [b] "r" (b)); > > return retval; > } > @@ -1082,7 +1082,7 @@ > if(__builtin_constant_p(b)) > __asm__("bts %[b], %[a]; setb %b[retval]" : [a] "+mr" (*(a + (b / 32))), [retval] "=q" (retval) : [b] "Ir" (b % 32)); > else > - __asm__("bts %[b], %[a]; setb %b[retval]" : [a] "+mr" (*a), [retval] "=q" (retval) : [b] "r" (b)); > + __asm__("bts %[b], %[a]; setb %b[retval]" : [a] "+m" (*a), [retval] "=q" (retval) : [b] "r" (b)); > > return retval; > } > > >

11 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 62267: [KERNEL32] Revert r62264. Reason: all APIs set the last error when a CSR* call doesn't return STATUS_SUCCESS. If some winetests fail because of this, this is because we do not cor...

by Aleksey Bragin

Well, it would make sense to talk to Christoph first. It's not THAT obvious where the real bug is, and he might have been willing to try to find it and fix. Regards, Aleksey Bragin On 21.02.2014 0:17, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Thu Feb 20 20:17:53 2014 > New Revision: 62267 > > URL: http://svn.reactos.org/svn/reactos?rev=62267&view=rev > Log: > [KERNEL32] > Revert r62264. > Reason: all APIs set the last error when a CSR* call doesn't return STATUS_SUCCESS. If some winetests fail because of this, this is because we do not correctly do what's needed here (normally the TRUE or FALSE value is returned by the console server, and is not retrieved by a success or failure of a CSR call contrary to what's done here). > > Modified: > trunk/reactos/dll/win32/kernel32/client/console/console.c > > Modified: trunk/reactos/dll/win32/kernel32/client/console/console.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/console/console.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/console/console.c [iso-8859-1] Thu Feb 20 20:17:53 2014 > @@ -796,6 +796,7 @@ > sizeof(CONSOLE_VERIFYHANDLE)); > if (!NT_SUCCESS(Status)) > { > + BaseSetLastNTError(Status); > return FALSE; > } > > >

11 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 62249: [NTOSKRNL] Fix returned symbolic links in IoGetDeviceInterfaces.

by Alex Ionescu

Was this the Video Driver bug in ReactBox? Best regards, Alex Ionescu On Tue, Feb 18, 2014 at 11:53 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Tue Feb 18 19:53:48 2014 > New Revision: 62249 > > URL: http://svn.reactos.org/svn/reactos?rev=62249&view=rev > Log: > [NTOSKRNL] > Fix returned symbolic links in IoGetDeviceInterfaces. > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/deviface.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/deviface.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/deviface… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/deviface.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/deviface.c [iso-8859-1] Tue Feb 18 19:53:48 2014 > @@ -466,7 +466,7 @@ > goto cleanup; > } > > - /* Enumerate subkeys (ie the different device objets) */ > + /* Enumerate subkeys (i.e. the different device objects) */ > while (TRUE) > { > Status = ZwEnumerateKey( > @@ -729,14 +729,17 @@ > Status = STATUS_UNSUCCESSFUL; > goto cleanup; > } > - KeyName.Length = KeyName.MaximumLength = (USHORT)bip->DataLength - 4 * sizeof(WCHAR); > - KeyName.Buffer = &((PWSTR)bip->Data)[4]; > + KeyName.Length = KeyName.MaximumLength = (USHORT)bip->DataLength; > + KeyName.Buffer = (PWSTR)bip->Data; > + > + /* Fixup the prefix (from "\\?\") */ > + RtlCopyMemory(KeyName.Buffer, L"\\??\\", 4 * sizeof(WCHAR)); > > /* Add new symbolic link to symbolic link list */ > if (ReturnBuffer.Length + KeyName.Length + sizeof(WCHAR) > ReturnBuffer.MaximumLength) > { > PWSTR NewBuffer; > - ReturnBuffer.MaximumLength = (USHORT)max(ReturnBuffer.MaximumLength * 2, > + ReturnBuffer.MaximumLength = (USHORT)max(ReturnBuffer.MaximumLength * sizeof(WCHAR), > (USHORT)(ReturnBuffer.Length + > KeyName.Length + > 2 * sizeof(WCHAR))); > >

11 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [dquintana] 62226: [RSHELL] * CMenuBand: Handle WM_COMMAND and run SMC_EXEC for static menu items (Run, Shutdown). CORE-7881

by Jerome Gardou

Hi David > + if (m_staticToolbar != NULL) > + hr = m_staticToolbar->GetWindow(&hwndStatic); > + if (FAILED(hr)) > + return hr; You are using potentially uninitialized variable here. are you compiling without "-Werror" (or /WX on msvc)? Keep it up :-) Greetings Jérôme

11 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 62142: [REACTOS] Revert r62140 per Alex request. Alex, why did we choose Win2k3 SP1 at first, and not SP2 directly? CORE-6611 #comment Reverted in r62142.

by Alex Ionescu

SP2 was not out when we made the choice. And before we move to SP2, I'd rather move to Win 7 =) -- Best regards, Alex Ionescu -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of hbelusca(a)svn.reactos.org Sent: Wednesday, February 12, 2014 2:58 PM To: ros-diffs(a)reactos.org Subject: [ros-diffs] [hbelusca] 62142: [REACTOS] Revert r62140 per Alex request. Alex, why did we choose Win2k3 SP1 at first, and not SP2 directly? CORE-6611 #comment Reverted in r62142. Author: hbelusca Date: Wed Feb 12 22:58:13 2014 New Revision: 62142 URL: http://svn.reactos.org/svn/reactos?rev=62142&view=rev Log: [REACTOS] Revert r62140 per Alex request. Alex, why did we choose Win2k3 SP1 at first, and not SP2 directly? CORE-6611 #comment Reverted in r62142. Modified: trunk/reactos/boot/bootdata/hivesys.inf trunk/reactos/include/psdk/ntverp.h trunk/reactos/ntoskrnl/ex/init.c Modified: trunk/reactos/boot/bootdata/hivesys.inf URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?… ============================================================================== --- trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] (original) +++ trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] Wed Feb 12 22:58:13 2014 @@ -1143,8 +1143,8 @@ ; ReactOS specific - by default we report ourselves as Server for the user, ; but we can also report as Workstation if some application needs it. HKLM,"SYSTEM\CurrentControlSet\Control\ReactOS\Settings\Version","ReportAsWorkstation",0x00010001,0x00000000 -; Some installers check for SP2 -HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x00000200 +; Some installers check for SP1 +HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001 +,0x00000100 HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders","SecurityProviders",2,"schannel.dll" HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders\SaslProfiles",,0x00000012 Modified: trunk/reactos/include/psdk/ntverp.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ntverp.h?rev=… ============================================================================== --- trunk/reactos/include/psdk/ntverp.h [iso-8859-1] (original) +++ trunk/reactos/include/psdk/ntverp.h [iso-8859-1] Wed Feb 12 22:58:13 2014 @@ -14,10 +14,10 @@ */ // -// Windows NT Build 3790.3959 +// Windows NT Build 3790.1830 // #define VER_PRODUCTBUILD 3790 -#define VER_PRODUCTBUILD_QFE 3959 +#define VER_PRODUCTBUILD_QFE 1830 // // Windows NT Version 5.2 Modified: trunk/reactos/ntoskrnl/ex/init.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=621… ============================================================================== --- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original) +++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Wed Feb 12 22:58:13 2014 @@ -1072,12 +1072,12 @@ /* Setup initial system settings */ CmGetSystemControlValues(LoaderBlock->RegistryBase, CmControlVector); - /* Load static defaults for Service Pack 2 and add our SVN revision */ + /* Load static defaults for Service Pack 1 and add our SVN revision + */ /* Format of CSD : SPMajor - SPMinor */ - CmNtCSDVersion = 0x200 | (KERNEL_VERSION_BUILD_HEX << 16); + CmNtCSDVersion = 0x100 | (KERNEL_VERSION_BUILD_HEX << 16); CmNtCSDReleaseType = 0; - /* Set Service Pack data for Service Pack 2 */ + /* Set Service Pack data for Service Pack 1 */ CmNtSpBuildNumber = VER_PRODUCTBUILD_QFE; if (!(CmNtCSDVersion & 0xFFFF0000)) {

11 years, 7 months

4
4
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 62140: [REACTOS] Go fully to Win2k3 SP2 version reporting. CORE-6611 #resolve #comment Fixed in r62140.

by Alex Ionescu

I am so sick of these types of changes being made without consultation. The kernel is not SP2. Please do not update this value, as we are missing exports/functionality exposed on SP2. Best regards, Alex Ionescu On Wed, Feb 12, 2014 at 12:03 PM, <hbelusca(a)svn.reactos.org> wrote: > Author: hbelusca > Date: Wed Feb 12 20:03:57 2014 > New Revision: 62140 > > URL: http://svn.reactos.org/svn/reactos?rev=62140&view=rev > Log: > [REACTOS] > Go fully to Win2k3 SP2 version reporting. > CORE-6611 #resolve #comment Fixed in r62140. > > Modified: > trunk/reactos/boot/bootdata/hivesys.inf > trunk/reactos/include/psdk/ntverp.h > trunk/reactos/ntoskrnl/ex/init.c > > Modified: trunk/reactos/boot/bootdata/hivesys.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys.inf?… > ============================================================================== > --- trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/hivesys.inf [iso-8859-1] Wed Feb 12 20:03:57 2014 > @@ -1143,8 +1143,8 @@ > ; ReactOS specific - by default we report ourselves as Server for the user, > ; but we can also report as Workstation if some application needs it. > HKLM,"SYSTEM\CurrentControlSet\Control\ReactOS\Settings\Version","ReportAsWorkstation",0x00010001,0x00000000 > -; Some installers check for SP1 > -HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x00000100 > +; Some installers check for SP2 > +HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x00000200 > > HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders","SecurityProviders",2,"schannel.dll" > HKLM,"SYSTEM\CurrentControlSet\Control\SecurityProviders\SaslProfiles",,0x00000012 > > Modified: trunk/reactos/include/psdk/ntverp.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ntverp.h?rev=… > ============================================================================== > --- trunk/reactos/include/psdk/ntverp.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/ntverp.h [iso-8859-1] Wed Feb 12 20:03:57 2014 > @@ -14,10 +14,10 @@ > */ > > // > -// Windows NT Build 3790.1830 > +// Windows NT Build 3790.3959 > // > #define VER_PRODUCTBUILD 3790 > -#define VER_PRODUCTBUILD_QFE 1830 > +#define VER_PRODUCTBUILD_QFE 3959 > > // > // Windows NT Version 5.2 > > Modified: trunk/reactos/ntoskrnl/ex/init.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/init.c?rev=621… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/init.c [iso-8859-1] Wed Feb 12 20:03:57 2014 > @@ -1072,12 +1072,12 @@ > /* Setup initial system settings */ > CmGetSystemControlValues(LoaderBlock->RegistryBase, CmControlVector); > > - /* Load static defaults for Service Pack 1 and add our SVN revision */ > + /* Load static defaults for Service Pack 2 and add our SVN revision */ > /* Format of CSD : SPMajor - SPMinor */ > - CmNtCSDVersion = 0x100 | (KERNEL_VERSION_BUILD_HEX << 16); > + CmNtCSDVersion = 0x200 | (KERNEL_VERSION_BUILD_HEX << 16); > CmNtCSDReleaseType = 0; > > - /* Set Service Pack data for Service Pack 1 */ > + /* Set Service Pack data for Service Pack 2 */ > CmNtSpBuildNumber = VER_PRODUCTBUILD_QFE; > if (!(CmNtCSDVersion & 0xFFFF0000)) > { > >

11 years, 7 months

2
1
0 0

Server fixes

by Colin Finck

Hi all, Pierre and me changed the HTTP server software on the VM for build.reactos.org, git.reactos.org, source.reactos.org and svn.reactos.org today. This may or may not fix the performance issues people were recently experiencing at git.reactos.org. At least, the stability has improved and the full configuration is less complex, making further changes easier. If anything got noticably worse, please report here. Cheers, Colin

11 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 62011: [atl] - Fix atl thunks to be allocated in executable memory and not from the stack in order to run libraries that use atl (such as browseui) in windows with DEP enabled

by Jerome Gardou

Hey Giannis. How big qre the thunks ? A whole page for each of them looks like a lot of resources. What about a special heap ? Keep it up! Regards Jérôme Le jeudi 6 février 2014, 13:07:37 gadamopoulos(a)svn.reactos.org a écrit : > Author: gadamopoulos > Date: Thu Feb 6 13:07:37 2014 > New Revision: 62011 > > URL: http://svn.reactos.org/svn/reactos?rev=62011&view=rev > Log: > [atl] > - Fix atl thunks to be allocated in executable memory and not from the stack > in order to run libraries that use atl (such as browseui) in windows with > DEP enabled > > Modified: > branches/shell-experiments/lib/atl/atlwin.h > > Modified: branches/shell-experiments/lib/atl/atlwin.h > URL: > http://svn.reactos.org/svn/reactos/branches/shell-experiments/lib/atl/atlwi > n.h?rev=62011&r1=62010&r2=62011&view=diff > =========================================================================== > === --- branches/shell-experiments/lib/atl/atlwin.h [iso-8859-1] (original) > +++ branches/shell-experiments/lib/atl/atlwin.h [iso-8859-1] Thu Feb 6 > 13:07:37 2014 @@ -153,21 +153,32 @@ > class CWndProcThunk > { > public: > - thunkCode m_thunk; > + thunkCode *m_pthunk; > _AtlCreateWndData cd; > public: > + > + CWndProcThunk() > + { > + m_pthunk = (thunkCode*)VirtualAlloc(NULL, sizeof(thunkCode), > MEM_COMMIT, PAGE_EXECUTE_READWRITE); + } > + > + ~CWndProcThunk() > + { > + VirtualFree(m_pthunk, sizeof(thunkCode), MEM_RELEASE); > + } > + > BOOL Init(WNDPROC proc, void *pThis) > { > - m_thunk.m_mov = 0x042444C7; > - m_thunk.m_this = PtrToUlong(pThis); > - m_thunk.m_jmp = 0xe9; > - m_thunk.m_relproc = DWORD(reinterpret_cast<char *>(proc) - > (reinterpret_cast<char *>(this) + sizeof(thunkCode))); + m_pthunk- >m_mov = > 0x042444C7; > + m_pthunk->m_this = PtrToUlong(pThis); > + m_pthunk->m_jmp = 0xe9; > + m_pthunk->m_relproc = DWORD(reinterpret_cast<char *>(proc) - > (reinterpret_cast<char *>(m_pthunk) + sizeof(thunkCode))); return TRUE; > } > > WNDPROC GetWNDPROC() > { > - return reinterpret_cast<WNDPROC>(&m_thunk); > + return reinterpret_cast<WNDPROC>(m_pthunk); > } > };

11 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [cwittich] 61898: [baseaddress] hackfix for VLC Player startup

by Aleksey Bragin

I would ask, what's the problem? Short description of the problem: <Christoph_vW> wsock32 only redirects to ws2_32 <Christoph_vW> when it gets relocated vlc does not work anymore Any clues? Regards, Aleksey Bragin On 01.02.2014 12:55, cwittich(a)svn.reactos.org wrote: > Author: cwittich > Date: Sat Feb 1 08:55:54 2014 > New Revision: 61898 > > URL: http://svn.reactos.org/svn/reactos?rev=61898&view=rev > Log: > [baseaddress] > hackfix for VLC Player startup > > Modified: > trunk/reactos/cmake/baseaddress.cmake > > Modified: trunk/reactos/cmake/baseaddress.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/baseaddress.cmake?re… > ============================================================================== > --- trunk/reactos/cmake/baseaddress.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/baseaddress.cmake [iso-8859-1] Sat Feb 1 08:55:54 2014 > @@ -283,7 +283,7 @@ > set(baseaddress_ws2_32_new 0x70790000) > set(baseaddress_wshirda 0x70760000) > set(baseaddress_wshtcpip 0x70730000) > -set(baseaddress_wsock32 0x70700000) > +set(baseaddress_wsock32 0x78700000) # FIXME: hackfix for VLC player > set(baseaddress_wtsapi32 0x706d0000) > set(baseaddress_wuapi 0x70690000) > set(baseaddress_xinput1_1 0x70660000) > >

11 years, 7 months

1
0
0 0

Status Meeting (January 2014)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 30th of January, 19:00 UTC. Put that into your calendars so you don't forget. And that's in two days! IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to me shortly before the meeting starts). Hermes sent the first suggestion well before the meeting, so please follow his example and send your suggestions too. Regards, Aleksey Bragin

11 years, 7 months

5
4
0 0

Re: [ros-dev] [ros-diffs] [hbelusca] 61875: [NTVDM] - Enable experimental sound support (only PC speaker for the moment, aka. uses beep.sys). - Introduce a #define WORKING_TIMER which aim is to disable the currently problem...

by Timo Kreuzer

What about reading the current TickCount from the shared user page? Am 29.01.2014 01:25, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Wed Jan 29 00:25:43 2014 > New Revision: 61875 > > URL: http://svn.reactos.org/svn/reactos?rev=61875&view=rev > Log: > [NTVDM] > - Enable experimental sound support (only PC speaker for the moment, aka. uses beep.sys). > - Introduce a #define WORKING_TIMER which aim is to disable the currently problematic approximate performance counter value calculation done in order not to call QueryPerformanceCounter each time. > The problem is that we then compute a number of clock ticks for the PIT, which becomes negative, and therefore everything starts to hang. > Disabling this code and calling each time QueryPerformanceCounter, fixes everything; we gain in precision but we loose in performance... > A definitive fix must be found, [TheFlash] !! > > This fixes sound (and hangs) in Advanced NetWars, Dangerous Dave, ElitePlus and Rescue Rover (the games that I've tested so far). > >

11 years, 7 months

1
0
0 0

[PATCH] fix typo in several names and comments

by Sergei Antonov

Hello! 'Lastest' (with 's') is a typo. The patch fixes or replaces it in several places.

11 years, 7 months

1
0
0 0

[PATCH] wrong way to get section count in pefixup.c

by Sergei Antonov

Hello! This is my fix to an error in pefixup tool. The section count was taken from a wrong struct member and the tool only worked (when worked) by chance.

11 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 61755: [KSECDD] Implement IRP_MJ_QUERY_INFORMATION and IRP_MJ_QUERY_VOLUME_INFORMATION

by Michael Fritscher

Hello Timo, > +static > +NTSTATUS > +KsecQueryVolumeInformation( > + PVOID InfoBuffer, > + FS_INFORMATION_CLASS FsInformationClass, > + PSIZE_T BufferLength) > +{ > + PFILE_FS_DEVICE_INFORMATION DeviceInformation; > + > + /* Only FileFsDeviceInformation is supported */ > + if (FsInformationClass == FileFsDeviceInformation) > + { > + return STATUS_INVALID_INFO_CLASS; > + } shouldn't be that "FsInformationClass != FileFsDeviceInformation" ? ;) Best regards, Michael Fritscher

11 years, 7 months

2
1
0 0

GPU drivers for XP/2003

by Javier Agustìn Fernàndez Arroyo

Hello all, XP support will come to end on April this year, and i suppose GPU vendors and manufacturers will drop driver releases for those systems as well. So, my question is, what about trying to contact them and try to convince them to release those drivers as "ReactOS" instead of "Windows XP"? :)

11 years, 7 months

2
2
0 0

While in Screen Saver

by James Tabor

Hello, Something not to worry about... Maybe someone knows about? Thanks, James While sitting for days idle this occurred. Real hardware Build 20140112-r61596 IRQ 2 is cascade (../../win32ss/user/ntuser/input.c:70) err: Screensaver is Idle (../../win32ss/user/ntuser/input.c:70) err: Screensaver is Idle WARNING: RtlUnhandledExceptionFilter at ../../lib/rtl/exception.c:302 is UNIMPLEMENTED! Unhandled exception MM:***PAGE FAULT AT IRQL > 1 Va 05000450, IRQL 2 MM:***EIP 8089B32A, EFL 00010282 MM:***EAX 0206000B, ECX 05000400 EDX 00000100 MM:***EBX 05000400, ESI 00000000 EDI 00000279 Entered debugger on last-chance exception (Exception Code: 0xc0000006) (Unknown/User defined exception) (../../ntoskrnl/mm/mmfault.c:122) Page fault at high IRQL was 2, address 0 Entered debugger on last-chance exception (Exception Code: 0xc0000006) (Unknown/User defined exception) kdb:> bt Eip: <NTOSKRNL.EXE:91d76 (include/ddk/wdm.h:9607 (KiTimerExpiration))> Frames: <NTOSKRNL.EXE:9293d (ntoskrnl/ke/dpc.c:576 (KiRetireDpcList))> <NTOSKRNL.EXE:28c6 (:0 (KiRetireDpcListInDpcStack))> <NTOSKRNL.EXE:1d185c (:0 (KdbInitFileBuffer))> Couldn't access memory at 0x00000018! kdb:> cont *** Fatal System Error: 0x0000001e (0xC0000006,0x80891D76,0xF78A7E30,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x8094dc0c. (../../ntoskrnl/mm/mmfault.c:122) Page fault at high IRQL was 2, address 4 Entered debugger on last-chance exception (Exception Code: 0xc0000006) (Unknown/User defined exception) kdb:> bt Eip: <NTOSKRNL.EXE:91d73 (include/ddk/wdm.h:9606 (KiTimerExpiration))> Frames: <NTOSKRNL.EXE:9293d (ntoskrnl/ke/dpc.c:576 (KiRetireDpcList))> <NTOSKRNL.EXE:28c6 (:0 (KiRetireDpcListInDpcStack))> <HAL.DLL:b3e2 (hal/halx86/up/pic.c:1323 (HalpDispatchInterrupt2))> <HAL.DLL:b648 (hal/halx86/up/pic.c:687 (KfLowerIrql))> <NTOSKRNL.EXE:173c87 (:0 (PortInfo))> <NTOSKRNL.EXE:14ac4a (ntoskrnl/kd/kdmain.c:207 (KdpEnterDebuggerException))> Couldn't access memory at 0x0000006C! kdb:>

11 years, 8 months

1
0
0 0

r61585 Buildbot test failures

by Eric Kohl

Hi! You may have noticed that my latest patch causes buildbot failures. This happens because the patch breaks winlogons AutoAdminLogon feature. Please do not revert that patch! I'll provide a fix for the AutoAdminLogon feature as soon as possible. Regards Eric

11 years, 8 months

1
0
0 0

Wine now has Task Scheduler implementation

by Александр

11 years, 8 months

1
0
0 0

Official announcement of ReactOS being kickstarted

by Александр

11 years, 8 months

1
0
0 0

Intel announces Edison: a 22nm dual-core PC the size of an SD card

by Александр

11 years, 8 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 61545: [MESA] - Use PSEH to test and catch SSE exceptions #CORE-7727 Problem with software implementation is fixed with r61545. Investigating on vmware driver support.

by Timo Kreuzer

Is this a bug in the mesa code or are we lacking something here? Am 06.01.2014 19:39, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Jan 6 18:39:42 2014 > New Revision: 61545 > > URL: http://svn.reactos.org/svn/reactos?rev=61545&view=rev > Log: > [MESA] > - Use PSEH to test and catch SSE exceptions > #CORE-7727 Problem with software implementation is fixed with r61545. Investigating on vmware driver support. > > Modified: > trunk/reactos/dll/opengl/mesa/x86/common_x86.c > > Modified: trunk/reactos/dll/opengl/mesa/x86/common_x86.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/mesa/x86/common… > ============================================================================== > --- trunk/reactos/dll/opengl/mesa/x86/common_x86.c [iso-8859-1] (original) > +++ trunk/reactos/dll/opengl/mesa/x86/common_x86.c [iso-8859-1] Mon Jan 6 18:39:42 2014 > @@ -51,6 +51,8 @@ > #include "main/imports.h" > #include "common_x86_asm.h" > > +#include <pseh/pseh2.h> > + > >

11 years, 8 months

3
3
0 0

Re: [ros-dev] [ros-general] ReactOS ISO support has been added in Rufus

by Pete Batard

On 2014.01.03 18:58, Thomas Mueller wrote: > What I would like to do, and about the only way I can see and test > ReactOS, is to build from RosBE from FreeBSD or Linux, or Wine, and > install onto a USB stick without having to make an intermediate > boot/installation medium. Then today may be your lucky day... ;) But first things first (you may skip this part if you're only interested in UNIX, as Rufus is Windows only): Besides ISO support through Syslinux, the new BETA of Rufus [1] also adds the ability to install the ReactOS boot records, so that one can then boot freeldr.sys directly from USB. Unlike what's the case for the ISO, this is a bare install, so you will still need to copy your own freeldr.sys, freeldr.ini and relevant files to the USB. However, the hard part of the install (modifying the boot records) should now be taken care of for you. Now, since this is an advanced feature, it's not made available in the UI by default. To access the bare ReactOS boot record installation, you must first enable Advanced Mode in Rufus, by clicking the white triangle next to "Format Options" and only then will you see "ReactOS" listed in the "Create a bootable disk" dropdown. It's the same way Rufus provides bare installation of Syslinux v4 & v5 boot records. I tested freeldr.sys boot from USB using this method, after copying the same set of files as the one ReactOS creates for second stage installation, and it seems to work as good as one might expect (boots brilliantly, but then runs into ReactOS 0x7b, due to issues with USB support - at least on the systems I'm testing with). I may eventually use this method to support ISOs, but for now, I'll stick with the syslinux -> mboot.c32 -> setupldr.sys for ISO support, while the direct freeldr.sys for more adventurous people. Now, what may be of more interest for UNIX-derivative users, is that what Rufus really uses behind the scenes to install boot blocks is its own integrated version of ms-sys [2]. Thus, since I added ReactOS support in my own embedded version of ms-sys, I also went ahead and produced a generic UNIX version that can install the ReactOS bootblocks from the commandline, for freeldr support. To use it, you'll first need to clone the relevant github repository [3] and then switch to the "rufus" branch of that repo, which is where I added the changes. I'm also providing a fully detailed example of a run (git clone, branch switch, installation, etc), in the attached log, but basically, what you want to run is: 1. Fetching & compiling the source # git clone https://github.com/pbatard/ms-sys.git # cd ms-sys/ # git checkout rufus # make 2. Installing the ReactOS boot blocks on an USB drive, here /dev/sda, after blanking its first sectors: # dd if=/dev/zero of=/dev/sda bs=8M count=8 # fdisk /dev/sda => create a FAT32 bootable partition # mkdosfs -F 32 /dev/sda1 # ./bin/ms-sys -0 /dev/sda => install the ReactOS MBR # ./bin/ms-sys -O /dev/sda1 => install the ReactOS FAT32 PBR # ./bin/ms-sys -p /dev/sda1 => write partition info [REQUIRED!] Then you can just copy your files, and boot the drive. Note that the MBR option is -0 (minus zero) and the second -O (minus uppercase O), and also that your drive _will NOT boot_ unless you also apply the -p option. Oh and if you want to complain about ms-sys (yeah, it would probably be nicer if it used getopt so that you could run multiple options at once), please remember that: 1. I am not the author of ms-sys 2. I use my own non-commandline, non-UNIX compatible version in Rufus This means that, due to time constraints, I have little interest in improving my UNIX/ReactOS version of ms-sys (to add ext2 support for instance). I created it as fast as I could, in the hope that it would be useful for UNIX people (only tested FAT32 - I kind of expect FAT16 to be broken), and I may see with the author (Henrik Carlqvist) if he wants to integrate the ReactOS patches, but that'll be about it. > There ought to be something like "make install DESTDIR=...". Hopefully, now that you can use ms-sys on Linux/FreeBSD, you should be able to add an install step, that can invoke ms-sys to create a whole Live/USB system from scratch, to install the newly generated development binaries. "All" that remains then, is to fix USB support in ReactOS, so that such a system can run as expected... ;) Regards, /Pete [1] http://rufus.akeo.ie/downloads/ [2] http://ms-sys.sourceforge.net/ [3] https://github.com/pbatard/ms-sys/tree/rufus root@sheeva:/usr/src# git clone https://github.com/pbatard/ms-sys.git Cloning into ms-sys... remote: Counting objects: 306, done. remote: Compressing objects: 100% (86/86), done. remote: Total 306 (delta 203), reused 302 (delta 199) Receiving objects: 100% (306/306), 84.59 KiB, done. Resolving deltas: 100% (203/203), done. root@sheeva:/usr/src# cd ms-sys/ root@sheeva:/usr/src/ms-sys# git checkout rufus Branch rufus set up to track remote branch rufus from origin. Switched to a new branch 'rufus' root@sheeva:/usr/src/ms-sys# make mkdir -p dep cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/partition_info.d src/partition_info.c > dep/partition_info.d mkdir -p obj mkdir -p bin cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/partition_info.o src/partition_info.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/ntfs.d src/ntfs.c > dep/ntfs.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/ntfs.o src/ntfs.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat12.d src/fat12.c > dep/fat12.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat12.o src/fat12.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat16.d src/fat16.c > dep/fat16.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat16.o src/fat16.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/file.d src/file.c > dep/file.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/file.o src/file.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/br.d src/br.c > dep/br.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/br.o src/br.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/nls.d src/nls.c > dep/nls.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/nls.o src/nls.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/main.d src/main.c > dep/main.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/main.o src/main.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/fat32.d src/fat32.c > dep/fat32.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/fat32.o src/fat32.c cc -MM -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -MT dep/identify.d src/identify.c > dep/identify.d cc -O2 -ansi -pedantic -Wall -c -I inc -D PACKAGE=\"ms-sys\" -D LOCALEDIR=\"/usr/local/share/locale\" -idirafter include-fallback -D_FILE_OFFSET_BITS=64 -o obj/identify.o src/identify.c cc -o bin/ms-sys obj/partition_info.o obj/ntfs.o obj/fat12.o obj/fat16.o obj/file.o obj/br.o obj/nls.o obj/main.o obj/fat32.o obj/identify.o mkdir -p mo msgfmt -o mo/sv.mo po/sv.po root@sheeva:/usr/src/ms-sys# dd if=/dev/zero of=/dev/sda bs=8M count=8 8+0 records in 8+0 records out 67108864 bytes (67 MB) copied, 2.41523 s, 27.8 MB/s root@sheeva:/usr/src/ms-sys# fdisk /dev/sda Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel with disk identifier 0x7759d579. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4, default 1): 1 First sector (2048-63487999, default 2048): Using default value 2048 Last sector, +sectors or +size{K,M,G} (2048-63487999, default 63487999): Using default value 63487999 Command (m for help): t Selected partition 1 Hex code (type L to list codes): c Changed system type of partition 1 to c (W95 FAT32 (LBA)) Command (m for help): a Partition number (1-4): 1 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. Syncing disks. root@sheeva:/usr/src/ms-sys# mkdosfs -F 32 /dev/sda1 mkdosfs 2.11 (12 Mar 2005) root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -0 /dev/sda ReactOS master boot record successfully written to /dev/sda root@sheeva:/usr/src/ms-sys# ./bin/ms-sys /dev/sda /dev/sda has an x86 boot sector, it is a ReactOS master boot record, like the one this program creates with the switch -r on a hard disk device. root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -O /dev/sda1 FAT32 ReactOS boot record successfully written to /dev/sda1 root@sheeva:/usr/src/ms-sys# ./bin/ms-sys -p /dev/sda1 Start sector 2048 (nr of hidden sectors) successfully written to /dev/sda1 Physical disk drive id 0x80 (C:) successfully written to /dev/sda1 Number of heads (64) successfully written to /dev/sda1 root@sheeva:/usr/src/ms-sys# ./bin/ms-sys /dev/sda1 /dev/sda1 has a FAT32 file system. /dev/sda1 has an x86 boot sector, it is exactly the kind of FAT32 ReactOS boot record this program would create with the switch -O on a FAT32 partition. root@sheeva:/usr/src/ms-sys# mount /dev/sda1 /mnt/usb/ root@sheeva:/usr/src/ms-sys# ls /ext/reactos_files/ ReactOS/ freeldr.ini freeldr.sys root@sheeva:/usr/src/ms-sys# ls /mnt/usb root@sheeva:/usr/src/ms-sys# cp -r /ext/reactos_files/* /mnt/usb root@sheeva:/usr/src/ms-sys# ls /mnt/usb ReactOS/ freeldr.ini* freeldr.sys* root@sheeva:/usr/src/ms-sys# umount /mnt/usb root@sheeva:/usr/src/ms-sys#

11 years, 8 months

1
0
0 0

(no subject)

by Александр

11 years, 8 months

1
1
0 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