Re: [ros-dev] [ros-diffs] [reactos] 06/12: [EXT2] Correctly zero memory before using it
This is 3rd party code. Can you surround it with #ifdef __REACTOS__? Le 01/04/2019 à 17:08, Hervé Poussineau a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=76910c358f7197a6b8e283ea267faf7b5c1812ff > > commit 76910c358f7197a6b8e283ea267faf7b5c1812ff > Author: Hervé Poussineau > AuthorDate: Sat Mar 30 23:06:27 2019 +0100 > Commit: Hervé Poussineau > CommitDate: Mon Apr 1 11:38:32 2019 +0200 > > [EXT2] Correctly zero memory before using it > --- > drivers/filesystems/ext2/src/memory.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/filesystems/ext2/src/memory.c > b/drivers/filesystems/ext2/src/memory.c > index 8915dfeccb..cf569f40cd 100644 > --- a/drivers/filesystems/ext2/src/memory.c > +++ b/drivers/filesystems/ext2/src/memory.c > @@ -2072,9 +2072,9 @@ Ext2ParseRegistryVolumeParams( > > USHORT i, j, k; > > -RtlZeroMemory(Codepage, CODEPAGE_MAXLEN); > -RtlZeroMemory(Prefix, HIDINGPAT_LEN); > -RtlZeroMemory(Suffix, HIDINGPAT_LEN); > +RtlZeroMemory(Codepage, sizeof(WCHAR) * CODEPAGE_MAXLEN); > +RtlZeroMemory(Prefix, sizeof(WCHAR) * HIDINGPAT_LEN); > +RtlZeroMemory(Suffix, sizeof(WCHAR) * HIDINGPAT_LEN); > RtlZeroMemory(MountPoint, sizeof(USHORT) * 4); > RtlZeroMemory(DrvLetter, sizeof(CHAR) * 4); > > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [reactos] 01/01: [FREETYPE] Fix 3 regressions in one patch
LT_CHARSET && LogFont->lfCharSet !=
> lf.lfCharSet)
> -continue;
>
> -IntLockGlobalFonts();
> -GetFontFamilyInfoForList(, Info, pFromW->Buffer, pCount,
> MaxCount, _FontListHead);
> -IntUnLockGlobalFonts();
> +RtlInitUnicodeString(, lf.lfFaceName);
> +FontGDI = FindFaceNameInLists();
> +if (FontGDI == NULL)
> +{
> +continue; /* no real font */
> +}
>
> -IntLockProcessPrivateFonts(Win32Process);
> -GetFontFamilyInfoForList(, Info, pFromW->Buffer, pCount, MaxCount,
> - >PrivateFontListHead);
> -IntUnLockProcessPrivateFonts(Win32Process);
> -break;
> +if (*pCount < MaxCount)
> + {
> +FontFamilyFillInfo([*pCount], pFromW->Buffer, NULL,
> FontGDI);
> +}
> +(*pCount)++;
> }
>
> return TRUE;
> @@ -5426,7 +5534,7 @@ NtGdiGetFontFamilyInfo(HDC Dc,
> /* Enumerate font families in the global list */
> IntLockGlobalFonts();
> Count = 0;
> -if (! GetFontFamilyInfoForList(, Info, NULL, , Size,
> _FontListHead) )
> +if (! GetFontFamilyInfoForList(, Info, , Size,
> _FontListHead) )
> {
> IntUnLockGlobalFonts();
> ExFreePoolWithTag(Info, GDITAG_TEXT);
> @@ -5437,7 +5545,7 @@ NtGdiGetFontFamilyInfo(HDC Dc,
> /* Enumerate font families in the process local list */
> Win32Process = PsGetCurrentProcessWin32Process();
> IntLockProcessPrivateFonts(Win32Process);
> -if (! GetFontFamilyInfoForList(, Info, NULL, , Size,
> +if (! GetFontFamilyInfoForList(, Info, , Size,
> >PrivateFontListHead))
> {
> IntUnLockProcessPrivateFonts(Win32Process);
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [reactos] 01/01: [CDFS] Make windows gcc release build compile, regression CORE-15659
Your #endif is misplaced. INLINE is part of the original source code. Le 22/01/2019 à 18:50, Joachim Henze a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=bccad87f3ccf266be2179d1322e7a422aeb2f3b7 > > commit bccad87f3ccf266be2179d1322e7a422aeb2f3b7 > Author: Joachim Henze > AuthorDate: Tue Jan 22 18:49:51 2019 +0100 > Commit: Joachim Henze > CommitDate: Tue Jan 22 18:49:51 2019 +0100 > > [CDFS] Make windows gcc release build compile, regression CORE-15659 > --- > drivers/filesystems/cdfs/cdprocs.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/filesystems/cdfs/cdprocs.h > b/drivers/filesystems/cdfs/cdprocs.h > index 1d788b28e1..4cff63837a 100644 > --- a/drivers/filesystems/cdfs/cdprocs.h > +++ b/drivers/filesystems/cdfs/cdprocs.h > @@ -1836,7 +1836,10 @@ CdRaiseStatusEx ( > > #else > > +#ifdef __REACTOS__ > +static // make windows gcc release build compile > INLINE > +#endif > DECLSPEC_NORETURN > VOID > CdRaiseStatusEx( > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Web services down
We seem to be back to normal state. Please report if some service is still not working properly. Pierre Schweitzer wrote on Wed, December 26th, 2018, 4:43 PM: > Dear all, > > Due to an unexpected outage touching our hoster infrastructure, our DB server > is currently down and it affects all the web services relying on it. So, > don't expect Jira, boards, wiki, website, and so on to work properly for now, > I'll keep you informed when I have more information. > > Cheers, > Pierre > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://reactos.org/mailman/listinfo/ros-dev
[ros-dev] Web services down
Dear all, Due to an unexpected outage touching our hoster infrastructure, our DB server is currently down and it affects all the web services relying on it. So, don't expect Jira, boards, wiki, website, and so on to work properly for now, I'll keep you informed when I have more information. Cheers, Pierre ___ Ros-dev mailing list Ros-dev@reactos.org http://reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [reactos] 01/01: [DESK][SHELL32] Allow Desk.cpl to run standalone on WinXP/2003 again CORE-15412
+goto cleanup;
> +}
> +pwszTempBuffer = HeapAlloc(GetProcessHeap(), 0, cbData);
> +if (!pwszTempBuffer)
> +{
> +result = ERROR_NOT_ENOUGH_MEMORY;
> +goto cleanup;
> +}
> +result = RegQueryValueExW(hKey, pszValue, NULL, ,
> (LPBYTE)pwszTempBuffer, );
> +if (result != ERROR_SUCCESS) goto cleanup;
> +
> +/* Expand environment variables, if appropriate, or copy the original
> string over. */
> +if (dwValueType == REG_EXPAND_SZ)
> +{
> +cbData = ExpandEnvironmentStringsW(pwszTempBuffer, NULL, 0) *
> sizeof(WCHAR);
> +if (!cbData) goto cleanup;
> +pwszExpandedBuffer = HeapAlloc(GetProcessHeap(), 0, cbData);
> +if (!pwszExpandedBuffer)
> +{
> +result = ERROR_NOT_ENOUGH_MEMORY;
> +goto cleanup;
> +}
> +ExpandEnvironmentStringsW(pwszTempBuffer, pwszExpandedBuffer,
> cbData);
> +}
> +else
> +{
> +pwszExpandedBuffer = HeapAlloc(GetProcessHeap(), 0, cbData);
> +memcpy(pwszExpandedBuffer, pwszTempBuffer, cbData);
> +}
> +
> +/* If the value references a resource based string, parse the value and
> load the string.
> + * Else just copy over the original value. */
> +result = ERROR_SUCCESS;
> +if (*pwszExpandedBuffer != L'@') /* '@' is the prefix for resource based
> string entries. */
> +{
> +lstrcpynW(pszOutBuf, pwszExpandedBuffer, cbOutBuf / sizeof(WCHAR));
> +}
> +else
> +{
> +WCHAR *pComma = wcsrchr(pwszExpandedBuffer, L',');
> +UINT uiStringId;
> +HMODULE hModule;
> +
> +/* Format of the expanded value is 'path_to_dll,-resId' */
> +if (!pComma || pComma[1] != L'-')
> +{
> +result = ERROR_BADKEY;
> +goto cleanup;
> +}
> +
> +uiStringId = _wtoi(pComma+2);
> +*pComma = L'\0';
> +
> +hModule = LoadLibraryExW(pwszExpandedBuffer + 1, NULL,
> LOAD_LIBRARY_AS_DATAFILE);
> +if (!hModule || !load_string(hModule, uiStringId, pszOutBuf,
> cbOutBuf / sizeof(WCHAR)))
> +result = ERROR_BADKEY;
> +FreeLibrary(hModule);
> +}
> +
> +cleanup:
> +HeapFree(GetProcessHeap(), 0, pwszTempBuffer);
> +HeapFree(GetProcessHeap(), 0, pwszExpandedBuffer);
> +return result;
> +}
> +
> +/********
> + * RegLoadMUIStringA
> + *
> + * @implemented
> + */
> +LONG WINAPI
> +RegLoadMUIStringA(IN HKEY hKey,
> + IN LPCSTR pszValue OPTIONAL,
> + OUT LPSTR pszOutBuf,
> + IN DWORD cbOutBuf,
> + OUT LPDWORD pcbData OPTIONAL,
> + IN DWORD Flags,
> + IN LPCSTR pszDirectory OPTIONAL)
> +{
> +UNICODE_STRING valueW, baseDirW;
> +WCHAR *pwszBuffer;
> +DWORD cbData = cbOutBuf * sizeof(WCHAR);
> +LONG result;
> +
> +valueW.Buffer = baseDirW.Buffer = pwszBuffer = NULL;
> +if (!RtlCreateUnicodeStringFromAsciiz(, pszValue) ||
> +!RtlCreateUnicodeStringFromAsciiz(, pszDirectory) ||
> +!(pwszBuffer = HeapAlloc(GetProcessHeap(), 0, cbData)))
> +{
> +result = ERROR_NOT_ENOUGH_MEMORY;
> +goto cleanup;
> +}
> +
> +result = RegLoadMUIStringW(hKey, valueW.Buffer, pwszBuffer, cbData,
> NULL, Flags,
> + baseDirW.Buffer);
> +
> +if (result == ERROR_SUCCESS)
> +{
> +cbData = WideCharToMultiByte(CP_ACP, 0, pwszBuffer, -1, pszOutBuf,
> cbOutBuf, NULL, NULL);
> +if (pcbData)
> +*pcbData = cbData;
> +}
> +
> +cleanup:
> +HeapFree(GetProcessHeap(), 0, pwszBuffer);
> +RtlFreeUnicodeString();
> +RtlFreeUnicodeString();
> +
> +return result;
> +}
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 03/03: [OLE32] The CoDisconnectContext() stub added in 6a2f9673 (PR #1044) is actually Vista+. Caught by Thomas Faber.
I'm not sure I understand this commit, nor the PR that was merged before. This is a synced module, for a Vista+ export... What's the point of this? It would have been better to sync with Wine and have this patch upstream. Le 18/11/2018 à 21:03, Hermès Bélusca-Maïto a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=2d320f5a8daf4627458e81f0ffd51bdd8f60d120 > > commit 2d320f5a8daf4627458e81f0ffd51bdd8f60d120 > Author: Hermès Bélusca-Maïto > AuthorDate: Sun Nov 18 21:05:32 2018 +0100 > Commit: Hermès Bélusca-Maïto > CommitDate: Sun Nov 18 21:06:22 2018 +0100 > > [OLE32] The CoDisconnectContext() stub added in 6a2f9673 (PR #1044) is > actually Vista+. Caught by Thomas Faber. > --- > dll/win32/ole32/ole32.spec | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dll/win32/ole32/ole32.spec b/dll/win32/ole32/ole32.spec > index d4ed1163d4..97667918e9 100644 > --- a/dll/win32/ole32/ole32.spec > +++ b/dll/win32/ole32/ole32.spec > @@ -23,7 +23,7 @@ > # CoCreateObjectInContext > # CoDeactivateObject > @ stdcall -stub CoDisableCallCancellation(ptr) > -@ stdcall -stub CoDisconnectContext(long) > +@ stdcall -stub -version=0x600+ CoDisconnectContext(long) > @ stdcall CoDisconnectObject(ptr long) > @ stdcall CoDosDateTimeToFileTime(long long ptr) > kernel32.DosDateTimeToFileTime > @ stdcall -stub CoEnableCallCancellation(ptr) > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [SERVICES] Fix timeout when a service is stopped
Hey Eric,
What's the purpose of that "Sleep(2000);"? Is it a debug leftover?
Cheers,
Pierre
Le 05/10/2018 à 08:43, Eric Kohl a écrit :
> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=f6d81f225747e4b1b3716e9ca8629f77dcc52b1a
>
> commit f6d81f225747e4b1b3716e9ca8629f77dcc52b1a
> Author: Eric Kohl
> AuthorDate: Fri Oct 5 08:41:23 2018 +0200
> Commit: Eric Kohl
> CommitDate: Fri Oct 5 08:41:23 2018 +0200
>
> [SERVICES] Fix timeout when a service is stopped
>
> RSetServiceStatus: Send the stop command for the dispatcher thread from a
> separate thread.
>
> Fixes CORE-15064
> ---
> base/system/services/rpcserver.c | 59
> ++--
> 1 file changed, 50 insertions(+), 9 deletions(-)
>
> diff --git a/base/system/services/rpcserver.c
> b/base/system/services/rpcserver.c
> index 7f251c8760..8e383a5bdc 100644
> --- a/base/system/services/rpcserver.c
> +++ b/base/system/services/rpcserver.c
> @@ -1671,6 +1671,43 @@ ScmIsValidServiceState(DWORD dwCurrentState)
> }
>
>
> +static
> +DWORD
> +WINAPI
> +ScmStopThread(
> +_In_ PVOID pParam)
> +{
> +PSERVICE pService;
> +
> +DPRINT("ScmStopThread(%p)\n", pParam);
> +
> +pService = (PSERVICE)pParam;
> +
> +if (pService->lpImage->dwImageRunCount != 0)
> +return 0;
> +
> +Sleep(2000);
> +
> +/* Lock the service database exclusively */
> +ScmLockDatabaseExclusive();
> +
> +/* Stop the dispatcher thread */
> +ScmControlService(pService->lpImage->hControlPipe,
> + L"",
> + (SERVICE_STATUS_HANDLE)pService,
> + SERVICE_CONTROL_STOP);
> +
> +/* Remove the service image */
> +ScmRemoveServiceImage(pService->lpImage);
> +
> +/* Unlock the service database */
> +ScmUnlockDatabase();
> +
> +DPRINT("ScmStopThread done!\n");
> +return 0;
> +}
> +
> +
> /* Function 7 */
> DWORD
> WINAPI
> @@ -1683,6 +1720,8 @@ RSetServiceStatus(
> DWORD dwPreviousType;
> LPCWSTR lpLogStrings[2];
> WCHAR szLogBuffer[80];
> +HANDLE hStopThread = NULL;
> +DWORD dwStopThreadId;
> UINT uID;
>
> DPRINT("RSetServiceStatus() called\n");
> @@ -1762,15 +1801,17 @@ RSetServiceStatus(
> /* If we just stopped the last running service... */
> if (lpService->lpImage->dwImageRunCount == 0)
> {
> -/* Stop the dispatcher thread */
> -ScmControlService(lpService->lpImage->hControlPipe,
> - L"",
> - (SERVICE_STATUS_HANDLE)lpService,
> - SERVICE_CONTROL_STOP);
> -
> -/* Remove the service image */
> -ScmRemoveServiceImage(lpService->lpImage);
> -lpService->lpImage = NULL;
> + /* Run the stop thread to stop the service dispatcher */
> + hStopThread = CreateThread(NULL,
> + 0,
> + (LPTHREAD_START_ROUTINE)ScmStopThread,
> + (LPVOID)lpService,
> + 0,
> + );
> + if (hStopThread != NULL)
> + {
> + CloseHandle(hStopThread);
> + }
> }
> }
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [ADVAPI32][SERVICES] Add (dummy) password encryption/decryption functions to CreateServiceA/W and ChangeServiceConfigA/W in order to prepare to pass encrypted password
Hi Eric,
For security reason, when freeing your password buffers (see below), you
shouldn't be using ZeroMemory() before free, but SecureZeroMemory() to
zero the buffer. The first one can be optimized (and thus removed) by
the compiler. The second cannot.
Cheers,
Pierre
Le 17/09/2018 à 16:36, Eric Kohl a écrit :
> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=5e2c4657ca10dea1154cb43f16ee6962999ac7a4
>
> commit 5e2c4657ca10dea1154cb43f16ee6962999ac7a4
> Author: Eric Kohl
> AuthorDate: Mon Sep 17 16:34:48 2018 +0200
> Commit: Eric Kohl
> CommitDate: Mon Sep 17 16:34:48 2018 +0200
>
> [ADVAPI32][SERVICES] Add (dummy) password encryption/decryption functions
> to CreateServiceA/W and ChangeServiceConfigA/W in order to prepare to pass
> encrypted passwords to the service manager
> ---
> base/system/services/config.c| 24
> base/system/services/rpcserver.c | 49 ++--
> base/system/services/services.h | 7 +++
> dll/win32/advapi32/service/scm.c | 123
> ---
> 4 files changed, 177 insertions(+), 26 deletions(-)
>
> diff --git a/base/system/services/rpcserver.c
> b/base/system/services/rpcserver.c
> index aa64233350..454181bb66 100644
> --- a/base/system/services/rpcserver.c
> +++ b/base/system/services/rpcserver.c
> @@ -2216,12 +2232,23 @@ RChangeServiceConfigW(
> dwError = ERROR_SUCCESS;
>
> if (dwError != ERROR_SUCCESS)
> +{
> +DPRINT1("ScmSetServicePassword failed (Error %lu)\n",
> dwError);
> goto done;
> +}
> }
> }
> }
>
> done:
> +if (lpClearTextPassword != NULL)
> +{
> +/* Wipe and release the password buffer */
> +ZeroMemory(lpClearTextPassword,
> + (wcslen(lpClearTextPassword) + 1) * sizeof(WCHAR));
> +HeapFree(GetProcessHeap(), 0, lpClearTextPassword);
> +}
> +
> if (hServiceKey != NULL)
> RegCloseKey(hServiceKey);
>
> @@ -2612,6 +2645,14 @@ done:
> if (hServiceKey != NULL)
> RegCloseKey(hServiceKey);
>
> +if (lpClearTextPassword != NULL)
> +{
> +/* Wipe and release the password buffer */
> +ZeroMemory(lpClearTextPassword,
> + (wcslen(lpClearTextPassword) + 1) * sizeof(WCHAR));
> + HeapFree(GetProcessHeap(), 0, lpClearTextPassword);
> +}
> +
> if (dwError == ERROR_SUCCESS)
> {
> DPRINT("hService %p\n", hServiceHandle);
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [NTOS:MM] Fix paged pool expansion
Hi Timo et al., To make the issue wider known than just me comment on GitHub. That commit introduced a regression. Le 20/08/2018 à 18:07, Timo Kreuzer a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=c219be9409af429909b1433da536516b3c3ab823 > > commit c219be9409af429909b1433da536516b3c3ab823 > Author: Timo Kreuzer > AuthorDate: Sun Feb 4 19:20:56 2018 +0100 > Commit: Timo Kreuzer > CommitDate: Mon Aug 20 18:07:35 2018 +0200 > > [NTOS:MM] Fix paged pool expansion > --- > ntoskrnl/mm/ARM3/pool.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/ntoskrnl/mm/ARM3/pool.c b/ntoskrnl/mm/ARM3/pool.c > index 7cebabe818..113a7aa981 100644 > --- a/ntoskrnl/mm/ARM3/pool.c > +++ b/ntoskrnl/mm/ARM3/pool.c > @@ -561,10 +565,11 @@ MiAllocatePoolPages(IN POOL_TYPE PoolType, > MiInitializePfnForOtherProcess(PageFrameNumber, > (PMMPTE)PointerPde, > > MmSystemPageDirectory[(PointerPde - MiAddressToPde(NULL)) / PDE_COUNT]); > +#endif > > /* Write the actual PDE now */ > -//MI_WRITE_VALID_PDE(PointerPde, TempPde); > -#endif > +MI_WRITE_VALID_PDE(PointerPde, TempPde); > + That little change for x86 actually breaks VBox support. It hits an ASSERT during 3rd stage: *** Assertion failed: PointerPde->u.Hard.Valid == 0 *** Source File: /srv/buildbot/Build_GCCLin_x86/build/ntoskrnl/mm/ARM3/miarm.h, line 975 See testbots for instance: https://build.reactos.org/builders/Test%20VBox/builds/8625/steps/test/logs/stdio Cheers, Pierre -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [CONFIGURE] Added support for new VS 19.15.x
Formatting is inconsistent now. Tab vs space issue. Le 16/08/2018 à 17:14, Oleksandr Shaposhnikov a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=c8d51bb87a92457f7356fb6cd3488cd0db3b4b5c > > commit c8d51bb87a92457f7356fb6cd3488cd0db3b4b5c > Author: Oleksandr Shaposhnikov > AuthorDate: Thu Aug 16 18:11:53 2018 +0300 > Commit: Oleksandr Shaposhnikov > CommitDate: Thu Aug 16 18:13:54 2018 +0300 > > [CONFIGURE] Added support for new VS 19.15.x > --- > configure.cmd | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.cmd b/configure.cmd > index 70b0f48211..bacc75a743 100755 > --- a/configure.cmd > +++ b/configure.cmd > @@ -71,6 +71,7 @@ if defined ROS_ARCH ( > cl 2>&1 | find "19.12." > NUL && set VS_VERSION=15 > cl 2>&1 | find "19.13." > NUL && set VS_VERSION=15 > cl 2>&1 | find "19.14." > NUL && set VS_VERSION=15 > + cl 2>&1 | find "19.15." > NUL && set VS_VERSION=15 > if not defined VS_VERSION ( > echo Error: Visual Studio version too old ^(before 10 ^(2010^)^) or > version detection failed. > goto quit > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [WIN32SS] Fix NtUserGetClipboardData for text paste (#645)
For the record, that commit seems to have broken ReactOS testing (see
testman, which records last successful test run for 2170901, ie,
previous commit).
Starting with that commit, any regression test run never ends.
It seems bug reports have been creating regarding regressions (timeouts)
in the tests but got ignored so far.
It would be great to fix these before pushing any other commits.
Cheers,
Pierre
Le 30/06/2018 à 17:12, Katayama Hirofumi MZ a écrit :
> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=6abc9f5b5af6cc7b7c57ff9c6bcc4a919cf85d1e
>
> commit 6abc9f5b5af6cc7b7c57ff9c6bcc4a919cf85d1e
> Author: Katayama Hirofumi MZ
> AuthorDate: Sun Jul 1 00:12:23 2018 +0900
> Commit: Hermès BÉLUSCA - MAÏTO
> CommitDate: Sat Jun 30 17:12:23 2018 +0200
>
> [WIN32SS] Fix NtUserGetClipboardData for text paste (#645)
>
> Fix the NtUserGetClipboardData function for the synthesized text formats
> (CF_TEXT, CF_OEMTEXT and CF_UNICODETEXT).
> CORE-11471
> ---
> win32ss/user/ntuser/clipboard.c | 47
> ++---
> 1 file changed, 30 insertions(+), 17 deletions(-)
>
> diff --git a/win32ss/user/ntuser/clipboard.c b/win32ss/user/ntuser/clipboard.c
> index 92109953cc..04e5d22291 100644
> --- a/win32ss/user/ntuser/clipboard.c
> +++ b/win32ss/user/ntuser/clipboard.c
> @@ -294,8 +294,8 @@ IntAddSynthesizedFormats(PWINSTATION_OBJECT pWinStaObj)
> bHaveBm = IntIsFormatAvailable(pWinStaObj, CF_BITMAP);
> bHaveDib = IntIsFormatAvailable(pWinStaObj, CF_DIB);
>
> -/* Add CF_LOCALE format if we have CF_TEXT */
> -if (!bHaveLocale && bHaveText)
> +/* Add CF_LOCALE format if we have CF_TEXT, CF_OEMTEXT or CF_UNICODETEXT
> */
> +if (!bHaveLocale && (bHaveText || bHaveOemText || bHaveUniText))
> {
> PCLIPBOARDDATA pMemObj;
> HANDLE hMem;
> @@ -881,6 +881,7 @@ NtUserGetClipboardData(UINT fmt, PGETCLIPBDATA pgcd)
> HANDLE hRet = NULL;
> PCLIP pElement;
> PWINSTATION_OBJECT pWinStaObj;
> +UINT uSourceFmt = fmt;
>
> TRACE("NtUserGetClipboardData(%x, %p)\n", fmt, pgcd);
>
> @@ -898,18 +899,7 @@ NtUserGetClipboardData(UINT fmt, PGETCLIPBDATA pgcd)
> }
>
> pElement = IntGetFormatElement(pWinStaObj, fmt);
> -if (pElement && IS_DATA_DELAYED(pElement) && pWinStaObj->spwndClipOwner)
> -{
> -/* Send WM_RENDERFORMAT message */
> -pWinStaObj->fInDelayedRendering = TRUE;
> -co_IntSendMessage(pWinStaObj->spwndClipOwner->head.h,
> WM_RENDERFORMAT, (WPARAM)fmt, 0);
> -pWinStaObj->fInDelayedRendering = FALSE;
> -
> -/* Data should be in clipboard now */
> -pElement = IntGetFormatElement(pWinStaObj, fmt);
> -}
> -
> -if (!pElement || IS_DATA_DELAYED(pElement))
> +if (!pElement)
> goto cleanup;
>
> if (IS_DATA_SYNTHESIZED(pElement))
> @@ -921,20 +911,43 @@ NtUserGetClipboardData(UINT fmt, PGETCLIPBDATA pgcd)
> case CF_UNICODETEXT:
> case CF_TEXT:
> case CF_OEMTEXT:
> -pElement = IntGetFormatElement(pWinStaObj, CF_UNICODETEXT);
> +uSourceFmt = CF_UNICODETEXT;
> +pElement = IntGetFormatElement(pWinStaObj, uSourceFmt);
> if (IS_DATA_SYNTHESIZED(pElement))
> -pElement = IntGetFormatElement(pWinStaObj, CF_TEXT);
> +{
> +uSourceFmt = CF_TEXT;
> +pElement = IntGetFormatElement(pWinStaObj, uSourceFmt);
> +}
> if (IS_DATA_SYNTHESIZED(pElement))
> -pElement = IntGetFormatElement(pWinStaObj, CF_OEMTEXT);
> +{
> +uSourceFmt = CF_OEMTEXT;
> +pElement = IntGetFormatElement(pWinStaObj, uSourceFmt);
> +}
> break;
> +
> case CF_BITMAP:
> IntSynthesizeBitmap(pWinStaObj, pElement);
> break;
> +
> default:
> ASSERT(FALSE);
> }
> }
>
> +if (pElement && IS_DATA_DELAYED(pElement) && pWinStaObj->spwndClipOwner)
> +{
> +/* Send WM_RENDERFORMAT message */
> +pWinStaObj->fInDelayedRendering = TRUE;
> +co_IntSendMessage(pWinStaObj->spwndClipOwner->head.h,
> WM_RENDERFORMAT, (WPARAM)uSourceFmt, 0);
> +pWinStaObj->fInDelayedRendering = FALSE;
> +
> +/* Data should be in clipboard now */
> +pElement = IntGetFormatElement(pWinStaObj, uSourceFmt);
> +}
> +
> +
Re: [ros-dev] Microsoft acquires GitHub
Let's no be paranoid and make plans out of nothing please... And if Microsoft are that evil, why are you using their mail services? Le 05/06/2018 à 19:43, M. Ziggyesque a écrit : > No, I don't see it as pointless to have a plan B. It's more a question of > when, not if, it's desirable, given past practices. > > Even with no immediate changes, github can no longer be considered > vendor-neutral. Down the road, as example, M$ may well try to require every > project adopt their code-signing policy or the project gets deleted, so they > get their kickbacks on all the certificate fees that would entail. ROS > doesn't require code-signing?? DELETE!! They did similar when they bought out > sysinternals, bloated all their utilities with certificates, so that's a > distinct possibility. > > While migrating the repo itself is easy, the issues list and other history is > less so, plus the hassle of getting links on external pages to redirect to a > new home; those would take some lead time so imo is better to have some plan > than not. > > -- Original message-- > From: David Quintana (gigaherz) > Date: Tue, Jun 5, 2018 4:40 AM > To: ReactOS Development List; > Cc: > Subject:Re: [ros-dev] Microsoft acquires GitHub > > To elaborate further: > > 1. The deal won't be closed for many months (they expect december) > 2. Microsoft probably won't change github at first (xcept maybe make the > login integrate with a Microsoft Account) > 3. We don't know what they plan to do with the platform in the long term, > so worrying now is pointless. > 4. We don't know that it will EVER be hostile toward ReactOS, even if they > break the platform and make it unusable, so chances are we are good. > 5. If worst comes to worst, as Thomas said, we just say goodbye to GH and > move elsewhere. > > > On 5 June 2018 at 10:36, Javier Agustìn Fernàndez Arroyo > mailto:elh...@gmail.com>> wrote: > great! :) > > On Tue, Jun 5, 2018 at 10:34 AM, Thomas Faber > mailto:thomas.fa...@reactos.org>> wrote: > To elaborate, we're not dependent on GitHub in any significant way. It's > just convenient. But if it stops being so, it's easy to go elsewhere. > That's a key part of Git, being a "distributed" VCS. > > > On 2018-06-05 10:31, Oleksandr Shaposhnikov wrote: >> No it may not. >> >> 5 черв. 2018 р. 11:24 Javier Agustìn Fernàndez Arroyo >> mailto:elh...@gmail.com>> пише: >> >> May this affect ReactOS? >> >> >> https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/<https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.microsoft.com%2Fblog%2F2018%2F06%2F04%2Fmicrosoft-github-empowering-developers%2F=02%7C01%7C%7Ca6b7a92ca5c146e5bc5e08d5cac00cc9%7C84df9e7fe9f640afb435%7C1%7C0%7C636637848550395788=MphM9bR%2F0p14QXZQBKrHGfUK3cmOwVfNKDYXdqtBMVA%3D=0> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org<mailto:Ros-dev@reactos.org> > http://www.reactos.org/mailman/listinfo/ros-dev<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reactos.org%2Fmailman%2Flistinfo%2Fros-dev=02%7C01%7C%7Ca6b7a92ca5c146e5bc5e08d5cac00cc9%7C84df9e7fe9f640afb435%7C1%7C0%7C636637848550552040=V8%2B3DEP1VRUt2B34MdmNxVef9urlPZ8tYoamkdKQdts%3D=0> > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org<mailto:Ros-dev@reactos.org> > http://www.reactos.org/mailman/listinfo/ros-dev<https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reactos.org%2Fmailman%2Flistinfo%2Fros-dev=02%7C01%7C%7Ca6b7a92ca5c146e5bc5e08d5cac00cc9%7C84df9e7fe9f640afb435%7C1%7C0%7C636637848550552040=V8%2B3DEP1VRUt2B34MdmNxVef9urlPZ8tYoamkdKQdts%3D=0> > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 04/05: [USETUP] Enhancements for filesystem utility functions.
{
> snprintf(Buffer, sizeof(Buffer),
> MUIGetString(STRING_KEEPFORMAT));
> +}
>
> if (ListEntry == >Selected->ListEntry)
> CONSOLE_SetInvertedTextXY(List->Left,
> @@ -279,7 +384,6 @@ DrawFileSystemList(
> }
> }
>
> -
> VOID
> ScrollDownFileSystemList(
> IN PFILE_SYSTEM_LIST List)
> @@ -291,7 +395,6 @@ ScrollDownFileSystemList(
> }
> }
>
> -
> VOID
> ScrollUpFileSystemList(
> IN PFILE_SYSTEM_LIST List)
> diff --git a/base/setup/usetup/fslist.h b/base/setup/usetup/fslist.h
> index 685a2cfe2e..4433d381ba 100644
> --- a/base/setup/usetup/fslist.h
> +++ b/base/setup/usetup/fslist.h
> @@ -31,7 +31,7 @@
> typedef struct _FILE_SYSTEM_ITEM
> {
> LIST_ENTRY ListEntry;
> -LPCWSTR FileSystemName; /* Not owned by the item */
> +PCWSTR FileSystemName; /* Not owned by the item */
> FORMATEX FormatFunc;
> CHKDSKEX ChkdskFunc;
> BOOLEAN QuickFormat;
> @@ -46,16 +46,16 @@ typedef struct _FILE_SYSTEM_LIST
> } FILE_SYSTEM_LIST, *PFILE_SYSTEM_LIST;
>
> VOID
> -FS_AddProvider(
> +AddProvider(
> IN OUT PFILE_SYSTEM_LIST List,
> -IN LPCWSTR FileSystemName,
> +IN PCWSTR FileSystemName,
> IN FORMATEX FormatFunc,
> IN CHKDSKEX ChkdskFunc);
>
> PFILE_SYSTEM_ITEM
> GetFileSystemByName(
> IN PFILE_SYSTEM_LIST List,
> -IN LPWSTR FileSystemName);
> +IN PWSTR FileSystemName);
>
> struct _PARTENTRY; // Defined in partlist.h
> PFILE_SYSTEM_ITEM
> @@ -68,7 +68,7 @@ CreateFileSystemList(
> IN SHORT Left,
> IN SHORT Top,
> IN BOOLEAN ForceFormat,
> -IN LPCWSTR ForceFileSystem);
> +IN PCWSTR SelectFileSystem);
>
> VOID
> DestroyFileSystemList(
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: improve SHGetFileInfo (#118)
TR path,DWORD
> dwFileAttributes,
> }
> }
> }
> -else
> +else if (psfParent)
> {
> if (!(PidlToSicIndex(psfParent, pidlLast, !(flags &
> SHGFI_SMALLICON),
> uGilFlags, &(psfi->iIcon
> @@ -769,33 +794,25 @@ DWORD_PTR WINAPI SHGetFileInfoA(LPCSTR path,DWORD
> dwFileAttributes,
> pathW = temppath;
> }
>
> -if (psfi && (flags & SHGFI_ATTR_SPECIFIED))
> -temppsfi.dwAttributes=psfi->dwAttributes;
> +if (psfi)
> +{
> +temppsfi.hIcon = psfi->hIcon;
> +temppsfi.iIcon = psfi->iIcon;
> +temppsfi.dwAttributes = psfi->dwAttributes;
>
> -if (psfi == NULL)
> -ret = SHGetFileInfoW(pathW, dwFileAttributes, NULL, 0, flags);
> -else
> ret = SHGetFileInfoW(pathW, dwFileAttributes, ,
> sizeof(temppsfi), flags);
> +psfi->hIcon = temppsfi.hIcon;
> +psfi->iIcon = temppsfi.iIcon;
> +psfi->dwAttributes = temppsfi.dwAttributes;
>
> -if (psfi)
> -{
> -if(flags & SHGFI_ICON)
> -psfi->hIcon=temppsfi.hIcon;
> -if(flags & (SHGFI_SYSICONINDEX|SHGFI_ICON|SHGFI_ICONLOCATION))
> -psfi->iIcon=temppsfi.iIcon;
> -if(flags & SHGFI_ATTRIBUTES)
> -psfi->dwAttributes=temppsfi.dwAttributes;
> -if(flags & (SHGFI_DISPLAYNAME|SHGFI_ICONLOCATION))
> -{
> -WideCharToMultiByte(CP_ACP, 0, temppsfi.szDisplayName, -1,
> - psfi->szDisplayName, sizeof(psfi->szDisplayName), NULL,
> NULL);
> - }
> -if(flags & SHGFI_TYPENAME)
> -{
> -WideCharToMultiByte(CP_ACP, 0, temppsfi.szTypeName, -1,
> - psfi->szTypeName, sizeof(psfi->szTypeName), NULL, NULL);
> -}
> +WideCharToMultiByte(CP_ACP, 0, temppsfi.szDisplayName, -1,
> + psfi->szDisplayName, sizeof(psfi->szDisplayName), NULL, NULL);
> +
> +WideCharToMultiByte(CP_ACP, 0, temppsfi.szTypeName, -1,
> + psfi->szTypeName, sizeof(psfi->szTypeName), NULL, NULL);
> }
> +else
> +ret = SHGetFileInfoW(pathW, dwFileAttributes, NULL, 0, flags);
>
> HeapFree(GetProcessHeap(), 0, temppath);
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [NTOS:KE] Replace "Fatal System Error" with "BugCheck"
Done with e26e4445b39d7455e83e45ac7272d21289cc5106. Le 08/02/2018 à 11:29, Thomas Faber a écrit : > On 2018-02-08 01:55, Alex Ionescu wrote: >> This changes documented/external behavior. What is the point of this >> change? > > Hmm. Before approving the change I googled/tested whether Windows > produces that output but somehow didn't see it. Now that you mention it, > all versions of Windows do seem to have that exact print, so I agree we > should revert this to avoid breaking tools that scan the debug output. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] 01/01: [NTOS:KE] Replace "Fatal System Error" with "BugCheck"
Hey Alex,
The root cause of this is:
https://jira.reactos.org/browse/CORE-14293?focusedCommentId=101589=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-101589
Cheers,
Pierre
Le 08/02/2018 à 01:55, Alex Ionescu a écrit :
> This changes documented/external behavior. What is the point of this change?
> Best regards,
> Alex Ionescu
>
>
> On Wed, Feb 7, 2018 at 1:22 PM, Serge Gautherie
> <reactos-git_serge_171...@gautherie.fr> wrote:
>> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=6ece4e9fc22d664ea2485d04303e8ae10047f21f
>>
>> commit 6ece4e9fc22d664ea2485d04303e8ae10047f21f
>> Author: Serge Gautherie <reactos-git_serge_171...@gautherie.fr>
>> AuthorDate: Wed Feb 7 06:29:02 2018 +0100
>> Commit: Pierre Schweitzer <pie...@reactos.org>
>> CommitDate: Wed Feb 7 22:22:28 2018 +0100
>>
>> [NTOS:KE] Replace "Fatal System Error" with "BugCheck"
>> ---
>> ntoskrnl/ke/bug.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/ntoskrnl/ke/bug.c b/ntoskrnl/ke/bug.c
>> index a92acb1bab..2127d7207c 100644
>> --- a/ntoskrnl/ke/bug.c
>> +++ b/ntoskrnl/ke/bug.c
>> @@ -1070,8 +1070,8 @@ KeBugCheckWithTf(IN ULONG BugCheckCode,
>> if ((BugCheckCode != MANUALLY_INITIATED_CRASH) && (KdDebuggerEnabled))
>> {
>> /* Crash on the debugger console */
>> -DbgPrint("\n*** Fatal System Error: 0x%08lx\n"
>> - " (0x%p,0x%p,0x%p,0x%p)\n\n",
>> +DbgPrint("\n*** BugCheck: 0x%08lx\n"
>> + " (0x%p,0x%p,0x%p,0x%p)\n\n",
>> KiBugCheckData[0],
>> KiBugCheckData[1],
>> KiBugCheckData[2],
>>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
signature.asc
Description: OpenPGP digital signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Making bluescreens more useful
Good idea! I would just have a few suggestions to make it even more useful: - "Consider filing a ticket at https://jira.reactos.org/ if it wasn't already reported there. To do so, provide information on what..." - "Ideally, try to reproduce the problem while capturing a debug log that you should translate afterwards. See https://; Cheers, Pierre Le 11/01/2018 à 00:48, Thomas Faber a écrit : > We often get bug reports with just a screenshot of a bluescreen; we then > go ahead and tell people that bluescreens are basically useless, they > should get a debug log and a backtrace, and also remember to tell us > what version they're using. > > Since there's actually no reason why bluescreens need to be useless, I > thought I'd try to change that. > I've attached an example. The source for this quick PoC can be found at > https://github.com/ThFabba/reactos/commit/6a9f172b76bd11f763598c16e5d47299eec1971c > > Thoughts? > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. signature.asc Description: OpenPGP digital signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Regression in r75772 broke multiple disk drive support
This regression got fixed with r75911. Can you confirm it's OK on your side? Le 18/09/2017 à 22:41, Pierre Schweitzer a écrit : > Ack. See https://jira.reactos.org/browse/CORE-13805 > > Thanks for the report. > > Le 17/09/2017 à 17:39, Dimitrij Klingbeil a écrit : >> Hi all, >> >> It looks like revision 75772 (removed a "DeviceExt->OpenHandleCount--;") >> has introduced some significant unintended consequences. >> Ever since I can't get ReactOS to recognize a second hard drive. >> >> My configuration is like this: >> - ReactOS in a VirtualBox VM, VirtualBox version 5.11.18 >> - VM configured for Windows 2003 32-bit, with 1 CPU >> - Emulated Chipset: PIIX3, no USB, no Audio, no Serial >> - AMD-V active, Nested Paging active, >> - No paravirtualization interface, no guest additions >> - Emulated Storage: SATA controller with 4 ports >> - Port 0: First Hard disk (has partition C) >> - Port 1: Second Hard disk (has partition D) >> - Port 3: CDROM (to install ReactOS from, E) >> - Each hard disk has one single primary partition (FAT formatted by an >> older >> ReactOS setup) >> - On C I install ReactOS (re-formatting the partition in the process) >> - On D there is some data (a small collection of program installers to try >> out) >> >> Now, inside ReactOS I cannot see the contents of D. The drive itself shows >> up, but unformatted and of a zero size. In the revisions before 75772 there >> were no problems, I could see the drive and use the data on it. >> Re-installing r75771 shows that the drive image is OK and the data is still >> there, so it's not the data that was corrupted. >> >> If I insert a CDROM image (with ReactOS already running), the CDROM drive >> (E) suddently disappears and D now has the CDROM in it (so happened just >> now >> with r75872). When I eject the CDROM, D becomes empty but still shows the >> icon for a CDROM. E does not re-appear. >> >> 75772 looks like a very small change, but something must have gone really >> off the rails... >> >> Regards, >> Dimitrij >> >> >> >> P.S. This was at first sent from the wrong (not subscribed to the list) >> address by mistake. I think the first one was rejected by the list SW, >> but sorry if the message appears twice. >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Regression in r75772 broke multiple disk drive support
Ack. See https://jira.reactos.org/browse/CORE-13805 Thanks for the report. Le 17/09/2017 à 17:39, Dimitrij Klingbeil a écrit : > Hi all, > > It looks like revision 75772 (removed a "DeviceExt->OpenHandleCount--;") > has introduced some significant unintended consequences. > Ever since I can't get ReactOS to recognize a second hard drive. > > My configuration is like this: > - ReactOS in a VirtualBox VM, VirtualBox version 5.11.18 > - VM configured for Windows 2003 32-bit, with 1 CPU > - Emulated Chipset: PIIX3, no USB, no Audio, no Serial > - AMD-V active, Nested Paging active, > - No paravirtualization interface, no guest additions > - Emulated Storage: SATA controller with 4 ports > - Port 0: First Hard disk (has partition C) > - Port 1: Second Hard disk (has partition D) > - Port 3: CDROM (to install ReactOS from, E) > - Each hard disk has one single primary partition (FAT formatted by an > older > ReactOS setup) > - On C I install ReactOS (re-formatting the partition in the process) > - On D there is some data (a small collection of program installers to try > out) > > Now, inside ReactOS I cannot see the contents of D. The drive itself shows > up, but unformatted and of a zero size. In the revisions before 75772 there > were no problems, I could see the drive and use the data on it. > Re-installing r75771 shows that the drive image is OK and the data is still > there, so it's not the data that was corrupted. > > If I insert a CDROM image (with ReactOS already running), the CDROM drive > (E) suddently disappears and D now has the CDROM in it (so happened just > now > with r75872). When I eject the CDROM, D becomes empty but still shows the > icon for a CDROM. E does not re-appear. > > 75772 looks like a very small change, but something must have gone really > off the rails... > > Regards, > Dimitrij > > > > P.S. This was at first sent from the wrong (not subscribed to the list) > address by mistake. I think the first one was rejected by the list SW, > but sorry if the message appears twice. > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cfinck] 75630: [FS_REC] - Add a detection routine for CDFS (ISO-9660) volumes that verifies the Primary Volume Descriptor. - Use this to also detect CDFS on disks and load t
if (FsRecIsCdfsVolume(MountDevice, SectorSize))
> +{
> +/* It is! */
> +Status = STATUS_FS_DRIVER_REQUIRED;
> +}
> +}
> +
> break;
>
> case IRP_MN_LOAD_FILE_SYSTEM:
>
> Added: trunk/reactos/drivers/filesystems/fs_rec/cdfs.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec/cdfs.h?rev=75630
> ==
> --- trunk/reactos/drivers/filesystems/fs_rec/cdfs.h (added)
> +++ trunk/reactos/drivers/filesystems/fs_rec/cdfs.h [iso-8859-1] Sun Aug 20
> 15:30:59 2017
> @@ -0,0 +1,24 @@
> +/*
> + * PROJECT: ReactOS File System Recognizer
> + * LICENSE: GPL-2.0 (https://spdx.org/licenses/GPL-2.0+)
> + * PURPOSE: CDFS Recognizer
> + * COPYRIGHT: Copyright 2017 Colin Finck <co...@reactos.org>
> + */
> +
> +// Information from http://wiki.osdev.org/ISO_9660#Volume_Descriptors
> +
> +// Structures
> +typedef struct _VD_HEADER
> +{
> +char Type;
> +char Identifier[5];
> +char Version;
> +}
> +VD_HEADER, *PVD_HEADER;
> +
> +// Constants
> +#define VD_HEADER_OFFSET32768 // Offset of the VD Header
> +#define VD_IDENTIFIER "CD001" // Identifier that must be in
> the Volume Descriptor
> +#define VD_IDENTIFIER_LENGTH5 // Character count of
> VD_IDENTIFIER
> +#define VD_TYPE_PRIMARY 1 // Type code for Primary Volume
> Descriptor
> +#define VD_VERSION 1 // Volume Descriptor Version
>
> Propchange: trunk/reactos/drivers/filesystems/fs_rec/cdfs.h
> --
> svn:eol-style = native
>
> Modified: trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c?rev=75630=75629=75630=diff
> ==
> --- trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c [iso-8859-1] Sun Aug 20
> 15:30:59 2017
> @@ -316,6 +316,7 @@
> {
> ULONG DeviceCount = 0;
> NTSTATUS Status;
> +PDEVICE_OBJECT CdfsObject;
> PDEVICE_OBJECT UdfsObject;
> PAGED_CODE();
>
> @@ -340,14 +341,24 @@
> DriverObject->MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL] = FsRecFsControl;
> DriverObject->DriverUnload = FsRecUnload;
>
> -/* Register CDFS */
> -Status = FsRecRegisterFs(DriverObject,
> - NULL,
> - NULL,
> +/* Register CDFS for CDs */
> +Status = FsRecRegisterFs(DriverObject,
> + NULL,
> + ,
> L"\\Cdfs",
> L"\\FileSystem\\CdfsRecognizer",
> FS_TYPE_CDFS,
> FILE_DEVICE_CD_ROM_FILE_SYSTEM);
> +if (NT_SUCCESS(Status)) DeviceCount++;
> +
> +/* Register CDFS for HDDs */
> +Status = FsRecRegisterFs(DriverObject,
> + CdfsObject,
> + NULL,
> + L"\\CdfsHdd",
> + L"\\FileSystem\\CdfsHddRecognizer",
> + FS_TYPE_CDFS,
> + FILE_DEVICE_DISK_FILE_SYSTEM);
> if (NT_SUCCESS(Status)) DeviceCount++;
>
> /* Register UDFS for CDs */
>
> Modified: trunk/reactos/drivers/filesystems/fs_rec/udfs.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec/udfs.c?rev=75630=75629=75630=diff
> ==
> --- trunk/reactos/drivers/filesystems/fs_rec/udfs.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fs_rec/udfs.c [iso-8859-1] Sun Aug 20
> 15:30:59 2017
> @@ -125,7 +125,7 @@
> MountDevice = Stack->Parameters.MountVolume.DeviceObject;
> if (FsRecGetDeviceSectorSize(MountDevice, ))
> {
> -/* Check if it's an actual FAT volume */
> +/* Check if it's an actual UDF volume */
> if (FsRecIsUdfsVolume(MountDevice, SectorSize))
> {
> /* It is! */
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 72922: [KD] - When enabling or disabling the kernel debugger and setting the KdDebuggerEnabled flag, also update the corresponding user-mode flag in SharedUserData
Le 06/10/2016 à 21:01, hbelu...@svn.reactos.org a écrit :
> Author: hbelusca
> Date: Thu Oct 6 19:01:33 2016
> New Revision: 72922
>
> URL: http://svn.reactos.org/svn/reactos?rev=72922=rev
> Log:
> [KD]
> - When enabling or disabling the kernel debugger and setting the
> KdDebuggerEnabled flag, also update the corresponding user-mode flag in
> SharedUserData->KdDebuggerEnabled.
> - Turn KdpGetMemorySizeInMBs into a INIT_FUNCTION.
> - Print kernel command line & ARC paths even in debug log file mode.
>
> [KD64]
> WinKD: Also print our nice ReactOS debug header (version, # of processors &
> memory MB, kernel command line and ARC paths).
>
> Modified:
> trunk/reactos/ntoskrnl/kd/kdinit.c
> trunk/reactos/ntoskrnl/kd/kdio.c
> trunk/reactos/ntoskrnl/kd/kdmain.c
> trunk/reactos/ntoskrnl/kd64/kdapi.c
> trunk/reactos/ntoskrnl/kd64/kdinit.c
>
> Modified: trunk/reactos/ntoskrnl/kd/kdio.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kd/kdio.c?rev=72922=72921=72922=diff
> ==
> --- trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/kd/kdio.c [iso-8859-1] Thu Oct 6 19:01:33 2016
> @@ -240,10 +243,15 @@
> KeInitializeSpinLock();
>
> /* Display separator + ReactOS version at start of the debug log */
> -
> DPRINT1("---\n");
> +DPRINT1("-\n");
This specific change has likely broken any testbot running sysreg2 and
vmware or vbox.
Why was this change even needed?
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [dchapyshev] 72835: [NTOS:FSRTL] Rework FsRtlIsNameInExpressionPrivate for correct parsing some expressions * Fixes 1 test for kmtest:FsRtlExpression and 15 tests for kernel3
gt; +{
> +if (Name->Buffer[Position] == L'.')
> +{
> +DontSkipDot = FALSE;
> +break;
> +}
> +}
> +}
> +
> +if (EndOfName || Name->Buffer[NamePosition] != L'.' ||
> !DontSkipDot)
> +BackTracking[BackTrackingPosition++] =
> ExpressionPosition * 2;
> +
> +BackTracking[BackTrackingPosition++] =
> (ExpressionPosition * 2) + 3;
> +continue;
> +}
> +/* Check DOS_DOT */
> +else if (Expression->Buffer[ExpressionPosition /
> sizeof(WCHAR)] == DOS_DOT)
> +{
> +if (EndOfName) continue;
> +
> +if (Name->Buffer[NamePosition] == L'.')
> +BackTracking[BackTrackingPosition++] =
> (ExpressionPosition + sizeof(WCHAR)) * 2;
> +}
> +/* Check DOS_QM */
> +else if (Expression->Buffer[ExpressionPosition /
> sizeof(WCHAR)] == DOS_QM)
> +{
> +if (EndOfName || Name->Buffer[NamePosition] == L'.')
> continue;
> +
> +BackTracking[BackTrackingPosition++] =
> (ExpressionPosition + sizeof(WCHAR)) * 2;
> +}
> +
> +/* Leave from loop */
> break;
> }
> -ExpressionPosition++;
> -}
> -}
> -
> - if (BackTracking != BackTrackingBuffer)
> -{
> +
> +for (Position = 0; MatchingChars > OldBackTrackingPosition &&
> Position < BackTrackingPosition; Position++)
> +{
> +while (MatchingChars > OldBackTrackingPosition &&
> + BackTracking[Position] >
> OldBackTracking[OldBackTrackingPosition])
> +{
> +++OldBackTrackingPosition;
> +}
> +}
> +}
> +
> +/* Swap pointers */
> +BackTrackingSwap = BackTracking;
> +BackTracking = OldBackTracking;
> +OldBackTracking = BackTrackingSwap;
> +}
> +
> +/* Store result value */
> +Result = (OldBackTracking[MatchingChars - 1] == (Expression->Length *
> 2));
> +
> +/* Frees the memory if necessary */
> +if (BackTracking != BackTrackingBuffer && BackTracking !=
> OldBackTrackingBuffer)
> ExFreePoolWithTag(BackTracking, 'nrSF');
> -}
> -if (DosBackTracking != DosBackTrackingBuffer)
> -{
> -ExFreePoolWithTag(DosBackTracking, 'nrSF');
> -}
> -
> -return (ExpressionPosition == Expression->Length / sizeof(WCHAR) &&
> NamePosition == Name->Length / sizeof(WCHAR));
> +if (OldBackTracking != BackTrackingBuffer && OldBackTracking !=
> OldBackTrackingBuffer)
> +ExFreePoolWithTag(OldBackTracking, 'nrSF');
> +
> +return Result;
> }
>
> /* PUBLIC FUNCTIONS
> **/
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 72435: [KDGDB] - Implement setting and removing breakpoints - Implement single-stepping - Only get past the breakpoint instruction when it comes from RtlpBreakWithS
Sorry, I had forgotten this:
Le 23/08/2016 à 00:24, jgar...@svn.reactos.org a écrit :
> Author: jgardou
> Date: Mon Aug 22 22:24:30 2016
> New Revision: 72435
>
> URL: http://svn.reactos.org/svn/reactos?rev=72435=rev
> Log:
> [KDGDB]
> - Implement setting and removing breakpoints
> - Implement single-stepping
> - Only get past the breakpoint instruction when it comes from
> RtlpBreakWithStatus
> - Implement writing to memory
> - Always send the thread raising the exception to GDB to avoid confusing it
> - Let GDB find the program counter alone by querying the registers (support
> was already there before.)
> - Properly escape special characters on input
> Ladies and gentlemen : the almost-fully functional GDB stub. (still no real
> multi-process support :-( )
> To enable , in CMakeCache.txt :
> - Set GDB:BOOL=TRUE
> - Set _WINKD_:BOOL=TRUE
> - Set KDBG:BOOL=FALSE
> To do : give GDB the list of loaded drivers. Loading ntoskrnl.exe symbols at
> 0x80801000 already does a good enough job.
> Default output is on COM1. Can be configure to any othe COM port with usual
> kernel options.
> Hope you'll like it as much as I do ;-)
>
> Modified:
> trunk/reactos/drivers/base/kdgdb/gdb_input.c
> trunk/reactos/drivers/base/kdgdb/gdb_receive.c
> trunk/reactos/drivers/base/kdgdb/gdb_send.c
> trunk/reactos/drivers/base/kdgdb/i386_sup.c
> trunk/reactos/drivers/base/kdgdb/kdcom.c
> trunk/reactos/drivers/base/kdgdb/kdgdb.h
> trunk/reactos/drivers/base/kdgdb/kdpacket.c
>
> Modified: trunk/reactos/drivers/base/kdgdb/gdb_input.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/gdb_input.c?rev=72435=72434=72435=diff
> ==
> --- trunk/reactos/drivers/base/kdgdb/gdb_input.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/base/kdgdb/gdb_input.c [iso-8859-1] Mon Aug 22
> 22:24:30 2016
> @@ -9,6 +9,11 @@
>
> /* LOCALS
> */
> static ULONG_PTR gdb_run_tid;
> +static struct
> +{
> +ULONG_PTR Address;
> +ULONG Handle;
> +} BreakPointHandles[32];
>
>
> /* GLOBALS
> /
> @@ -203,16 +208,15 @@
>
> if (!Resuming)
> {
> +/* Report the idle thread */
> +#if MONOPROCESS
> +ptr += sprintf(ptr, "1");
> +#else
> +ptr += sprintf(gdb, "p1.1");
> +#endif
That looks highly suspicious?
Shouldn't it be ptr += sprintf(ptr, "p1.1");
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 72435: [KDGDB] - Implement setting and removing breakpoints - Implement single-stepping - Only get past the breakpoint instruction when it comes from RtlpBreakWithS
;
> -*ptr++ = hex_chars[EipPtr[2] >> 4];
> -*ptr++ = hex_chars[EipPtr[2] & 0xF];
> -*ptr++ = hex_chars[EipPtr[3] >> 4];
> -*ptr++ = hex_chars[EipPtr[3] & 0xF];
> -*ptr++ = ';';
> -*ptr++ = '\0';
> -
> -return ptr;
> -}
> -
> +
>
> Modified: trunk/reactos/drivers/base/kdgdb/kdcom.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/kdcom.c?rev=72435=72434=72435=diff
> ======
> --- trunk/reactos/drivers/base/kdgdb/kdcom.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/base/kdgdb/kdcom.c [iso-8859-1] Mon Aug 22
> 22:24:30 2016
> @@ -303,7 +303,6 @@
> return KdPacketReceived;
> }
>
> -KDDBGPRINT("CpGetByte returned %u.\n", CpStatus);
> return KdPacketTimedOut;
> }
>
>
> Modified: trunk/reactos/drivers/base/kdgdb/kdgdb.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/kdgdb.h?rev=72435=72434=72435=diff
> ==
> --- trunk/reactos/drivers/base/kdgdb/kdgdb.h [iso-8859-1] (original)
> +++ trunk/reactos/drivers/base/kdgdb/kdgdb.h [iso-8859-1] Mon Aug 22
> 22:24:30 2016
> @@ -19,7 +19,7 @@
>
> #include
>
> -#define KDDEBUG /* uncomment to enable debugging this dll */
> +//#define KDDEBUG /* uncomment to enable debugging this dll */
>
> /* To undefine once https://sourceware.org/bugzilla/show_bug.cgi?id=17397 is
> resolved */
> #define MONOPROCESS 1
> @@ -83,7 +83,7 @@
> void send_gdb_packet(_In_ CHAR* Buffer);
> void send_gdb_memory(_In_ VOID* Buffer, size_t Length);
> void gdb_send_debug_io(_In_ PSTRING String, _In_ BOOLEAN WithPrefix);
> -void gdb_send_exception(BOOLEAN WithThread);
> +void gdb_send_exception(void);
> void send_gdb_ntstatus(_In_ NTSTATUS Status);
> extern const char hex_chars[];
>
> @@ -113,15 +113,18 @@
> /* arch_sup.c */
> extern void gdb_send_register(void);
> extern void gdb_send_registers(void);
> -extern char* gdb_append_pc_to_exception(_In_ PETHREAD Thread, _Inout_ char*
> ptr);
>
> /* Architecture specific defines. See ntoskrnl/include/internal/arch/ke.h */
> #ifdef _M_IX86
> +/* Handling passing over the breakpoint instruction */
> # define KdpGetContextPc(Context) \
> ((Context)->Eip)
> # define KdpSetContextPc(Context, ProgramCounter) \
> ((Context)->Eip = (ProgramCounter))
> # define KD_BREAKPOINT_SIZEsizeof(UCHAR)
> +/* Single step mode */
> +# define KdpSetSingleStep(Context) \
> +((Context)->EFlags |= EFLAGS_TF)
> #else
> # error "Please define relevant macros for your architecture"
> #endif
>
> Modified: trunk/reactos/drivers/base/kdgdb/kdpacket.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/base/kdgdb/kdpacket.c?rev=72435=72434=72435=diff
> ==
> --- trunk/reactos/drivers/base/kdgdb/kdpacket.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/base/kdgdb/kdpacket.c [iso-8859-1] Mon Aug 22
> 22:24:30 2016
> @@ -160,7 +160,7 @@
> #else
> gdb_dbg_pid = handle_to_gdb_pid(PsGetThreadProcessId(Thread));
> #endif
> -gdb_send_exception(FALSE);
> +gdb_send_exception();
> /* Next receive call will ask for the context */
> KdpManipulateStateHandler = GetContextManipulateHandler;
> break;
> @@ -394,6 +394,13 @@
> IN PSTRING MessageData,
> IN OUT PKD_CONTEXT KdContext)
> {
> +/* Override if we have some debug print from KD. */
> +if (PacketType == PACKET_TYPE_KD_DEBUG_IO)
> +{
> +send_kd_debug_io((DBGKD_DEBUG_IO*)MessageHeader->Buffer,
> MessageData);
> +return;
> +}
> +
> /* Maybe we are in a send <-> receive loop that GDB doesn't need to know
> about */
> if (KdpSendPacketHandler)
> {
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tthompson] 71945: [NTFS] *AddRun() - Don't leak RunBuffer when encountering errors. Handle exception from FsRtlAddLargeMcbEntry().
Comment inline
Le 15/07/2016 à 17:27, tthomp...@svn.reactos.org a écrit :
> Author: tthompson
> Date: Fri Jul 15 15:27:04 2016
> New Revision: 71945
>
> URL: http://svn.reactos.org/svn/reactos?rev=71945=rev
> Log:
> [NTFS]
> *AddRun() - Don't leak RunBuffer when encountering errors.
> Handle exception from FsRtlAddLargeMcbEntry().
>
> Modified:
> branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c
>
> Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c
> URL:
> http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c?rev=71945=71944=71945=diff
> ==
> --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1]
> (original)
> +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1]
> Fri Jul 15 15:27:04 2016
> @@ -88,25 +88,40 @@
> ULONGLONG NextVBN = AttrContext->Record.NonResident.LowestVCN;
>
> // Allocate some memory for the RunBuffer
> -PUCHAR RunBuffer = ExAllocatePoolWithTag(NonPagedPool,
> Vcb->NtfsInfo.BytesPerFileRecord, TAG_NTFS);
> +PUCHAR RunBuffer;
> int RunBufferOffset = 0;
>
> if (!AttrContext->Record.IsNonResident)
> return STATUS_INVALID_PARAMETER;
> +
> +RunBuffer = ExAllocatePoolWithTag(NonPagedPool,
> Vcb->NtfsInfo.BytesPerFileRecord, TAG_NTFS);
>
> // Convert the data runs to a map control block
> Status = ConvertDataRunsToLargeMCB(DataRun, , );
> if (!NT_SUCCESS(Status))
> {
> DPRINT1("Unable to convert data runs to MCB (probably ran out of
> memory)!\n");
> +ExFreePoolWithTag(RunBuffer, TAG_NTFS);
> return Status;
> }
>
> // Add newly-assigned clusters to mcb
> -FsRtlAddLargeMcbEntry(,
> - NextVBN,
> - NextAssignedCluster,
> - RunLength);
> +_SEH2_TRY{
> +if (!FsRtlAddLargeMcbEntry(,
> +NextVBN,
> + NextAssignedCluster,
> + RunLength))
> +{
> +FsRtlUninitializeLargeMcb();
> +ExFreePoolWithTag(RunBuffer, TAG_NTFS);
> +return STATUS_INSUFFICIENT_RESOURCES;
> +}
> +} _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) {
> +FsRtlUninitializeLargeMcb();
> +ExFreePoolWithTag(RunBuffer, TAG_NTFS);
> +_SEH2_YIELD(return STATUS_INSUFFICIENT_RESOURCES);
> +} _SEH2_END;
Purely cosmetic one here. You should, in your try block, call
ExRaiseStatus with the appropriate status and do the cleanup in the
exception handler. That avoids code duplication.
This also implies you don't want to force the status code, but rather
use _SEH2_GetExceptionCode().
Also note that FsRtlAddLargeMcbEntry may fail for various reasons. I
don't really know which status code to use as you have no way to know
why it failed.
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tthompson] 71968: [NTFS] +FreeClusters(). Fix a DPRINT.
Comment inline.
Le 19/07/2016 à 17:31, tthomp...@svn.reactos.org a écrit :
> Author: tthompson
> Date: Tue Jul 19 15:31:22 2016
> New Revision: 71968
>
> URL: http://svn.reactos.org/svn/reactos?rev=71968=rev
> Log:
> [NTFS]
> +FreeClusters(). Fix a DPRINT.
>
> Modified:
> branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c
> branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c
> branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/ntfs.h
>
> Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c
> URL:
> http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c?rev=71968=71967=71968=diff
> ==
> --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1]
> (original)
> +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/attrib.c [iso-8859-1]
> Tue Jul 19 15:31:22 2016
> @@ -409,6 +409,208 @@
> return TRUE;
> }
>
> +/**
> +* @name FreeClusters
> +* @implemented
> +*
> +* Shrinks the allocation size of a non-resident attribute by a given number
> of clusters.
> +* Frees the clusters from the volume's $BITMAP file as well as the
> attribute's data runs.
> +*
> +* @param Vcb
> +* Pointer to an NTFS_VCB for the destination volume.
> +*
> +* @param AttrContext
> +* Pointer to an NTFS_ATTR_CONTEXT describing the attribute from which the
> clusters will be freed.
> +*
> +* @param AttrOffset
> +* Byte offset of the destination attribute relative to its file record.
> +*
> +* @param FileRecord
> +* Pointer to a complete copy of the file record containing the attribute.
> Must be at least
> +* Vcb->NtfsInfo.BytesPerFileRecord bytes long.
> +*
> +* @param ClustersToFree
> +* Number of clusters that should be freed from the end of the data stream.
> Must be no more
> +* Than the number of clusters assigned to the attribute (HighestVCN + 1).
> +*
> +* @return
> +* STATUS_SUCCESS on success. STATUS_INVALID_PARAMETER if AttrContext
> describes a resident attribute,
> +* or if the caller requested more clusters be freed than the attribute has
> been allocated.
> +* STATUS_INSUFFICIENT_RESOURCES if ConvertDataRunsToLargeMCB() fails.
> +* STATUS_BUFFER_TOO_SMALL if ConvertLargeMCBToDataRuns() fails.
> +*
> +*
> +*/
> +NTSTATUS
> +FreeClusters(PNTFS_VCB Vcb,
> + PNTFS_ATTR_CONTEXT AttrContext,
> + ULONG AttrOffset,
> + PFILE_RECORD_HEADER FileRecord,
> + ULONG ClustersToFree)
> +{
> +NTSTATUS Status = STATUS_SUCCESS;
> +ULONG ClustersLeftToFree = ClustersToFree;
> +
> +// convert data runs to mcb
> +PUCHAR DataRun = (PUCHAR)>Record +
> AttrContext->Record.NonResident.MappingPairsOffset;
> +PNTFS_ATTR_RECORD DestinationAttribute =
> (PNTFS_ATTR_RECORD)((ULONG_PTR)FileRecord + AttrOffset);
> +LARGE_MCB DataRunsMCB;
> +ULONG NextAttributeOffset = AttrOffset + AttrContext->Record.Length;
> +PNTFS_ATTR_RECORD NextAttribute =
> (PNTFS_ATTR_RECORD)((ULONG_PTR)FileRecord + NextAttributeOffset);
> +ULONGLONG NextVBN = AttrContext->Record.NonResident.LowestVCN;
> +
> +// Allocate some memory for the RunBuffer
> +PUCHAR RunBuffer = ExAllocatePoolWithTag(NonPagedPool,
> Vcb->NtfsInfo.BytesPerFileRecord, TAG_NTFS);
> +ULONG RunBufferOffset = 0;
Two notes regarding this allocation:
- You should check allocation worked (obviously ;-));
- You should start memory work only after checking the record is not
resident.
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tthompson] 71807: [NTFS][FREELDR] Fix ReadAttribute() and NtfsReadAttribute() in the case when an attribute contains two data runs; Remove extra if statement that prevents s
Actually, this (duplicated) function looks quite poorly designed (not your fault, obviously :-p). The more you fix it, the more it seems natural that the first specific case should be integrated in the while loop for real. That would make the function more robust, with less duplicated code (and thus, less bugs :-p). GSoC note: this is not a "todo" task. This is just an open discussion about a possible improvement if some day someone's bored. Le 04/07/2016 19:02, tthomp...@svn.reactos.org a écrit : > Author: tthompson > Date: Mon Jul 4 17:02:10 2016 > New Revision: 71807 > > URL: http://svn.reactos.org/svn/reactos?rev=71807=rev > Log: > [NTFS][FREELDR] > Fix ReadAttribute() and NtfsReadAttribute() in the case when an attribute > contains two data runs; Remove extra if statement that prevents second data > run from being read after it's decoded. > > Modified: > branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c > branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c > > Modified: branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c > URL: > http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c?rev=71807=71806=71807=diff > == > --- branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c > [iso-8859-1] (original) > +++ branches/GSoC_2016/NTFS/boot/freeldr/freeldr/lib/fs/ntfs.c > [iso-8859-1] Mon Jul 4 17:02:10 2016 > @@ -320,9 +320,6 @@ > } > else > DataRunStartLCN = -1; > - > -if (*DataRun == 0) > -return AlreadyRead; > } > > while (Length > 0) > > Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c > URL: > http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c?rev=71807=71806=71807=diff > == > --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c[iso-8859-1] > (original) > +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c[iso-8859-1] > Mon Jul 4 17:02:10 2016 > @@ -384,9 +384,6 @@ > } > else > DataRunStartLCN = -1; > - > -if (*DataRun == 0) > -return AlreadyRead; > } > > while (Length > 0) > > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: Signature cryptographique S/MIME ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tthompson] 71820: [NTFS] Add ability to write to resident attributes. SetAttributeDataLength() - Check if the file is memory mapped before truncating +InternalSetResidentAtt
Le 06/07/2016 19:59, Trevor Thompson a écrit :
> Hi Pierre, thanks for the fast review! I'll respond inline.
>
> On Tue, Jul 5, 2016 at 4:39 PM, Pierre Schweitzer <pie...@reactos.org>
> wrote:
>
>> Hi,
>>
>> Comments inline.
>>
>> Le 05/07/2016 09:00, tthomp...@svn.reactos.org a écrit :
>> ==
>>> --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c
>> [iso-8859-1] (original)
>>> +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c
>> [iso-8859-1] Tue Jul 5 07:00:43 2016
>>> @@ -158,7 +157,7 @@
>>> DPRINT1("Total clusters in bitmap: %I64x\n", BitmapDataSize * 8);
>>> DPRINT1("Diff in size: %I64d B\n", ((BitmapDataSize * 8) -
>> DeviceExt->NtfsInfo.ClusterCount) * DeviceExt->NtfsInfo.SectorsPerCluster *
>> DeviceExt->NtfsInfo.BytesPerSector);
>>>
>>> -ReadAttribute(DeviceExt, DataContext, Read,
>> (PCHAR)((ULONG_PTR)BitmapData + Read), (ULONG)BitmapDataSize);
>>> +ReadAttribute(DeviceExt, DataContext, 0, (PCHAR)BitmapData,
>> (ULONG)BitmapDataSize);
>>
>> What's this change?
>>
>
> I'm getting rid of the Read variable, which isn't being used in any
> meaningful way. This just removes all references to said variable. It was
> just vestigial from this bit of code I copy-pasted from
> NtfsGetFreeClusters():
>
> /* FIXME: Totally underoptimized! */
> for (; Read < BitmapDataSize; Read +=
> DeviceExt->NtfsInfo.BytesPerSector)
> {
> ReadAttribute(DeviceExt, DataContext, Read,
> (PCHAR)((ULONG_PTR)BitmapData + Read), DeviceExt->NtfsInfo.BytesPerSector);
> }
>
> By the way, is there any reason I shouldn't heed the comment and replace
> this with a single call to ReadAttribute()?
I don't recall why I had to do it that way... Perhaps I was hitting a
bug somewhere else (perhaps read alignment issues?). But if it doesn't
regress anything, just feel free to do it properly.
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [tthompson] 71820: [NTFS] Add ability to write to resident attributes. SetAttributeDataLength() - Check if the file is memory mapped before truncating +InternalSetResidentAtt
Hi,
Comments inline.
Le 05/07/2016 09:00, tthomp...@svn.reactos.org a écrit :
> Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c
> URL:
> http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c?rev=71820=71819=71820=diff
> ==
> --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c[iso-8859-1]
> (original)
> +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/mft.c[iso-8859-1]
> Tue Jul 5 07:00:43 2016
> @@ -170,6 +172,50 @@
> return AttrRecord->Resident.ValueLength;
> }
>
> +void
> +InternalSetResidentAttributeLength(PNTFS_ATTR_CONTEXT AttrContext,
> + PFILE_RECORD_HEADER FileRecord,
> + ULONG AttrOffset,
> + ULONG DataSize)
> +{
> +ULONG EndMarker = AttributeEnd;
> +ULONG FinalMarker = FILE_RECORD_END;
> +ULONG NextAttributeOffset;
> +ULONG Offset;
> +USHORT Padding;
> +
> +DPRINT("InternalSetResidentAttributeLength( %p, %p, %lu, %lu )\n",
> AttrContext, FileRecord, AttrOffset, DataSize);
> +
> +// update ValueLength Field
> +AttrContext->Record.Resident.ValueLength = DataSize;
> +Offset = AttrOffset + FIELD_OFFSET(NTFS_ATTR_RECORD,
> Resident.ValueLength);
> +RtlCopyMemory((PCHAR)FileRecord + Offset, , sizeof(ULONG));
That part looks a bit over-engineered to me and might be simplified
(like not using an intermediate var, nor RtlCopyMemory).
Cosmetic, I'd replace PCHAR by ULONG_PTR.
Same comment goes to code below doing basically the same thing.
> +
> +// calculate the record length and end marker offset
> +AttrContext->Record.Length = DataSize +
> AttrContext->Record.Resident.ValueOffset;
> +NextAttributeOffset = AttrOffset + AttrContext->Record.Length;
> +
> +// Ensure NextAttributeOffset is aligned to an 8-byte boundary
> +if (NextAttributeOffset % 8 != 0)
> +{
> +Padding = 8 - (NextAttributeOffset % 8);
> +NextAttributeOffset += Padding;
> +AttrContext->Record.Length += Padding;
> +}
> +
> +// update the record length
> +Offset = AttrOffset + FIELD_OFFSET(NTFS_ATTR_RECORD, Length);
> +RtlCopyMemory((PCHAR)FileRecord + Offset, >Record.Length,
> sizeof(ULONG));
> +
> +// write the end marker
> +RtlCopyMemory((PCHAR)FileRecord + NextAttributeOffset, ,
> sizeof(ULONG));
> +
> +// write the final marker
> +Offset = NextAttributeOffset + sizeof(ULONG);
> +RtlCopyMemory((PCHAR)FileRecord + Offset, , sizeof(ULONG));
> +
> +FileRecord->BytesInUse = Offset + sizeof(ULONG);
> +}
>
> NTSTATUS
> SetAttributeDataLength(PFILE_OBJECT FileObject,
> @@ -179,6 +225,18 @@
> PFILE_RECORD_HEADER FileRecord,
> PLARGE_INTEGER DataSize)
> {
> +NTSTATUS Status = STATUS_SUCCESS;
> +
> +// are we truncating the file?
> +if (DataSize->QuadPart < AttributeDataLength(>Record)
Unless I'm blind, I'm not sure it builds.
> +{
> +if (!MmCanFileBeTruncated(FileObject->SectionObjectPointer,
> (PLARGE_INTEGER)))
> +{
> +DPRINT1("Can't truncate a memory-mapped file!\n");
> +return STATUS_USER_MAPPED_FILE;
> +}
> +}
> +
> if (AttrContext->Record.IsNonResident)
> {
> ULONG BytesPerCluster = Fcb->Vcb->NtfsInfo.BytesPerCluster;
> Modified: branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c
> URL:
> http://svn.reactos.org/svn/reactos/branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c?rev=71820=71819=71820=diff
> ==
> --- branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c
> [iso-8859-1] (original)
> +++ branches/GSoC_2016/NTFS/drivers/filesystems/ntfs/volinfo.c
> [iso-8859-1] Tue Jul 5 07:00:43 2016
> @@ -158,7 +157,7 @@
> DPRINT1("Total clusters in bitmap: %I64x\n", BitmapDataSize * 8);
> DPRINT1("Diff in size: %I64d B\n", ((BitmapDataSize * 8) -
> DeviceExt->NtfsInfo.ClusterCount) * DeviceExt->NtfsInfo.SectorsPerCluster *
> DeviceExt->NtfsInfo.BytesPerSector);
>
> -ReadAttribute(DeviceExt, DataContext, Read,
> (PCHAR)((ULONG_PTR)BitmapData + Read), (ULONG)BitmapDataSize);
> +ReadAttribute(DeviceExt, DataContext, 0, (PCHAR)BitmapData,
> (ULONG)BitmapDataSize);
What's this change?
>
> RtlInitializeBitMap(, (PULONG)BitmapData,
> DeviceExt->NtfsInfo.ClusterCount);
> FreeClusters = RtlNumberOfClearBits();
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 71419: [NETSHELL]: Fix french orthograph.
Le 27/05/2016 00:37, hbelu...@svn.reactos.org a écrit : > @@ -95,7 +95,7 @@ > FONT 8, "MS Shell Dlg" > BEGIN > LTEXT "Pour le périphérique :", IDC_STATIC, 33, 2, 100, 50 > -LTEXT "s. o.", IDC_NETWORK_DEVICE, 105, 2, 253, 20 > +LTEXT "n/a", IDC_NETWORK_DEVICE, 105, 2, 253, 20 > LTEXT "Les composants sélectionnés sont utilisés par cette connexion > :", IDC_STATIC, 33, 12, 253, 20 > CONTROL "", IDC_COMPONENT_LIST, "SysListView32", LVS_REPORT | > LVS_SINGLESEL | LVS_SHOWSELALWAYS | LVS_NOCOLUMNHEADER | LVS_NOSORTHEADER | > WS_BORDER | WS_TABSTOP, 33, 22, 250, 50 > PUSHBUTTON "", IDC_NETWORK_INSTALL, 122, 75, 50, 14, > WS_DISABLED | WS_TABSTOP For the record, "n/a" isn't French. n/a means "Not available". "s. o." means "Sans objet" which is the closest. -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: Signature cryptographique S/MIME ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Regarding r71352 and SubGit
Complementary to the work already done by Colin, Fisheye backups have been restored so that SVN cache is consistent with Colin's rollback. Same goes to git. Todays commits will be replayed on next commit for Git. Fisheye is already up to date. Never ever this thing on our infra. Be glad we have backups. Le 18/05/2016 18:51, Colin Finck a écrit : > Hello all, > > As most of you know, I have been busy setting up a two-way Git mirror of > our ReactOS repository using SubGit. > Testing was done in the recent weeks by multiple people using a sandbox > repository and the results looked pretty well. Therefore, SubGit was > considered ready for prime time and I started a first import of our > ReactOS repository. > > The only problem with this: Even without mirroring branches, the Git > repository became a 5.5GB monster (from the 750MB of our current git-svn > mirror). This size was totally not clonable as shown in testing. > The proposed solution: Git offers a garbage cleaner using "git gc > --aggressive". And hell yeah, it reduced the size to a nice 500MB repo. > > While that optimization was running and SubGit was not syncing, two > revisions were committed: r71350 and r71351. > Without expecting any problems, I resumed SubGit mirroring and then > things started to get weird: Apparently, SubGit totally lost traction of > the SVN repository and instead of syncing the two new revisions, it > committed one in r71352 that _replaces_ trunk by r71349. > This is one of the worst commits possible, as it forces SVN clients to > redownload everything when updating their working copies. > > Even more, it shows me that a clear separation of permissions for the > SVN Server and SubGit isn't sufficient. SubGit can and actually did harm > to our repository this way. This is exactly what I was warned of and > what now happened... > I'm sure everybody can understand that I cannot continue with the SubGit > installation under these circumstances. We cannot put our repository at > risk, especially now that we're in the mid of GSoC. > This way, SubGit has definitely shown that it's not ready for our > repository. > I deeply apologize for this trouble and especially to the critics who > remained right. And of course to Hermes, whose name SubGit abused for > making the guilty commit. > > Right now, I'm restoring the repository to r71351 using backups and > "svnadmin dump". This effectively erases r71352 from SVN history. > As r71352 was only online for 10 minutes, I believe it's better to get > rid of that commit in SVN history rather than having everyone suffer > from it. > > Again, I deeply apologize! > > > With best regards, > > Colin > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: Signature cryptographique S/MIME ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GSOC-2016
Hi Samian, Basically, the usage of samba-tng would just be shipping it with ReactOS and making sure it works fine. Probably not the most excting thing ;-). It has been reported working on ReactOS [1], I'm not sure up to which extent. Next step would be to implement this as a proper kernel driver (and its usermode counterpart). You can have a look at VBox shared folders to understand how it works [2]. Basically, 'driver' is the kernel driver, relying on rdbss (proprietary blob from MS), it's pretty simple, because most of the "hard" work is done by rdbss. For Samba, you'd have to use the TDI interface to be able to perform networking from your driver. The second directory, 'np' is the usermode counterpart of the kernel driver. np stands for network provider. It's a component that allows communicating with the driver from usermode, through private IOCTLs, to initiate connections, enumerating remote folders and so on. Samba obviously has one two (which is lanman, unless I'm mistaken). Implementing Samba support would be implementing both. Because rdbss can be annoying (we don't have any open source equivalent), the best thing to do at first is to implement the two parts against Windows 2003, with Windows PSDK/DDK. And then, we'll see how we can make this right into ReactOS. The other advantage of such method is that you can make sure your implementation is compatible with Windows one: can MS lanman communicate with your driver? Can your lanman communicate with MS dirver? This is for the big picture. Fortunately for you, you know Samba, TDI is publicly documented, rdbss as well! The only... Obscure part is the private IOCTLs between lanman & the kernel driver. But these can be found. This email shows you somehow the different steps you can have during GSoC, and the what to look at. This is not a fixed thing, only an help for your proposal. It will be up to your mentor to review this! ;-). Do not hesitate if you have questions (general or on a specific point). Cheers, Pierre [1]: https://www.reactos.org/wiki/Tests_for_0.4.0 [2]: https://www.virtualbox.org/browser/vbox/trunk#src/VBox/Additions/WINNT/SharedFolders Le 11/03/2016 00:11, Mohammad Samian Yusuf a écrit : > Hi Pierre > > > The Samba-TNG code has not been updated recently as per i know. Can you > elaborate on how we can implement this, from the userland space atm ? i am > looking into the source codes, so a bit of more explanation on how we might > achieve this could be helpful. > Sorry i am have not done kernel programming, i did a few course, on kernel > dev, but nothing big,. > But i can learn and show you the proposal before i submit it. > > With Care > Samian > > From: Ros-dev <ros-dev-boun...@reactos.org> on behalf of Pierre Schweitzer > <pie...@reactos.org> > Sent: Sunday, March 6, 2016 2:41 AM > To: ros-dev@reactos.org > Subject: Re: [ros-dev] GSOC-2016 > > Hi Samian, > > Definitely interesting topic! > > I recently did some work on parts in ReactOS that you would deal with > for properly implementing CIFS into ReactOS. > > Even though, it keeps being a tough topic. You actually have two ways to > envision your GSoC project regarding SMB support, depending on your > level in development and your knowledge of the Windows NT architecture. > > One way (likely the easiest - which must somehow work atm) is to work > only in userland and to rely on software such as samba-tng. This might > be a first step in your project, to get used to ReactOS development. > > The second way, and likely hardest way, is to do it the Windows way. > This way involves several components some being in userland, most being > in kernel world. To give a short overview, you'd have to implement > lanman network provider (in userland - a stub already exists in our > trunk) and to implement CIFS network file system in kernel mode > (mrxsmb.sys). The later also requires a secondary driver rdbss.sys. Even > though, at first, it would possible to implement everything into a > single driver. We could discuss later on why two drivers, and why it > would be great to have both. > > Luckily, ReactOS already comes with the MUP driver (which allows > redirecting open requests for network file systems) and several features > into MPR (which allows mapping network shares into the system). > > If you need some references, the book Windows Internals gives a quick > overview about how it works in Windows. You'll find a word about all the > things I've been talking here, so that you're not lost. > > Depending on which way you want to start with, I can give more pointers > about where to look. > > If you need more information, do not hesitate to ask. > > Regards, > > Le 05/03/2016 18:42, Mohammad Samian Yu
Re: [ros-dev] GSOC-2016
Hi Samian, Definitely interesting topic! I recently did some work on parts in ReactOS that you would deal with for properly implementing CIFS into ReactOS. Even though, it keeps being a tough topic. You actually have two ways to envision your GSoC project regarding SMB support, depending on your level in development and your knowledge of the Windows NT architecture. One way (likely the easiest - which must somehow work atm) is to work only in userland and to rely on software such as samba-tng. This might be a first step in your project, to get used to ReactOS development. The second way, and likely hardest way, is to do it the Windows way. This way involves several components some being in userland, most being in kernel world. To give a short overview, you'd have to implement lanman network provider (in userland - a stub already exists in our trunk) and to implement CIFS network file system in kernel mode (mrxsmb.sys). The later also requires a secondary driver rdbss.sys. Even though, at first, it would possible to implement everything into a single driver. We could discuss later on why two drivers, and why it would be great to have both. Luckily, ReactOS already comes with the MUP driver (which allows redirecting open requests for network file systems) and several features into MPR (which allows mapping network shares into the system). If you need some references, the book Windows Internals gives a quick overview about how it works in Windows. You'll find a word about all the things I've been talking here, so that you're not lost. Depending on which way you want to start with, I can give more pointers about where to look. If you need more information, do not hesitate to ask. Regards, Le 05/03/2016 18:42, Mohammad Samian Yusuf a écrit : > Hi my name is samian > > > I wanted to write up a proposal for the project > > "Integrating SMB into ReactOS " > > > I was wondering whether anyone has taken up this project or not yet ? > > > Is this an active project as is anyone currently working on it, as of now i > am looking int the codes to come up with a plan for the development. > Currently i am working with the samba team in testing a new copy transfer > system, which they plan to implement into the future. > > I just need to know this project is online and someone working around to > mentor me at some stages. > > > Any advice would be appreciated > > > With Care > > Samian > > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: Signature cryptographique S/MIME ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk detects some disk errors, just display a warning message but allow the user to continue the installation.
Then fix FastFAT so that it updates statistics and don't put hazardous
hacks into Usetup.
Will be greatly appreciated :-).
As a side note, it seems that our vfatlib is already able to fix errors.
I believe it can already fix a wrong free clusters count.
It's actually funny it's raised as an error, IIRC, free clusters count
is not mandatory and cannot even be trusted by drivers.
Le 02/03/2016 10:14, Hermès BÉLUSCA - MAÏTO a écrit :
> Thanks Pierre for your ideas. I will modify the message box to try to
> integrate those options.
> At the moment we are (in usetup) limited, so repairing the errors will be
> done later. The rest can be implemented easily.
> The fact is that the only error that happens as soon as you write files using
> ReactOS' fastfat driver is that fastfat doesn't update the "free cluster
> number" field in the FSInfo sector of FAT32 disk.
> Because of that, each time you try to reinstall ReactOS without formatting on
> such a partition, you get the checkdisk complaining that this number is wrong
> & needs to be corrected, but then the VfatChkdsk returns a non-success error
> that is interpreted by Usetup as a failure (and the error message appears,
> forbidding the user to continue nevertheless to install ROS).
>
> Cheers,
> Hermès
>
> -Message d'origine-
> De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre
> Schweitzer
> Envoyé : mercredi 2 mars 2016 08:47
> À : ros-dev@reactos.org
> Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk
> detects some disk errors, just display a warning message but allow the user
> to continue the installation.
>
> No?!
> This is totally broken and is to be reverted.
>
> If you detect errors, there are only 3 issues:
> - Offer the user to attempt to repair errors
> - Offer the user to format
> - Exit (as it was done previously)
>
> (If repairing fails, you fall into the two next cases).
> You cannot ignore errors and let the use write on a borked file system.
>
> Le 02/03/2016 01:51, hbelu...@svn.reactos.org a écrit :
>> Author: hbelusca
>> Date: Wed Mar 2 00:51:48 2016
>> New Revision: 70857
>>
>> URL: http://svn.reactos.org/svn/reactos?rev=70857=rev
>> Log:
>> [USETUP]: In case chkdsk detects some disk errors, just display a warning
>> message but allow the user to continue the installation.
>>
>> Modified:
>> trunk/reactos/base/setup/usetup/interface/usetup.c
>> trunk/reactos/base/setup/usetup/lang/bg-BG.h
>> trunk/reactos/base/setup/usetup/lang/bn-BD.h
>> trunk/reactos/base/setup/usetup/lang/cs-CZ.h
>> trunk/reactos/base/setup/usetup/lang/da-DK.h
>> trunk/reactos/base/setup/usetup/lang/de-DE.h
>> trunk/reactos/base/setup/usetup/lang/el-GR.h
>> trunk/reactos/base/setup/usetup/lang/en-US.h
>> trunk/reactos/base/setup/usetup/lang/es-ES.h
>> trunk/reactos/base/setup/usetup/lang/et-EE.h
>> trunk/reactos/base/setup/usetup/lang/fr-FR.h
>> trunk/reactos/base/setup/usetup/lang/he-IL.h
>> trunk/reactos/base/setup/usetup/lang/it-IT.h
>> trunk/reactos/base/setup/usetup/lang/ja-JP.h
>> trunk/reactos/base/setup/usetup/lang/lt-LT.h
>> trunk/reactos/base/setup/usetup/lang/ms-MY.h
>> trunk/reactos/base/setup/usetup/lang/nl-NL.h
>> trunk/reactos/base/setup/usetup/lang/pl-PL.h
>> trunk/reactos/base/setup/usetup/lang/pt-BR.h
>> trunk/reactos/base/setup/usetup/lang/ro-RO.h
>> trunk/reactos/base/setup/usetup/lang/ru-RU.h
>> trunk/reactos/base/setup/usetup/lang/sk-SK.h
>> trunk/reactos/base/setup/usetup/lang/sq-AL.h
>> trunk/reactos/base/setup/usetup/lang/sv-SE.h
>> trunk/reactos/base/setup/usetup/lang/tr-TR.h
>> trunk/reactos/base/setup/usetup/lang/uk-UA.h
>> trunk/reactos/base/setup/usetup/mui.h
>>
>> Modified: trunk/reactos/base/setup/usetup/interface/usetup.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/int
>> erface/usetup.c?rev=70857=70856=70857=diff
>> ==
>> --- trunk/reactos/base/setup/usetup/interface/usetup.c [iso-8859-1]
>> (original)
>> +++ trunk/reactos/base/setup/usetup/interface/usetup.c [iso-8859-1]
>> Wed Mar 2 00:51:48 2016
>> @@ -3154,13 +3154,15 @@
>> if (!NT_SUCCESS(Status))
>> {
>> DPRINT("ChkdskPartition() failed with status 0x%08lx\n",
>> Status);
>> -sprintf(Buffer, "Setup failed to verify the selected
>> partition.\n"
>> +
Re: [ros-dev] [ros-diffs] [hbelusca] 70857: [USETUP]: In case chkdsk detects some disk errors, just display a warning message but allow the user to continue the installation.
ginal)
> +++ trunk/reactos/base/setup/usetup/lang/ru-RU.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -1744,6 +1744,8 @@
> "ReactOS ãáâ ¢«¨¢ ¥âáï à §¤¥«:"},
> {STRING_CHECKINGPART,
> "à®£à ¬¬ ãáâ ®¢ª¨ ¯à®¢¥àï¥â ¢ë¡à ë© à §¤¥«."},
> +{STRING_CONTINUE,
> +"ENTER = த®«¦¨âì"},
> {STRING_QUITCONTINUE,
> "F3 = ë室 ENTER = த®«¦¨âì"},
> {STRING_REBOOTCOMPUTER,
>
> Modified: trunk/reactos/base/setup/usetup/lang/sk-SK.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/sk-SK.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/lang/sk-SK.h [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/lang/sk-SK.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -1757,6 +1757,8 @@
> "Inçtal tor nainçtaluje systm ReactOS na oblas"},
> {STRING_CHECKINGPART,
> "Inçtal tor teraz skontroluje vybran£ oblas."},
> +{STRING_CONTINUE,
> +"ENTER = Pokraova"},
> {STRING_QUITCONTINUE,
> "F3 = Skoni ENTER = Pokraova"},
> {STRING_REBOOTCOMPUTER,
>
> Modified: trunk/reactos/base/setup/usetup/lang/sq-AL.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/sq-AL.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/lang/sq-AL.h [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/lang/sq-AL.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -1750,6 +1750,8 @@
> "Instalimi i ReactOS ne Particion"},
> {STRING_CHECKINGPART,
> "Instalimi tani sht duke kontrolluar particionin e przgjedhur."},
> +{STRING_CONTINUE,
> +"ENTER = Vazhdo"},
> {STRING_QUITCONTINUE,
> "F3 = Dil ENTER = Vazhdo"},
> {STRING_REBOOTCOMPUTER,
>
> Modified: trunk/reactos/base/setup/usetup/lang/sv-SE.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/sv-SE.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/lang/sv-SE.h [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/lang/sv-SE.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -1753,6 +1753,8 @@
> "Setup installerar ReactOS till Partitionen"},
> {STRING_CHECKINGPART,
> "Setup undersker nu den valda partitionen."},
> +{STRING_CONTINUE,
> +"ENTER = Fortstt"},
> {STRING_QUITCONTINUE,
> "F3 = Avsluta ENTER = Fortstt"},
> {STRING_REBOOTCOMPUTER,
>
> Modified: trunk/reactos/base/setup/usetup/lang/tr-TR.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/tr-TR.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/lang/tr-TR.h [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/lang/tr-TR.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -1724,6 +1724,8 @@
> "Kur, ReactOS'u blm zerine kurar."},
> {STRING_CHECKINGPART,
> "Kur, imdi seili blm gzden geiriyor."},
> +{STRING_CONTINUE,
> +"Giri = Srdr"},
> {STRING_QUITCONTINUE,
> "3 = k Giri = Srdr"},
> {STRING_REBOOTCOMPUTER,
>
> Modified: trunk/reactos/base/setup/usetup/lang/uk-UA.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/uk-UA.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/lang/uk-UA.h [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/lang/uk-UA.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -1753,6 +1753,8 @@
> "ReactOS ¢áâ ®¢«îóâìáï ஧¤i«"},
> {STRING_CHECKINGPART,
> "áâ ®¢«î¢ ç ¯¥à¥¢iàïó ¢¨¡à ¨© ஧¤i«."},
> +{STRING_CONTINUE,
> +"ENTER = த®¢¦¨â¨"},
> {STRING_QUITCONTINUE,
> "F3 = ¨©â¨ ENTER = த®¢¦¨â¨"},
> {STRING_REBOOTCOMPUTER,
>
> Modified: trunk/reactos/base/setup/usetup/mui.h
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/mui.h?rev=70857=70856=70857=diff
> ==
> --- trunk/reactos/base/setup/usetup/mui.h [iso-8859-1] (original)
> +++ trunk/reactos/base/setup/usetup/mui.h [iso-8859-1] Wed Mar 2
> 00:51:48 2016
> @@ -115,11 +115,12 @@
> #define STRING_NONFORMATTEDOTHERPART 63
> #define STRING_INSTALLONPART 10
> #define STRING_CHECKINGPART 11
> -#define STRING_QUITCONTINUE 12
> -#define STRING_REBOOTCOMPUTER13
> -#define STRING_TXTSETUPFAILED14
> -#define STRING_COPYING 15
> -#define STRING_SETUPCOPYINGFILES 16
> +#define STRING_CONTINUE 12
> +#define STRING_QUITCONTINUE 13
> +#define STRING_REBOOTCOMPUTER14
> +#define STRING_TXTSETUPFAILED15
> +#define STRING_COPYING 16
> +#define STRING_SETUPCOPYINGFILES 17
> #define STRING_REGHIVEUPDATE 20
> #define STRING_IMPORTFILE21
> #define STRING_DISPLAYETTINGSUPDATE 22
>
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: Signature cryptographique S/MIME
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Something is wron again with getbuilds
A router stopped doing its job (i.e., routing) for a while, hence the downtime and first the flapping in the beginning of the afternoon. The router has been stabilized. On 16/12/2015 19:53, Alexander Rechitskiy wrote: > Hi! > https://www.reactos.org/getbuilds > What is wrong with this page again? > -- > С уважением, > Alexander Rechitskiy > +79286331900 > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [sginsberg] 69393: [NTOS] Fix the Ob wait system calls to only catch the exceptions that are expected to be raised by the Ke wait functions (and not potentially silently catc
On 28/09/2015 11:01, sginsb...@svn.reactos.org wrote:
> Author: sginsberg
> Date: Mon Sep 28 09:01:11 2015
> New Revision: 69393
>
> URL: http://svn.reactos.org/svn/reactos?rev=69393=rev
> Log:
> [NTOS] Fix the Ob wait system calls to only catch the exceptions that are
> expected to be raised by the Ke wait functions (and not potentially silently
> catching *any* exception and corrupting everything in the process). Also
> fixup some code logic. SEH Mega Fixup 1/???
>
> Modified:
> trunk/reactos/ntoskrnl/ob/obwait.c
>
> Modified: trunk/reactos/ntoskrnl/ob/obwait.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ob/obwait.c?rev=69393=69392=69393=diff
> ==
> --- trunk/reactos/ntoskrnl/ob/obwait.c[iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ob/obwait.c[iso-8859-1] Mon Sep 28
> 09:01:11 2015
> @@ -49,12 +49,12 @@
> IN BOOLEAN Alertable,
> IN PLARGE_INTEGER TimeOut OPTIONAL)
> {
> -PKWAIT_BLOCK WaitBlockArray = NULL;
> +PKWAIT_BLOCK WaitBlockArray;
> HANDLE Handles[MAXIMUM_WAIT_OBJECTS], KernelHandle;
> PVOID Objects[MAXIMUM_WAIT_OBJECTS];
> PVOID WaitObjects[MAXIMUM_WAIT_OBJECTS];
> -ULONG i = 0, ReferencedObjects = 0, j;
> -KPROCESSOR_MODE PreviousMode = ExGetPreviousMode();
> +ULONG i, ReferencedObjects, j;
> +KPROCESSOR_MODE PreviousMode;
> LARGE_INTEGER SafeTimeOut;
> BOOLEAN LockInUse;
> PHANDLE_TABLE_ENTRY HandleEntry;
> @@ -65,31 +65,26 @@
> NTSTATUS Status;
> PAGED_CODE();
>
> -/* Enter a critical region since we'll play with handles */
> -LockInUse = TRUE;
> -KeEnterCriticalRegion();
> -
> /* Check for valid Object Count */
> if ((ObjectCount > MAXIMUM_WAIT_OBJECTS) || !(ObjectCount))
> {
> /* Fail */
> -Status = STATUS_INVALID_PARAMETER_1;
> -goto Quickie;
> +return STATUS_INVALID_PARAMETER_1;
> }
>
> /* Check for valid Wait Type */
> if ((WaitType != WaitAll) && (WaitType != WaitAny))
> {
> /* Fail */
> -Status = STATUS_INVALID_PARAMETER_3;
> -goto Quickie;
> -}
> -
> -/* Enter SEH */
> -_SEH2_TRY
> -{
> -/* Check if the call came from user mode */
> -if (PreviousMode != KernelMode)
> +return STATUS_INVALID_PARAMETER_3;
> +}
> +
> +/* Enter SEH for user mode */
> +PreviousMode = ExGetPreviousMode();
> +if (PreviousMode != KernelMode)
> +{
> +/* Enter SEH */
> +_SEH2_TRY
No, this is plain wrong.
This is not because you're in kernel mode that the world is marvelous
and callers trustable.
A caller can pass you buggy address and you HAVE to wrap the
RtlCopyMemory in SEH to make sure that if a buggy address is passed, the
whole system isn't brought down (that's the whole purpose of the copy
after all!).
In case you have a doubt, just put some random:
Status = ZwWaitForMultipleObjects(2, (void **)0x42424242, WaitAll,
FALSE, NULL);
In a kernel component. In w2k3, you'll get Status = STATUS_ACCESS_VIOLATION
In ReactOS, with your changes: BSOD.
Please before doing random changes that you believe are right: do testing.
Alex already told you that.
Cheers,
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate remaining French strings in msgina.dll
"Voyez (avec) votre administrateur système" sounds too "spoken" French. I'd really be in favour of something more... "written". Consultez, contactez, whatever. On 09/14/2015 12:43 PM, Hermès BÉLUSCA - MAÏTO wrote: > Hi all ! > > > > De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Sylvain > Petreolle > Envoyé : lundi 14 septembre 2015 11:36 > À : ReactOS Development List > Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] > Translate remaining French strings in msgina.dll > > > >> +IDS_LOGONUSERDISABLED "Votre compte est désactivé. Voyez votre >> administrateur système." > >> Consultez votre ? > > In this case we should change the english line too, unless this is a false > friend : > >> -IDS_LOGONUSERDISABLED "Your account has been disabled. Please see your >> system administrator." > > Voyez avec votre administrateur système ? > > > > I confirm what Pierre says, in proper french we say « Consultez votre > administrateur système » ; in english “please see” can be said. I would not > say it is a false friend, but better proper translation; indeed when you > translate from language X to language Y you are not obliged to do > word-by-word translation if you know that in language Y there is another way > to say the same thing (eg. If you see “when pigs will fly” you won’t > translate by “quand les cochons voleront” in French, but instead you’ll say > “quand les poules auront des dents”). > > > > [...] > > > > Kind regards, > > > > Sylvain Petreolle > > > > Cheers, > > Hermès > > > > (and the obligatory : > > “Sent by my spying MS Outlook” :P) > > > > _ > > De : Pierre Schweitzer <pie...@reactos.org> > À : ros-dev@reactos.org > Envoyé le : Vendredi 11 septembre 2015 22h05 > Objet : Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] > Translate remaining French strings in msgina.dll > > > > > > > Comments inline. > > On 11/09/2015 21:30, spetreo...@svn.reactos.org wrote: >> URL: >> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/lang/fr-FR.rc?rev=69186 >> >> <http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msgina/lang/fr-FR.rc?rev=69186=69185=69186=diff> >> =69185=69186=diff >> == >> >> >> ___ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer <pie...@reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 69221: [MOUNTMGR] Implement the IOCTL IOCTL_MOUNTMGR_VOLUME_MOUNT_POINT_CREATED: - Implement WriteRemoteDatabaseEntry() - Implement MountMgrVolumeMountPointCrea
DatabaseEntry = AllocatePool(EntrySize);
>> +if (DatabaseEntry == NULL)
>> +{
>> +FreePool(UniqueId);
>> +FreePool(SourceSymbolicName.Buffer);
>> +CloseRemoteDatabase(RemoteDatabase);
>> +return STATUS_INSUFFICIENT_RESOURCES;
>> +}
>> +
>> +/* Fill it in */
>> +DatabaseEntry->EntrySize = EntrySize;
>> +DatabaseEntry->DatabaseOffset = 1;
>> +DatabaseEntry->SymbolicNameOffset = sizeof(DATABASE_ENTRY);
>> +DatabaseEntry->SymbolicNameLength = TargetVolumeName.Length;
>> +DatabaseEntry->UniqueIdOffset = TargetVolumeName.Length +
>> sizeof(DATABASE_ENTRY);
>> +DatabaseEntry->UniqueIdLength = UniqueId->UniqueIdLength;
>> +RtlCopyMemory((PVOID)((ULONG_PTR)DatabaseEntry +
>> sizeof(DATABASE_ENTRY)), TargetVolumeName.Buffer,
>> DatabaseEntry->SymbolicNameLength);
>> +RtlCopyMemory((PVOID)((ULONG_PTR)DatabaseEntry +
>> DatabaseEntry->UniqueIdOffset), UniqueId->UniqueId,
>> UniqueId->UniqueIdLength);
>> +
>> +/* And write it down */
>> +Status = AddRemoteDatabaseEntry(RemoteDatabase, DatabaseEntry);
>> +FreePool(DatabaseEntry);
>> +if (!NT_SUCCESS(Status))
>> +{
>> +FreePool(UniqueId);
>> +FreePool(SourceSymbolicName.Buffer);
>> +CloseRemoteDatabase(RemoteDatabase);
>> +return Status;
>> +}
>> +
>> +/* And now, allocate an Unique ID item */
>> +UniqueIdReplicate = AllocatePool(sizeof(UNIQUE_ID_REPLICATE));
>> +if (UniqueIdReplicate == NULL)
>> +{
>> +FreePool(UniqueId);
>> +FreePool(SourceSymbolicName.Buffer);
>> +CloseRemoteDatabase(RemoteDatabase);
>> +return Status;
>> +}
>> +
>> +/* To associate it with the device */
>> +UniqueIdReplicate->UniqueId = UniqueId;
>> +InsertTailList(>ReplicatedUniqueIdsListHead,
>> >ReplicatedUniqueIdsListEntry);
>> +}
>> +
>> +/* We're done with the remote database */
>> +CloseRemoteDatabase(RemoteDatabase);
>> +
>> +/* Check we were find writing the entry */
>> +if (!NT_SUCCESS(Status))
>> +{
>> +FreePool(SourceSymbolicName.Buffer);
>> +return Status;
>> +}
>> +
>> +/* This is the end, allocate an associated entry */
>> +AssociatedEntry = AllocatePool(sizeof(ASSOCIATED_DEVICE_ENTRY));
>> +if (AssociatedEntry == NULL)
>> +{
>> +FreePool(SourceSymbolicName.Buffer);
>> +return STATUS_INSUFFICIENT_RESOURCES;
>> +}
>> +
>> +/* Initialize its source name string */
>> +AssociatedEntry->String.Length = SourceSymbolicName.Length;
>> +AssociatedEntry->String.MaximumLength =
>> AssociatedEntry->String.Length + sizeof(UNICODE_NULL);
>> +AssociatedEntry->String.Buffer =
>> AllocatePool(AssociatedEntry->String.MaximumLength);
>> +if (AssociatedEntry->String.Buffer == NULL)
>> +{
>> +FreePool(AssociatedEntry);
>> +FreePool(SourceSymbolicName.Buffer);
>> +return STATUS_INSUFFICIENT_RESOURCES;
>> +}
>> +
>> +/* Copy data & insert in list */
>> +RtlCopyMemory(AssociatedEntry->String.Buffer,
>> SourceSymbolicName.Buffer, SourceSymbolicName.Length);
>> +AssociatedEntry->String.Buffer[SourceSymbolicName.Length /
>> sizeof(WCHAR)] = UNICODE_NULL;
>> +AssociatedEntry->DeviceInformation = DeviceInformation;
>> +InsertTailList(>AssociatedDevicesHead,
>> >AssociatedDevicesEntry);
>> +
>> +/* We're done! */
>> +FreePool(SourceSymbolicName.Buffer);
>> +return STATUS_SUCCESS;
>> }
>>
>> NTSTATUS
>>
>> Modified: trunk/reactos/drivers/filters/mountmgr/mntmgr.h
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filters/mountmgr/mntmgr.h?rev=69221=69220=69221=diff
>>
>> ==
>> --- trunk/reactos/drivers/filters/mountmgr/mntmgr.h [iso-8859-1]
>> (original)
>> +++ trunk/reactos/drivers/filters/mountmgr/mntmgr.h [iso-8859-1] Sun
>> Sep 13 22:52:07 2015
>> @@ -298,6 +298,36 @@
>> OUT PUNICODE_STRING VolumeName
>> );
>>
>> +HANDLE
>> +OpenRemoteDatabase(
>> +IN PDEVICE_INFORMATION DeviceInformation,
>> +IN BOOLEAN MigrateDatabase
>> +);
>> +
>> +PDATABASE_ENTRY
>> +GetRemoteDatabaseEntry(
>> +IN HANDLE Database,
>> +IN LONG StartingOffset
>> +);
>> +
>> +NTSTATUS
>> +WriteRemoteDatabaseEntry(
>> +IN HANDLE Database,
>> +IN LONG Offset,
>> +IN PDATABASE_ENTRY Entry
>> +);
>> +
>> +NTSTATUS
>> +CloseRemoteDatabase(
>> +IN HANDLE Database
>> +);
>> +
>> +NTSTATUS
>> +AddRemoteDatabaseEntry(
>> +IN HANDLE Database,
>> +IN PDATABASE_ENTRY Entry
>> +);
>> +
>> /* device.c */
>>
>> DRIVER_DISPATCH MountMgrDeviceControl;
>> @@ -458,4 +488,10 @@
>> IN BOOLEAN MarkOffline
>> );
>>
>> +NTSTATUS
>> +MountMgrQuerySymbolicLink(
>> +IN PUNICODE_STRING SymbolicName,
>> +IN OUT PUNICODE_STRING LinkTarget
>> +);
>> +
>> #endif /* _MNTMGR_H_ */
>>
>> Modified: trunk/reactos/drivers/filters/mountmgr/mountmgr.c
>> URL:
>> http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filters/mountmgr/mountmgr.c?rev=69221=69220=69221=diff
>>
>> ==
>> --- trunk/reactos/drivers/filters/mountmgr/mountmgr.c [iso-8859-1]
>> (original)
>> +++ trunk/reactos/drivers/filters/mountmgr/mountmgr.c [iso-8859-1] Sun
>> Sep 13 22:52:07 2015
>> @@ -48,7 +48,6 @@
>> * - MountMgrQueryDosVolumePaths
>> * - MountMgrQueryVolumePaths
>> * - MountMgrValidateBackPointer
>> - * - MountMgrVolumeMountPointCreated
>> * - MountMgrVolumeMountPointDeleted
>> * - ReconcileThisDatabaseWithMasterWorker
>> */
>>
>>
>>
>
>
>
> ___
> Ros-dev mailing list
> Ros-dev@reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
--
Pierre Schweitzer
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [spetreolle] 69186: [TRANSLATIONS] Translate remaining French strings in msgina.dll
> -PUSHBUTTON "No", IDNO, 95, 39, 50, 14 > +LTEXT "Ãtes vous sûr de vouloir vous déconnecter?", IDC_STATIC, 35, > 16, 146, 8 You need a dash here. > @@ -160,34 +160,34 @@ > IDS_ASKFORUSER "Utilisateur : " > IDS_ASKFORPASSWORD "Mot de passe : " > IDS_FORCELOGOFF "Cela déconnectera l'utilisateur en cours et perdra les > données non sauvées. Continuer ?" > -IDS_LOCKMSG "Seulement %s ou bien un Administrateur peut déverrouiller > cet ordinateur." > -IDS_LOGONMSG "You are logged on as %s." > -IDS_LOGONDATE "Logon date: %s %s" > -IDS_COMPUTERLOCKED "Computer locked" > -IDS_LOCKEDWRONGPASSWORD "The password is wrong. Please enter your > password again. Letters in passwords must be typed using the correct case." > -IDS_LOCKEDWRONGUSER "This computer is locked. Only %s\\%s or an > Administrator can unlock this computer." > -IDS_CHANGEPWDTITLE "Change Password" > -IDS_NONMATCHINGPASSWORDS "The passwords you typed do not match. Type the > same password in both text boxes." > -IDS_PASSWORDCHANGED "Your password has been changed." > -IDS_LOGONTITLE "Logon Message" > -IDS_LOGONWRONGUSERORPWD "The system could not log you on. Make sure your > User name and domain are correct, then type your password again. Letters in > passwords must be typed using the correct case." > -IDS_LOGONUSERDISABLED "Your account has been disabled. Please see your > system administrator." > -IDS_PASSWORDMUSTCHANGE "You are required to change your password at > first logon." > -IDS_PASSWORDEXPIRED "Your password has expired and must be changed." > +IDS_LOCKMSG "Seul %s ou un administrateur peut déverrouiller cet > ordinateur." > +IDS_LOGONMSG "Vous êtes connecté en tant que %s." > +IDS_LOGONDATE "Date de connexion: %s %s" See comment about ':' > +IDS_COMPUTERLOCKED "Ordinateur verrouillé" > +IDS_LOCKEDWRONGPASSWORD "Le mot de passe est incorrect. Entrez à > nouveau votre mot de passe en respectant les majuscules." > +IDS_LOCKEDWRONGUSER "Cet ordinateur est actuellement verrouillé. Seul > %s\\%s ou un administrateur peut déverrouiller cet ordinateur." > +IDS_CHANGEPWDTITLE "Changer le mot de passe" > +IDS_NONMATCHINGPASSWORDS "Les mots de passe ne correspondent pas. Entrez > le même mot de passe dans les deux zones de texte." > +IDS_PASSWORDCHANGED "Votre mot de passe a été changé." > +IDS_LOGONTITLE "Connexion" > +IDS_LOGONWRONGUSERORPWD "Le système ne peut vous connecter. Vérifiez > vos noms d'utilisateur et de domaine. Entrez à nouveau votre mot de passe en > respectant les majuscules." > +IDS_LOGONUSERDISABLED "Votre compte est désactivé. Voyez votre > administrateur système." Consultez votre ? -- Pierre Schweitzer System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 68754: [NTVDM]: Initialize the PSP' memory control block owner name with the file name (without extension, and up to 8 chars) of the started program.
And what about simply doing some PspName = strrchr(ProgramName, '\\'); or whatever? It looks really weird to start looking at the begin of a path to get its last element delimitation... And for the record, otherwise, you have splitpath :-) On 18/08/2015 14:35, Thomas Faber wrote: On 2015-08-18 14:26, hbelu...@svn.reactos.org wrote: [NTVDM]: Initialize the PSP' memory control block owner name with the file name (without extension, and up to 8 chars) of the started program. Shouldn't that use GetShortPathName to make sure the program can find itself on disk? :p ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [cwittich] 68305: [BROWSEUI] don't expose some interfaces expose IID_IContextMenu3 from CBandSiteMenu
This commit regressed (badly) explorer: https://www3.heisspiter.net/explorer.png On 28/06/2015 20:22, cwitt...@svn.reactos.org wrote: Author: cwittich Date: Sun Jun 28 18:22:02 2015 New Revision: 68305 URL: http://svn.reactos.org/svn/reactos?rev=68305view=rev Log: [BROWSEUI] don't expose some interfaces expose IID_IContextMenu3 from CBandSiteMenu Modified: trunk/reactos/dll/win32/browseui/addressband.h trunk/reactos/dll/win32/browseui/addresseditbox.h trunk/reactos/dll/win32/browseui/bandsitemenu.h trunk/reactos/dll/win32/browseui/internettoolbar.h Modified: trunk/reactos/dll/win32/browseui/addressband.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/addressband.h?rev=68305r1=68304r2=68305view=diff == --- trunk/reactos/dll/win32/browseui/addressband.h[iso-8859-1] (original) +++ trunk/reactos/dll/win32/browseui/addressband.h[iso-8859-1] Sun Jun 28 18:22:02 2015 @@ -136,6 +136,5 @@ COM_INTERFACE_ENTRY_IID(IID_IInputObjectSite, IInputObjectSite) COM_INTERFACE_ENTRY_IID(IID_IPersist, IPersist) COM_INTERFACE_ENTRY_IID(IID_IPersistStream, IPersistStream) -COM_INTERFACE_ENTRY_IID(IID_IDispatch, IDispatch) END_COM_MAP() }; Modified: trunk/reactos/dll/win32/browseui/addresseditbox.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/addresseditbox.h?rev=68305r1=68304r2=68305view=diff == --- trunk/reactos/dll/win32/browseui/addresseditbox.h [iso-8859-1] (original) +++ trunk/reactos/dll/win32/browseui/addresseditbox.h [iso-8859-1] Sun Jun 28 18:22:02 2015 @@ -97,7 +97,6 @@ COM_INTERFACE_ENTRY_IID(IID_IWinEventHandler, IWinEventHandler) COM_INTERFACE_ENTRY_IID(IID_IOleCommandTarget, IOleCommandTarget) COM_INTERFACE_ENTRY_IID(IID_IDispatch, IDispatch) -COM_INTERFACE_ENTRY_IID(IID_IPersist, IPersist) COM_INTERFACE_ENTRY_IID(IID_IPersistStream, IPersistStream) END_COM_MAP() }; Modified: trunk/reactos/dll/win32/browseui/bandsitemenu.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/bandsitemenu.h?rev=68305r1=68304r2=68305view=diff == --- trunk/reactos/dll/win32/browseui/bandsitemenu.h [iso-8859-1] (original) +++ trunk/reactos/dll/win32/browseui/bandsitemenu.h [iso-8859-1] Sun Jun 28 18:22:02 2015 @@ -55,6 +55,7 @@ BEGIN_COM_MAP(CBandSiteMenu) COM_INTERFACE_ENTRY_IID(IID_IShellService, IShellService) COM_INTERFACE_ENTRY_IID(IID_IContextMenu2, IContextMenu2) +COM_INTERFACE_ENTRY_IID(IID_IContextMenu3, IContextMenu3) COM_INTERFACE_ENTRY_IID(IID_IContextMenu, IContextMenu) END_COM_MAP() }; Modified: trunk/reactos/dll/win32/browseui/internettoolbar.h URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/browseui/internettoolbar.h?rev=68305r1=68304r2=68305view=diff == --- trunk/reactos/dll/win32/browseui/internettoolbar.h[iso-8859-1] (original) +++ trunk/reactos/dll/win32/browseui/internettoolbar.h[iso-8859-1] Sun Jun 28 18:22:02 2015 @@ -228,7 +228,6 @@ COM_INTERFACE_ENTRY_IID(IID_IInputObject, IInputObject) COM_INTERFACE_ENTRY_IID(IID_IOleWindow, IOleWindow) COM_INTERFACE_ENTRY_IID(IID_IDockingWindow, IDockingWindow) -COM_INTERFACE_ENTRY_IID(IID_IPersist, IPersist) //COM_INTERFACE_ENTRY_IID(IID_IPersistStream, IPersistStream) COM_INTERFACE_ENTRY_IID(IID_IPersistStreamInit, IPersistStreamInit) COM_INTERFACE_ENTRY_IID(IID_IOleCommandTarget, IOleCommandTarget) @@ -237,7 +236,5 @@ COM_INTERFACE_ENTRY_IID(IID_IShellChangeNotify, IShellChangeNotify) COM_INTERFACE_ENTRY_IID(IID_IObjectWithSite, IObjectWithSite) COM_INTERFACE_ENTRY_IID(IID_IServiceProvider, IServiceProvider) -COM_INTERFACE_ENTRY_IID(IID_IWinEventHandler, IWinEventHandler) -COM_INTERFACE_ENTRY_IID(IID_IBandSite, IBandSite) END_COM_MAP() }; -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Changes in authentication for Jira
Dear all, We are now running Jira 6 in production, after a long fight. Thanks to the Atlassian support for their care and help in this process. If you spot anything unusual, please report to me either by mail or on Jira, ONLINE project. With my best regards, On 06/10/2015 04:34 PM, Pierre Schweitzer wrote: Dear all, We have proceed to a complete reimplementation of authentication server which serves Jira Fisheye. The purpose is to rely on something maintained and stable. It should not change anything for you on daily usage. 58 accounts have been left out and will not be able to connect to Jira due to incompatible account name (using invalid chars). If you happen to be incapable of log in, please contact me so that I can rename your account. New accounts cannot be created with such invalid chars any longer. As a side note, this was a major blocker for our upgrade to Jira 6. If we do not spot anything wrong with our new authentication mechanism, then, then the upgrade to Jira 6 should happen in the next days. With my best regards, ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Changes in authentication for Jira
The Agile extension has already been enabled with success during our testing. All previous boards are available again. So, once in production, you'll have it back. On 06/10/2015 10:38 PM, Timo Kreuzer wrote: Great to hear that. When you do the update, please have a look at reenabling the agile-extensions, that I think we lost on the previous update attempt. Thanks, Timo Am 10.06.2015 um 16:34 schrieb Pierre Schweitzer: Dear all, We have proceed to a complete reimplementation of authentication server which serves Jira Fisheye. The purpose is to rely on something maintained and stable. It should not change anything for you on daily usage. 58 accounts have been left out and will not be able to connect to Jira due to incompatible account name (using invalid chars). If you happen to be incapable of log in, please contact me so that I can rename your account. New accounts cannot be created with such invalid chars any longer. As a side note, this was a major blocker for our upgrade to Jira 6. If we do not spot anything wrong with our new authentication mechanism, then, then the upgrade to Jira 6 should happen in the next days. With my best regards, ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Changes in authentication for Jira
Dear all, We have proceed to a complete reimplementation of authentication server which serves Jira Fisheye. The purpose is to rely on something maintained and stable. It should not change anything for you on daily usage. 58 accounts have been left out and will not be able to connect to Jira due to incompatible account name (using invalid chars). If you happen to be incapable of log in, please contact me so that I can rename your account. New accounts cannot be created with such invalid chars any longer. As a side note, this was a major blocker for our upgrade to Jira 6. If we do not spot anything wrong with our new authentication mechanism, then, then the upgrade to Jira 6 should happen in the next days. With my best regards, -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Changes in authentication for Jira
I win my internal bet: I was sure it would be the first question asked (or related, the password change one). The answer is no: the 6h delay to get both databases in sync is still required. They are perhaps options to tackle this in the future. Colin I will have a look. But our priority for now was to sanitize the whole thing to let Jira 6 run on top of it. On 06/10/2015 04:42 PM, Hermès BÉLUSCA - MAÏTO wrote: Hi! Happy to hear that, I hope it fixes also this timeout that some people who just created a new ROS account suffered when connecting to Jira for the first time? Hermès. -Message d'origine- De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre Schweitzer Envoyé : mercredi 10 juin 2015 16:34 À : ReactOS Development List Objet : [ros-dev] Changes in authentication for Jira Dear all, We have proceed to a complete reimplementation of authentication server which serves Jira Fisheye. The purpose is to rely on something maintained and stable. It should not change anything for you on daily usage. 58 accounts have been left out and will not be able to connect to Jira due to incompatible account name (using invalid chars). If you happen to be incapable of log in, please contact me so that I can rename your account. New accounts cannot be created with such invalid chars any longer. As a side note, this was a major blocker for our upgrade to Jira 6. If we do not spot anything wrong with our new authentication mechanism, then, then the upgrade to Jira 6 should happen in the next days. With my best regards, -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Vote for removing rapps DB from trunk
Hi, With such idea, we could envision automatic cab generation on commit to avoid devs to do it, so that any change done to it would be taken into account without further human processing. Regards, On 01/06/2015 14:03, Hermès BÉLUSCA - MAÏTO wrote: Hi ! Yep, get rid of these rapps db files from the trunk and move them elsewhere (so that each time they are updated we won’t have useless new revision numbers for the main trunk).. Cheers, Hermès. De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de daniel.rei...@reactos.org Envoyé : samedi 30 mai 2015 17:23 À : ros-dev@reactos.org Objet : [ros-dev] Vote for removing rapps DB from trunk Hey guys, as some of you might have seen already we now have two copies of the more and more increasing RAPPS DB in trunk. This is: a) Absolutely unnecessary and does only result in one thing, two differing DBs b) Shows even more that it’s not useful to have it in trunk at all. Because of this I start a vote now to get your opinion in completely removing the RAPPS DB from trunk into a subtree like done for many other things, too. What do you think? Greetings Daniel Reimer Gesendet von Windows Mail ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Status Meeting (May 2015)
Hi, The credentials just have been sent. The meeting will start in a half or so. If you didn't receive them, please contact me before the meeting starts. The meeting will take place on #meeting, fezile.reacots.org (6667 no SSL). If you don't have credentials, you won't be able to attend it. Cheers, On 24/05/2015 18:56, Aleksey Bragin wrote: Hello, Let me invite you to the monthly status meeting taking place 28th of May, 19:00 UTC, as always. 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. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Fezile motherboard has finally failed
It was from beginish of December 2014. Proper update is ongoing at the moment. On 11/05/2015 08:25, Ged Murphy wrote: Hi Colin, Doxygen doesn't appear to be the latest code. Did you do a rebuild? The date of the last build is also missing so I can't tell when it's from, although I believe it was from as far back as 2012 previously. Ged. -Original Message- From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck Sent: 10 May 2015 19:14 To: ros-dev@reactos.org Subject: Re: [ros-dev] Fezile motherboard has finally failed Well, this definitely took longer than any of us expected.. Nevertheless, the Fezile server is back now! Enjoy an updated Doxygen as well as the Buildslaves and cppcheck. Cheers, Colin Am 11.12.2014 um 17:07 schrieb Colin Finck: Hi all, Today, the motherboard in our Fezile server has finally failed after many hick-ups over the year. This causes an outage for the following services: * doxygen.reactos.org * cppcheck.reactos.org * VMware Player Test slave * VMware Player Patchbot As this is not the first time we struggle with such problems, iso.reactos.org is routed to a different server right now and not affected. We have already ordered replacement hardware for this system and hope to be able to get it back to a working state soon. Even if this machine is from 2007, we have decided to revive it with replacement parts instead of going for a brand-new one as this is much cheaper and quicker to realize. Also there is a huge pile of replacement hardware available. Sorry for the inconveniences! Cheers, Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Fezile motherboard has finally failed
Forgot to say: The generation is done and went fine. Enjoy the most up to date Doxygen ;-). On 05/11/2015 08:46 AM, Ged Murphy wrote: Great, thanks Pierre :) -Original Message- From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Pierre Schweitzer Sent: 11 May 2015 07:31 To: ros-dev@reactos.org Subject: Re: [ros-dev] Fezile motherboard has finally failed It was from beginish of December 2014. Proper update is ongoing at the moment. On 11/05/2015 08:25, Ged Murphy wrote: Hi Colin, Doxygen doesn't appear to be the latest code. Did you do a rebuild? The date of the last build is also missing so I can't tell when it's from, although I believe it was from as far back as 2012 previously. Ged. -Original Message- From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck Sent: 10 May 2015 19:14 To: ros-dev@reactos.org Subject: Re: [ros-dev] Fezile motherboard has finally failed Well, this definitely took longer than any of us expected.. Nevertheless, the Fezile server is back now! Enjoy an updated Doxygen as well as the Buildslaves and cppcheck. Cheers, Colin Am 11.12.2014 um 17:07 schrieb Colin Finck: Hi all, Today, the motherboard in our Fezile server has finally failed after many hick-ups over the year. This causes an outage for the following services: * doxygen.reactos.org * cppcheck.reactos.org * VMware Player Test slave * VMware Player Patchbot As this is not the first time we struggle with such problems, iso.reactos.org is routed to a different server right now and not affected. We have already ordered replacement hardware for this system and hope to be able to get it back to a working state soon. Even if this machine is from 2007, we have decided to revive it with replacement parts instead of going for a brand-new one as this is much cheaper and quicker to realize. Also there is a huge pile of replacement hardware available. Sorry for the inconveniences! Cheers, Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Release: build failed
Manually uploaded. On 10/05/2015 19:28, build...@reactos.org wrote: The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS. Full details are available at: https://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/1177 Buildbot URL: https://build.reactos.org/ Buildslave for this Build: Debug Build Reason: The Periodic scheduler named 'Release' triggered this build Build Source Stamp: HEAD Blamelist: BUILD FAILED: failed shell sincerely, -The Buildbot -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 67508: [PARPORT] Introduce a skeleton that will serve as base for implementing the parallel port function driver. Brought to you by The ReactOS Printing Group. CORE
Joke or not, it's good to know who's committing ;-). Thanks for detailing. In case of a trouble with committed, we know who to contact. On 02/05/2015 17:07, daniel.rei...@reactos.org wrote: Seems like someone didn’t get the joke, huh? ^^ Gesendet von Windows Mail Von: Amine Khaldi Gesendet: Samstag, 2. Mai 2015 16:39 An: ros-dev@reactos.org Hi, For grumpy folks who do not appreciate fun names like RPG Team...etc and prefer negative perceptions over positive ones, this is merely Amine Khaldi aka AmineKhaldi, Colin Finck aka ColinFinck, Mark Jansen aka learn_more and V. We welcome anyone to join the ReactOS Printing Group, with Aleksandar Andrejevic aka TheFlash being the potential next RPG guy ;) This effort started as an extra motivation for Colin Finck to make his upcoming school project (related to printing support in ReactOS) progress as smoothly as we can help it be. Cheers, Amine. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 67508: [PARPORT] Introduce a skeleton that will serve as base for implementing the parallel port function driver. Brought to you by The ReactOS Printing Group. CORE
On 02/05/2015 12:15, akha...@svn.reactos.org wrote: Author: akhaldi Date: Sat May 2 10:15:37 2015 New Revision: 67508 URL: http://svn.reactos.org/svn/reactos?rev=67508view=rev Log: [PARPORT] Introduce a skeleton that will serve as base for implementing the parallel port function driver. Brought to you by The ReactOS Printing Group. CORE-9644 Is there a need for that much secrecy? I shall remind that we ask people to contribute with their real names. Such secret looks useless and damaging for the project. And no, ARM group isn't a good example, nor a reason to keep doing so. -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Status Meeting (April 2015)
Hi, The credentials just have been sent and the server started. As a reminder, the server is running on fezile.reactos.org:6667, channel #meeting. No SSL (yet). In case you didn't have your credentials, you cannot attend the meeting (private). Contact me if anything wrong. The meeting will start in less than 1 hour. With my best regards, On 28/04/2015 00:27, Aleksey Bragin wrote: Hello, Let me invite you to the monthly status meeting taking place 30th of April, 19:00 UTC, as always. 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. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. And join Mumble! Regards, Aleksey Bragin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [aandrejevic] 67340: [NTVDM] Implement basic XMS functions.
On 22/04/2015 05:10, aandreje...@svn.reactos.org wrote:
+static inline PXMS_HANDLE GetHandleRecord(WORD Handle)
+{
+PXMS_HANDLE Entry = HandleTable[Handle - 1];
+if (Handle == 0 || Handle = XMS_MAX_HANDLES) return NULL;
+
+return Entry-Size ? Entry : NULL;
+}
This looks highly dangerous to me and likely compiler dependent.
I'd rather perform the sanity checks before ever touching HandleTable,
especially because the value of Handle is coming right from caller
registers and have never been sanitized before.
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [gadamopoulos] 66988: [EXPLORER] - Fix showing the website when Help is selected from the start menu.
Just a side (minor) remark. On 31/03/2015 00:28, gadamopou...@svn.reactos.org wrote: Modified: trunk/reactos/base/shell/explorer/explorer.rc URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/explorer/explorer.rc?rev=66988r1=66987r2=66988view=diff == --- trunk/reactos/base/shell/explorer/explorer.rc [iso-8859-1] (original) +++ trunk/reactos/base/shell/explorer/explorer.rc [iso-8859-1] Mon Mar 30 22:28:08 2015 @@ -28,7 +28,7 @@ STRINGTABLE BEGIN //IDS_HELP_COMMAND helpctr.exe-FromStartHelp -IDS_HELP_COMMAND https://www.reactos.org/; +IDS_HELP_COMMAND http://www.reactos.org/; This is to be reverted once ReactOS fully supports SSL. -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 66946: [CMAKE] Improve the concatenate_files macro introduced by Timo in r52179 + r52182 and hackfixed in r53914 . Notice that now it can take an arbitrary number
Seconding here...
What's the whole purpose of this?
You have cat on Linux/BSD systems and type on Windows systems (if you
don't want to do the whole cmd copy stuff).
So what's the point? Let's keep efficient local tools.
On 29/03/2015 07:15, Thomas Faber wrote:
I don't see how creating a new host-tool is an improvement over using OS
builtins?
On 2015-03-29 03:53, hbelu...@svn.reactos.org wrote:
Author: hbelusca
Date: Sun Mar 29 01:53:10 2015
New Revision: 66946
URL: http://svn.reactos.org/svn/reactos?rev=66946view=rev
Log:
[CMAKE]
Improve the concatenate_files macro introduced by Timo in r52179 + r52182
and hackfixed in r53914 . Notice that now it can take an arbitrary number of
files to be concatenated. Hence you need to specify first the output file,
and all the rest is the different files.
[FREELDR]
Use the improved concatenate_files macro.
Modified:
trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
trunk/reactos/cmake/CMakeMacros.cmake
Modified: trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt?rev=66946r1=66945r2=66946view=diff
==
--- trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt[iso-8859-1]
(original)
+++ trunk/reactos/boot/freeldr/freeldr/CMakeLists.txt[iso-8859-1]
Sun Mar 29 01:53:10 2015
@@ -226,10 +226,13 @@
add_dependencies(freeldr_pe asm)
add_dependencies(freeldr_pe_dbg asm)
+# Retrieve the full path to the generated file of the 'freeldr_pe' target
+get_target_property(_freeldr_pe_output_file freeldr_pe LOCATION)
+
concatenate_files(
+${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys
${CMAKE_CURRENT_BINARY_DIR}/frldr16.bin
-freeldr_pe
-${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys)
+${_freeldr_pe_output_file})
add_custom_target(freeldr ALL DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys)
@@ -238,9 +241,9 @@
add_cd_file(TARGET freeldr FILE ${CMAKE_CURRENT_BINARY_DIR}/freeldr.sys
DESTINATION loader NO_CAB NOT_IN_HYBRIDCD FOR livecd hybridcd NAME_ON_CD
setupldr.sys)
concatenate_files(
+${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys
${CMAKE_CURRENT_BINARY_DIR}/frldr16.bin
-freeldr_pe
-${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys)
+${_freeldr_pe_output_file})
add_custom_target(setupldr ALL DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys)
add_cd_file(TARGET setupldr FILE ${CMAKE_CURRENT_BINARY_DIR}/setupldr.sys
DESTINATION loader NO_CAB FOR bootcd regtest)
Modified: trunk/reactos/cmake/CMakeMacros.cmake
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/CMakeMacros.cmake?rev=66946r1=66945r2=66946view=diff
==
--- trunk/reactos/cmake/CMakeMacros.cmake[iso-8859-1] (original)
+++ trunk/reactos/cmake/CMakeMacros.cmake[iso-8859-1] Sun Mar 29
01:53:10 2015
@@ -504,33 +504,12 @@
endfunction()
endif()
-if(CMAKE_HOST_SYSTEM_NAME STREQUAL Windows)
-macro(to_win_path _cmake_path _native_path)
-string(REPLACE / \\ ${_native_path} ${_cmake_path})
-endmacro()
-
-# yeah the parameter mess sucks, but thats what works...
-function(concatenate_files _file1 _target2 _output)
-get_target_property(_file2 ${_target2} LOCATION)
-to_win_path(${_file1} _real_file1)
-to_win_path(${_file2} _real_file2)
-to_win_path(${_output} _real_output)
-add_custom_command(
-OUTPUT ${_output}
-COMMAND cmd.exe /C copy /Y /B ${_real_file1} + ${_real_file2}
${_real_output} nul
-DEPENDS ${_file1}
-DEPENDS ${_target2})
-endfunction()
-else()
-macro(concatenate_files _file1 _target2 _output)
-get_target_property(_file2 ${_target2} LOCATION)
-add_custom_command(
-OUTPUT ${_output}
-COMMAND cat ${_file1} ${_file2} ${_output}
-DEPENDS ${_file1}
-DEPENDS ${_target2})
-endmacro()
-endif()
+macro(concatenate_files _output)
+add_custom_command(
+OUTPUT ${_output}
+COMMAND native-cat ${ARGN} ${_output}
+DEPENDS ${ARGN} native-cat)
+endmacro()
function(add_importlibs _module)
add_dependency_node(${_module})
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 66903: [NTVDM] - Fix some english. - Validity checks for DosGetSftEntry returned pointer added. - Use unsigned indices for for-loops indices that are always positi
On 03/26/2015 03:52 PM, hbelu...@svn.reactos.org wrote:
Modified: trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c?rev=66903r1=66902r2=66903view=diff
==
--- trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c [iso-8859-1]
(original)
+++ trunk/reactos/subsystems/mvdm/ntvdm/dos/dos32krnl/bios.c [iso-8859-1]
Thu Mar 26 14:52:16 2015
@@ -56,6 +56,13 @@
BOOLEAN DosCheckInput(VOID)
{
PDOS_SFT_ENTRY SftEntry = DosGetSftEntry(DOS_INPUT_HANDLE);
+
+if (SftEntry == NULL)
+{
+/* Invalid handle */
+DosLastError = ERROR_INVALID_HANDLE; // ERROR_FILE_NOT_FOUND
Hum... Why?
Is the error code wrong and should be ERROR_FILE_NOT_FOUND? And then,
why setting this other error code?
Or is the error code right, and then, what's the purpose of such comment?
Or do you have a doubt about the right error code to use? Be it one or
the other?
I come back to my eternal comment: don't comment for yourself. Comment
for the others, you're not alone here. So, make it explicit.
Cheers,
--
Pierre Schweitzer pie...@reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Jira Fisheye downtime
Dear all, Due to DB maintenance, Jira Fisheye will be down in a few minutes. There's no ETA for up status. Sorry for the caused inconvenience, -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Jira Fisheye downtime
Dear all, Jira Fisheye are getting back online. Everything went fine. Please report if you see anything wrong. With my best regards, On 03/19/2015 04:54 PM, Pierre Schweitzer wrote: Dear all, Due to DB maintenance, Jira Fisheye will be down in a few minutes. There's no ETA for up status. Sorry for the caused inconvenience, ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ReactOS versioning
I'm not sure you realize what you're praising. Links junctions are not supported on FAT, they require NTFS. On 03/10/2015 12:37 PM, Huw Campbell wrote: SxS uses hard links, not symlinks. Seems like the way to go too, as we're already hitting the boundary with common controls and it's how windows does version compatibly. Huw -Original Message- From: Ged Murphy gedmurphy.mailli...@gmail.com Sent: 10/03/2015 10:27 PM To: 'ReactOS Development List' ros-dev@reactos.org Subject: Re: [ros-dev] ReactOS versioning It might also be useful to employ some form of heuristics as UAC does. Things like file name detection, string table detection, marked processes via user defined requests or a hash database, etc. Perhaps even scanning the imports (although this is harder to manage due to people using GetProcAddress to detect OS version) -Original Message- From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer Sent: 07 March 2015 12:44 To: ReactOS Development List Subject: [ros-dev] ReactOS versioning 1. We need a method to specify which application should be run in which environment. We should probably use the same mechanism that is used on Windows. Compatibility information is stored in a registry key HKCU\Software\Microsodt\Windows NT\CurrentVersion\AppCompatFlags\... The trick is to make this easy / transparent for the user. A right-click - properties - compatibility approach should for now probably be the easiest thing, ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ReactOS versioning
, as well as creating a better organized system. So each DLL, lets say ADVAPI32, as located in different version specific system32 folders, would mainly/only consist of forwarders to a parent DLL. On Windows we can see this being developed similarly, using api sets and redirections made by the loader. Cloning this mechanism 1:1 might not be the right thing though, since it does not address all our requirements. So instead I suggest proving our own custom parent DLLs. While these could be organized the same way as on Windows 2003, this is probably not optimal. Instead I suggest merging stuff together into 1 or few DLLs (similar to how stuff was combined in kernelbase.dll) This might looks like this (note, that the names are just quickly made up names, I don't claim that they are good) - user32/gdi32 - ros-win32-core.dll - kernel32/advapi32 - ros-kernel-base.dll - msvcr* - ros-crt.dll - ntdll - ros-ntdll (the kernel would need to load this one) This also allows our DLLs to make use of higher version APIs, by linking them to the parent DLL. Now this obviously introduces a problem when trying to run individual DLLs within a Windows system. To still be able to do this for testing purposes, we need to make sure that they still run there. First, if they import from a custom ros-* DLL, it won't run on Windows without that DLL. So we need the possibility to either statically link these functions, or compile a helper DLL, that contains these functions, so our DLLs can be run on Windows. If we used a common parent DLL, this also creates the problem of DLL initialization. e.g. the DLL parent for kernel32 and advapi32 would do the initialization for both of these, so this would not be suitable to use when replacing only one of the DLLs. Instead DLL initialization could be done by calling a specific initialization function in the parent DLL from the child DLL. So kernel32!DllMain would call ros-kernel-base!DllMain_kernel32, passing the original parameters as well as a version number, that the parent DLL can use to do version specific initialization. This way The parent DLL would only do the kernel32 initialization, when the related kernel32 child DLL was used, the advapi32 initialization would not be done. There is still a problem: relocation. So we would need to make sure we chose base addresses that still allow us to plug the stuff into Windows without causing everything to relocate, which often simply doesn't work. As an alternative, we should provide a compile time switch to compile specific DLLs in a self-contained way. In terms of structure we could use the MS api-sets as a base for static libraries. Then we can link these either into the parent DLLs like ros-kernel-base.dll or - when a compile switch is given - to link together fully self contained DLLs. I am really not interested in answers like This is not what WIndows does!, THIS CANNOT WORK!!!, You are a * even suggesting this, What if application x parses the import table and disassembles the DLL to hook into internal functions, ...: I am only interested in *constructive* comments. Everything else: - /dev/null Thanks, Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
ignoring everyone? I checked CORE-9111 and I don't see any single comment from Timo, Jerome, James, whoever else counts. Regards, Aleksey Bragin P.S. I'm not talking about actual changes, I'm talking about the process and attitude. On 06.03.2015 2:03, hbelu...@svn.reactos.org wrote: Author: hbelusca Date: Thu Mar 5 23:03:33 2015 New Revision: 66575 URL: http://svn.reactos.org/svn/reactos?rev=66575 http://svn.reactos.org/svn/reactos?rev=66575view=rev view=rev Log: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] GSoC :: application rejected
The ReactOS Foundation application got officially rejected because of the numbers of slots available and the high # of terrific applications. On 03/03/2015 02:08 PM, Hermès BÉLUSCA - MAÏTO wrote: We've been yet again rejected for the same reasons as before (i.e. no apparent reasons)? Cheers, Hermès. -Message d'origine- De : Ros-dev [mailto:ros-dev-boun...@reactos.org] De la part de Pierre Schweitzer Envoyé : lundi 2 mars 2015 22:23 À : ReactOS Development List Objet : [ros-dev] GSoC :: application rejected Dear all, The ReactOS Foundation application to GSoC has been rejected this year again. Statistics are not reliable after all. In any case, keep up the good work. We don't need Google to be the bests at what we do. Cheers, -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] GSoC :: application rejected
Dear all, The ReactOS Foundation application to GSoC has been rejected this year again. Statistics are not reliable after all. In any case, keep up the good work. We don't need Google to be the bests at what we do. Cheers, -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Cant log in jira
We've faced an incident on the LDAP server this morning. It has been solved at 1:04PM CEST. On 01/03/2015 13:27, Aleksey Bragin wrote: I can. Regards, Aleksey On 01.03.2015 15:20, Alexander Rechitskiy wrote: Cant log in jira -- С уважением, Alexander Rechitskiy +79286331900 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [gadamopoulos] 66383: [SHELL32] - Implement progress dialogs for SHFileOperation - Patch by Hwu Davies CORE-4476
In such situations, please update all the langages files and not only English. This makes work easier for translators to track changes. On 21/02/2015 13:52, gadamopou...@svn.reactos.org wrote: Author: gadamopoulos Date: Sat Feb 21 12:52:58 2015 New Revision: 66383 URL: http://svn.reactos.org/svn/reactos?rev=66383view=rev Log: [SHELL32] - Implement progress dialogs for SHFileOperation - Patch by Hwu Davies CORE-4476 Modified: trunk/reactos/dll/win32/shell32/lang/en-US.rc Modified: trunk/reactos/dll/win32/shell32/lang/en-US.rc URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/lang/en-US.rc?rev=66383r1=66382r2=66383view=diff == --- trunk/reactos/dll/win32/shell32/lang/en-US.rc [iso-8859-1] (original) +++ trunk/reactos/dll/win32/shell32/lang/en-US.rc [iso-8859-1] Sat Feb 21 12:52:58 2015 @@ -693,6 +693,13 @@ IDS_OVERWRITEFILE_CAPTION Confirm file overwrite IDS_OVERWRITEFOLDER_TEXT This folder already contains a folder named '%1'.\n\nIf the files in the destination folder have the same names as files in the\nselected folder they will be replaced. Do you still want to move or copy\nthe folder? +IDS_FILEOOP_COPYING Copying +IDS_FILEOOP_MOVINGMoving +IDS_FILEOOP_DELETING Deleting +IDS_FILEOOP_FROM_TO From %1 to %2 +IDS_FILEOOP_FROM From %1 +IDS_FILEOOP_PREFLIGHT Preflight + /* message box strings */ IDS_RESTART_TITLE Restart IDS_RESTART_PROMPT Do you want to restart the system? -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] VirtualBox Testslave
Hi Colin, I will have a look at sysreg2. Please make sure that the NUC is setup with the latest LTS. It will make the process smoother. Cheers, Pierre On 18/02/2015 11:17, Colin Finck wrote: Hi all, As tests have shown that VirtualBox doesn't work properly inside an already virtualized environment, ReactOS Deutschland e.V. has just ordered a tiny Intel NUC that will serve as a VirtualBox Testslave. We plan to set it up right next to our Buildslaves, so that every ISO could possibly be regression-tested under VirtualBox. As a start, we plan to test the builds of the new MSVC Builder. The machine is powerful enough though to eventually test multiple ISOs simultaneously. I don't know about the current state of sysreg2 regarding VirtualBox support. To let this all happen as soon as possible, please ensure sysreg2 can fully handle VirtualBox once I set up the machine. Cheers, Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] The ReactOS Project at FOSDEM 2015
As a side note, it was interesting to note that the way people look at ReactOS changed a bit. Cannot say why though. We're still a hobby project for many, but some start thinking about things they could do with ReactOS. One project is considering shipping ReactOS as a LiveCD to allow their users to flash their USB devices without using Windows. I won't give name here, I let them study how suitable ReactOS is for their needs, and come back at us/release if that's OK. If I've got more news on this, I'll forward. On 02/06/2015 12:06 AM, Colin Finck wrote: Hi all, FOSDEM 2015 has ended some days ago. After five years of absence, the ReactOS Project was finally represented with a stand again, maintained by Aleksey Bragin, Giannis Adamopoulos, Pierre Schweitzer and me. Turns out that FOSDEM has significantly grown over the recent years, so our experiences really deserve a report - and should motivate others to join us next time! :) Our stand was born around 11 o'clock on Saturday when I arrived at the AW building. After walking several rounds in the building and neither finding known people nor a free table, it turned out that the coreboot guys next to us had tried to expand their presence a bit ;) Reclaiming our booth was a matter of a few words though, and soon we had a sweet spot in the building with enough space for the upcoming crowd. With Aleksey arriving shortly after that, along with several flags and pins, our empire was finally alive and marked! Giannis and Pierre arrived in the course of the day, right in time for the afternoon rush hour with lots of people interested in ReactOS. Our four person booth staff was really overwhelmed in these times. But let's see, maybe we even got new developers through this :) Our stock of 100 ReactOS demonstration CDs prepared by Hermès Bélusca-Maito and me already ran out during the first day. Given our experiences at other exhibitions and the general phase-out of CDs these days, this came totally unexpected. But it wouldn't be the ReactOS Project if we had no solution to the problem. On the same Saturday evening, Pierre and me went out on a little adventure into downtown Brussels in the hope of finding open stores that sell all we needed: Blank CDs, labels and paper sleeves. And we were successful! Returning with another 100 CDs, all disc drives of our laptops were working that evening and the full other day, busy with burning new ReactOS CDs. FOSDEM staff was kind enough to offer one of their printers for getting the additional labels done. And our booth on Sunday had partly turned into a CD manufacturing plant. With the consequence of people sometimes grabbing the CD labels and trying to read them before being presented with our real flyers :) At the end of the conference, around 170 ReactOS CDs were in the wild. Definitely much more than what we expected! Of course, the culinary supply also didn't come too short in the capital of Belgium. On Saturday evening, we met up with our friend Nuno Brito, who had already reserved a nice restaurant for us. Obviously, he had learned from last year! I well remember the evening, when five hungry geeks walked for half an hour through the city, trying to beat the unsolvable problem of finding the best restaurant for all of us. I've put up some of Aleksey's and my photos here: https://www.flickr.com/photos/colinfinck/sets/72157650656130121/ Maybe more to come in the next few days! I hope you're now all eager to join us next time to this wonderful event! Cheers, Colin P.S.: Feel free to use this for a news article about FOSDEM on our website ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 66101: [CDMAKE] It's totally pointless to nullify after calloc
It wasn't intended. Then, if you want to rethink the usage of calloc and/or redundant code, feel free. On 29/01/2015 00:03, Timo Kreuzer wrote: This code change doesn't help to make the code more readable. Am 28.01.2015 um 21:41 schrieb pschweit...@svn.reactos.org: Author: pschweitzer Date: Wed Jan 28 20:41:23 2015 New Revision: 66101 URL: http://svn.reactos.org/svn/reactos?rev=66101view=rev Log: [CDMAKE] It's totally pointless to nullify after calloc Modified: trunk/reactos/tools/cdmake/dirhash.c Modified: trunk/reactos/tools/cdmake/dirhash.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/cdmake/dirhash.c?rev=66101r1=66100r2=66101view=diff == --- trunk/reactos/tools/cdmake/dirhash.c[iso-8859-1] (original) +++ trunk/reactos/tools/cdmake/dirhash.c[iso-8859-1] Wed Jan 28 20:41:23 2015 @@ -137,8 +137,6 @@ free(parentcase); de = calloc(1, sizeof(*de)); -de-head = NULL; -de-child = NULL; de-parent = parent_de; de-normalized_name = strdup(targetnorm); de-case_name = strdup(chop_filename(casename)); ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Security issue on ReactOS.org website
Dear all, Just to make sure you read it: https://www.reactos.org/node/928 The SVN accounts are not affected. Cheers, -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
[ros-dev] Downtime tomorrow at noon CET
Dear all, Due to a hard disk dying, we'll attempt to anticipate its total death tomorrow at noon CET to change it before it quits working. It is a disk in one of our hypervisor. The following services will be hit: - ReactOS main website - Jira/Fisheye - Main DNS server - ReactOS community website Sorry for the caused inconvenience. With my best regards, -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 66022: [FREELDR]: Commit a temporary hackfix for (Pc)GetTime: on VBox when booting with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get CM
From our investigations (Timo I), there seems to be a memory
corruption when using a PXE boot on VBox.
You're committing a hack to workaround this memory corruption (which
replaces code which seems correct by some other code which is probably
correct), which lets you go a little bit further, where memory
corruption seems to strike again. And thus, this doesn't bring PXE boot
in better shape.
Furthermore, it appears that you're working around a bug which isn't in
ReactOS but in VBox. As a reminder, PXE boot works fine with Qemu, with
VMware. And when changing the ROM of VBox [1], then PXE boot works on
VBox as well.
Revert and report to VirtualBox instead. Our code is correct.
Thanks to Timo Hervé for their help on digging into this issue.
[1]: https://git.ipxe.org/ipxe.git/blob/HEAD:/src/config/vbox/README
On 10/01/2015 01:21, hbelu...@svn.reactos.org wrote:
Author: hbelusca
Date: Sat Jan 10 00:21:33 2015
New Revision: 66022
URL: http://svn.reactos.org/svn/reactos?rev=66022view=rev
Log:
[FREELDR]: Commit a temporary hackfix for (Pc)GetTime: on VBox when booting
with PXE, for some mysterious reason, Int386(0x1A) call with AH = 0x02 (Get
CMOS Time) *never ever* returns!! (however without PXE everything works).
So... is it some kind of stack overflow or whatever that makes the Int386
function stack messy? Or something else? So in the meantime we use direct
CMOS port reads. Timo, Hervé (and others), can you please review? And in
particular why does it happen only with PXE?
Modified:
trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c
Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c?rev=66022r1=66021r2=66022view=diff
==
--- trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1]
(original)
+++ trunk/reactos/boot/freeldr/freeldr/arch/i386/pcrtc.c [iso-8859-1]
Sat Jan 10 00:21:33 2015
@@ -20,10 +20,50 @@
#define BCD_INT(bcd) (((bcd 0xf0) 4) * 10 + (bcd 0x0f))
+#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED
+
+/* CMOS Registers and Ports */
+#define CMOS_CONTROL_PORT (PUCHAR)0x70
+#define CMOS_DATA_PORT (PUCHAR)0x71
+
+#define RTC_REGISTER_A 0x0A
+#define RTC_REG_A_UIP 0x80
+
+static UCHAR
+HalpReadCmos(IN UCHAR Reg)
+{
+/* Select the register */
+WRITE_PORT_UCHAR(CMOS_CONTROL_PORT, Reg);
+
+/* Query the value */
+return READ_PORT_UCHAR(CMOS_DATA_PORT);
+}
+
+#endif
+
TIMEINFO*
PcGetTime(VOID)
{
static TIMEINFO TimeInfo;
+
+#ifndef INT386_WITH_INT_1A_AH_02_04__IS__FIXED
+
+/* Loop while update is in progress */
+while ((HalpReadCmos(RTC_REGISTER_A)) RTC_REG_A_UIP);
+
+/* Set the time data */
+TimeInfo.Second = BCD_INT(HalpReadCmos(0));
+TimeInfo.Minute = BCD_INT(HalpReadCmos(2));
+TimeInfo.Hour = BCD_INT(HalpReadCmos(4));
+TimeInfo.Day = BCD_INT(HalpReadCmos(7));
+TimeInfo.Month = BCD_INT(HalpReadCmos(8));
+TimeInfo.Year = BCD_INT(HalpReadCmos(9));
+
+/* Compensate for the century field */
+TimeInfo.Year += (TimeInfo.Year 80) ? 1900: 2000;
+
+#else
+
REGS Regs;
for (;;)
@@ -86,6 +126,9 @@
break;
}
+
+#endif
+
return TimeInfo;
}
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] ReactOS Hybrid-USB Key attempt
On 08/01/2015 03:22, Hermès BÉLUSCA - MAÏTO wrote: - we still report strange dates when listing files from the livecd (at least when it is mounted as ramdisk), see the video. From the video, it appears to only affect directories and not normal files. Likely some bug in CDFS. -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 65982: [FREELDR] - Correctly append a backslash to the BootPath (if needed). - Be able to specify relative boot paths (relative to the current boot device): as a c
On 05/01/2015 00:49, hbelu...@svn.reactos.org wrote:
Author: hbelusca
Date: Sun Jan 4 23:49:18 2015
New Revision: 65982
URL: http://svn.reactos.org/svn/reactos?rev=65982view=rev
Log:
[FREELDR]
- Correctly append a backslash to the BootPath (if needed).
- Be able to specify relative boot paths (relative to the current boot
device): as a consequence, remove the LiveCD hackish special value that was
introduced long long ago.
- Fix BootPath retrieval in ReactOSSetup mode (via the SystemPath optional
value), and use a better way to build the temporary txtsetup.sif full file
names.
As a consequence we can now build hybrid cds with the following architecture:
\
-- loader\ (bootsectors + free/setupldr.sys)
-- myboot\ (contents of what_defaults_to_reactos directory for the bootcd)
-- mylive\ (contents of what_defaults_to_reactos directory for the livecd)
-- regular_files
and
freeldr.ini specifying the following values:
; The Setup entry
[Setup]
BootType=ReactOSSetup
SystemPath=\myboot
; The LiveCD entry
[LiveCD]
BootType=Windows2003
SystemPath=\mylive
Options=/MININT
Part 2/2
CORE-9023
Modified:
trunk/reactos/boot/bootdata/livecd.ini
trunk/reactos/boot/freeldr/freeldr/CHANGELOG
trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c
trunk/reactos/boot/freeldr/freeldr/windows/winldr.c
Modified: trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c?rev=65982r1=65981r2=65982view=diff
==
--- trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1]
(original)
+++ trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1]
Sun Jan 4 23:49:18 2015
@@ -178,17 +178,40 @@
HasSection = IniOpenSection(SectionName, SectionId);
UiDrawBackdrop();
-UiDrawProgressBarCenter(1, 100, Loading NT...);
+UiDrawProgressBarCenter(1, 100, Loading ReactOS Setup...);
/* Read the system path is set in the .ini file */
if (!HasSection ||
!IniReadSettingByName(SectionId, SystemPath, BootPath,
sizeof(BootPath)))
{
+// MachDiskGetBootPath(BootPath, sizeof(BootPath));
+// strcpy(BootPath, SectionName);
+}
Why?
Can you please stop commenting out code without further explanations?
Either you comment out (better doing so with #if 0, for the record) and
you explain why you do so alongside in the code, for next developers
coming into the code, or you don't comment out.
So, just don't answer here, just commit an explanation ;-).
Cheers,
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 65501: [FASTFAT] Set clean shutdown bit on dismount
First flag is set to inform that the second flag is to be removed on
dismount/shutdown.
Hence its removal.
On 11/27/2014 04:14 PM, Jérôme Gardou wrote:
Hey Pierre!
This flag
+if (DeviceExt-VolumeFcb-Flags VCB_CLEAR_DIRTY)
+{
+/* Set clean shutdown bit */
+Status = GetNextCluster(DeviceExt, 1, eocMark);
+if (NT_SUCCESS(Status))
+{
+eocMark |= DeviceExt-CleanShutBitMask;
+if (NT_SUCCESS(WriteCluster(DeviceExt, 1, eocMark)))
and that one
+DeviceExt-VolumeFcb-Flags = ~VCB_IS_DIRTY;
+}
+}
+
/* Flush volume files */
VfatFlushVolume(DeviceExt, (PVFATFCB)FileObject-FsContext);
don't really seem to match. Or is the former a part of a OR combination
defining the latter ?
Cheers.
Jérôme.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pie...@reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 65352: [NTOSKRNL] So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice
Not at all. Because it breaks most of the features we could expect from
1st stage. Such as formatting with something else than FAT.
So, having it enabled in 1st stage is a total defeat.
Having it disabled elsewhere just unlocks software that rely on volume
open (such as NTFS tools).
On 10/11/2014 10:50, Aleksey Bragin wrote:
Thank you for working on this hack (partial) removal!
After all, having it only in the 1st stage is a win over having it
enabled all the time.
Regards,
Aleksey
On 10.11.2014 12:45, pschweit...@svn.reactos.org wrote:
Author: pschweitzer
Date: Mon Nov 10 09:45:43 2014
New Revision: 65352
URL: http://svn.reactos.org/svn/reactos?rev=65352view=rev
Log:
[NTOSKRNL]
So... Because actual ReactOS mood is to worship hacks instead of
looking for proper fixes to have decent behavior: reenable the
IopParseDevice hack.
But, so far, only reenable it for the 1st stage: the most intensive
storage stack stage (unless you start playing with partitions
formating in 3rd stage).
CORE-8732 #resolve #comment Bug is now properly hidden with r65352
Modified:
trunk/reactos/ntoskrnl/io/iomgr/file.c
Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?rev=65352r1=65351r2=65352view=diff
==
--- trunk/reactos/ntoskrnl/io/iomgr/file.c[iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/io/iomgr/file.c[iso-8859-1] Mon Nov 10
09:45:43 2014
@@ -404,6 +404,27 @@
/* Check if we can simply use a dummy file */
UseDummyFile = ((OpenPacket-QueryOnly) ||
(OpenPacket-DeleteOnly));
+/* FIXME: Small hack still exists, have to check why...
+ * This is triggered multiple times by usetup and then once per
boot.
+ */
+if (ExpInTextModeSetup
+!(DirectOpen)
+!(RemainingName-Length)
+!(OpenPacket-RelatedFileObject)
+((wcsstr(CompleteName-Buffer, LHarddisk)) ||
+(wcsstr(CompleteName-Buffer, LFloppy)))
+!(UseDummyFile))
+{
+DPRINT1(Using IopParseDevice() hack. Requested invalid
attributes: %lx\n,
+DesiredAccess ~(SYNCHRONIZE |
+ FILE_READ_ATTRIBUTES |
+ READ_CONTROL |
+ ACCESS_SYSTEM_SECURITY |
+ WRITE_OWNER |
+ WRITE_DAC));
+DirectOpen = TRUE;
+}
+
/* Check if this is a direct open */
if (!(RemainingName-Length)
!(OpenPacket-RelatedFileObject)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 65352: [NTOSKRNL] So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice
Let me make a simple arrogant comment:
Challenge accepted :P
Best regards,
Pierre Schweitzer
On 10/11/2014 19:02, Alex Ionescu wrote:
Let me make a simple arrogant comment:
Don't try to fix hacks that I spent years trying to fix (and failed). They
just can't be fixed :P
Best regards,
Alex Ionescu
On Mon, Nov 10, 2014 at 1:45 AM, pschweit...@svn.reactos.org wrote:
Author: pschweitzer
Date: Mon Nov 10 09:45:43 2014
New Revision: 65352
URL: http://svn.reactos.org/svn/reactos?rev=65352view=rev
Log:
[NTOSKRNL]
So... Because actual ReactOS mood is to worship hacks instead of looking
for proper fixes to have decent behavior: reenable the IopParseDevice hack.
But, so far, only reenable it for the 1st stage: the most intensive
storage stack stage (unless you start playing with partitions formating
in 3rd stage).
CORE-8732 #resolve #comment Bug is now properly hidden with r65352
Modified:
trunk/reactos/ntoskrnl/io/iomgr/file.c
Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?rev=65352r1=65351r2=65352view=diff
==
--- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10
09:45:43 2014
@@ -404,6 +404,27 @@
/* Check if we can simply use a dummy file */
UseDummyFile = ((OpenPacket-QueryOnly) || (OpenPacket-DeleteOnly));
+/* FIXME: Small hack still exists, have to check why...
+ * This is triggered multiple times by usetup and then once per boot.
+ */
+if (ExpInTextModeSetup
+!(DirectOpen)
+!(RemainingName-Length)
+!(OpenPacket-RelatedFileObject)
+((wcsstr(CompleteName-Buffer, LHarddisk)) ||
+(wcsstr(CompleteName-Buffer, LFloppy)))
+!(UseDummyFile))
+{
+DPRINT1(Using IopParseDevice() hack. Requested invalid
attributes: %lx\n,
+DesiredAccess ~(SYNCHRONIZE |
+ FILE_READ_ATTRIBUTES |
+ READ_CONTROL |
+ ACCESS_SYSTEM_SECURITY |
+ WRITE_OWNER |
+ WRITE_DAC));
+DirectOpen = TRUE;
+}
+
/* Check if this is a direct open */
if (!(RemainingName-Length)
!(OpenPacket-RelatedFileObject)
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 65367: [PARTTEST] Add a dummy application that will open first disk and check first sector for MBR and then will open first partition to check for something kno
Heh
Interesting remark, this was actually taken from our FAT FSD. Which
means we don't support 64KB clusters at all in ReactOS...
Will look deeper into it then.
Thanks for the feedback.
On 10/11/2014 21:38, Michael Fritscher wrote:
Hi,
+if (Sector-BytesPerSector * Sector-SectorsPerCluster 32 * 1024)
+{
+return FALSE;
+}
FAT supports cluster sizes until 64KB ;-) At least the WinNT series can
work with them.
Best regards,
Michael Fritscher
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] NTFS in ReactOS: heise online article
On 08/11/2014 07:14, Thomas Mueller wrote: Dear Thomas, I really would like something readable and writable, like USB stick, as opposed to live CD. There's no easy way to do so. Even if you'd copy contents of the LiveCD to an USB drive, it wouldn't be writable, the CDFS driver we use is also read-only. Pierre Schweitzer pierre at reactos.org My idea was to build and use the ROSBE on FreeBSD, NetBSD or Linux to build the trunk, then install to a USB stick formatted FAT32. Question is whether that could boot. In theory, it could. In practice, I'm not that sure, you're really dependent on USB. And I'm not sure it's in a that good shape, unfortunately... Linux, the BSDs and Haiku can be installed on a USB stick, but I believe MS-Windows can't. I thought of buying a cheap refurbished SATA hard disk, maybe 80 or 160 GB, and using that to install ReactOS, FreeDOS and possibly something else (OpenBSD?), but ReactOS and FreeDOS have the limitation of having to be the first FAT16 or FAT32 partition on the disk, has to be drive C: I might set up to boot with Syslinux. Tom ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] NTFS in ReactOS: heise online article
Dear Thomas, This source of such article is a post from reboot.pro (http://reboot.pro/topic/20149-ntfs-now-supported-in-reactos-livecd/) where I report this progress and ask for help. On ReactOS website, you don't have such strong report, but the piece of information exists, spread in various places. People started talking about it on boards a few days ago. You have a short report about it in the latest ReactOS developer meeting minutes (https://www.reactos.org/node/909). And finally, the commits made on NTFS where kind of explicit about the progresses (coming along with pictures: https://git.reactos.org/?p=reactos.gita=searchh=HEADst=commits=[NTFS]). Note that the 0.3.17 release has initial, but not full (release process was started before everything could be developed) NTFS support. Testing from trunk is then the preferred method. Cheers, On 06/11/2014 05:57, Thomas Mueller wrote: I saw an article on heise online (German-language website) http://www.heise.de/newsticker/ on ReactOS liest NTFS http://www.heise.de/newsticker/meldung/ReactOS-liest-NTFS-2442615.html Date is 05.11.2014, meaning just yesterday. I subsequently looked on reactos.org and couldn't find any reference to this article. So far, this is only for reading NTFS on ReactOS; writing ability stil has to be worked on. This is the first article I've seen on this subject: looks like progress. Some ReactOS developers must be familiar with this? Tom ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 65166: [NTFS] Simplify buffer size management in GetNtfsFileRecord(). As tests shown, Windows doesn't care about the real size of the file record and expects th
You're missing line 611 where we check against size: Stack-Parameters.FileSystemControl.OutputBufferLength (FIELD_OFFSET(NTFS_FILE_RECORD_OUTPUT_BUFFER, FileRecordBuffer) + DeviceExt-NtfsInfo.BytesPerFileRecord) On 01/11/2014 11:13, Thomas Faber wrote: On 2014-11-01 11:02, pschweit...@svn.reactos.org wrote: -OutputBuffer-FileRecordLength = FileRecord-BytesInUse; -RtlCopyMemory(OutputBuffer-FileRecordBuffer, FileRecord, FileRecord-BytesInUse); +OutputBuffer-FileRecordLength = DeviceExt-NtfsInfo.BytesPerFileRecord; +RtlCopyMemory(OutputBuffer-FileRecordBuffer, FileRecord, DeviceExt-NtfsInfo.BytesPerFileRecord); Wait, now there's no check against OutputBufferLength at all? It should at least be min(DeviceExt-NtfsInfo.BytesPerFileRecord, Stack-Parameters.FileSystemControl.OutputBufferLength) in the memcpy size. Or am I missing something? ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 65140: [FASTFAT] - Fix renaming files in case the target file already exists. - Plug a few reference count leaks on FCBs. CORE-8660 #comment fixed in r65140 #resolv
isn't open by anyone! */
-if (TargetFcb-OpenHandleCount != 0)
-{
-vfatReleaseFCB(DeviceExt, *ParentFCB);
-*ParentFCB = NULL;
-vfatReleaseFCB(DeviceExt, TargetFcb);
-return STATUS_ACCESS_DENIED;
-}
-
/* Effectively delete old file to allow renaming */
+DPRINT(Effectively deleting the file.\n);
VfatDelEntry(DeviceExt, TargetFcb, NULL);
-vfatGrabFCB(DeviceExt, *ParentFCB);
vfatReleaseFCB(DeviceExt, TargetFcb);
*Deleted = TRUE;
+return STATUS_SUCCESS;
}
else
{
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [akhaldi] 64994: [ADVAPI32] * Update ImpersonateNamedPipeClient(). CORE-8540
And it changes behavior of the functions.
I'd rather trust a !NT_SUCESS(Status)) than a status. This means these
functions with Wine code would fail on an informational status (whereas
they didn't before). Is it intentional? Do we have tests to assess such
behavior?
It's a bit a shame to replace well written ReactOS to Wine code with
broken style :-(.
On 25/10/2014 22:10, Ged Murphy wrote:
Eeww, these are a bit ugly :(
On 25/10/2014 19:30, akha...@svn.reactos.org akha...@svn.reactos.org
wrote:
Author: akhaldi
Date: Sat Oct 25 18:30:05 2014
New Revision: 64994
URL: http://svn.reactos.org/svn/reactos?rev=64994view=rev
Log:
[ADVAPI32]
* Update ImpersonateNamedPipeClient().
CORE-8540
Modified:
trunk/reactos/dll/win32/advapi32/wine/security.c
Modified: trunk/reactos/dll/win32/advapi32/wine/security.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/wine/s
ecurity.c?rev=64994r1=64993r2=64994view=diff
==
--- trunk/reactos/dll/win32/advapi32/wine/security.c [iso-8859-1]
(original)
+++ trunk/reactos/dll/win32/advapi32/wine/security.c [iso-8859-1] Sat Oct
25 18:30:05 2014
@@ -954,37 +954,14 @@
return TRUE;
}
-/**
- * ImpersonateNamedPipeClient EXPORTED
- *
- * @implemented
- */
-BOOL
-WINAPI
-ImpersonateNamedPipeClient(HANDLE hNamedPipe)
-{
-IO_STATUS_BLOCK StatusBlock;
-NTSTATUS Status;
-
-TRACE(ImpersonateNamedPipeClient() called\n);
-
-Status = NtFsControlFile(hNamedPipe,
- NULL,
- NULL,
- NULL,
- StatusBlock,
- FSCTL_PIPE_IMPERSONATE,
- NULL,
- 0,
- NULL,
- 0);
-if (!NT_SUCCESS(Status))
-{
-SetLastError(RtlNtStatusToDosError(Status));
-return FALSE;
-}
-
-return TRUE;
+BOOL WINAPI ImpersonateNamedPipeClient( HANDLE hNamedPipe )
+{
+IO_STATUS_BLOCK io_block;
+
+TRACE((%p)\n, hNamedPipe);
+
+return set_ntstatus( NtFsControlFile(hNamedPipe, NULL, NULL, NULL,
+ io_block, FSCTL_PIPE_IMPERSONATE, NULL, 0,
NULL, 0) );
}
/*
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 64752: [NTFS] Implement NtfsDateTimeToFileTime() which convert epoch time (1970) to Windows time (1601)
My link says: Values are stored in universal coordinated time, like in
Linux.
This is what I interpret as: stored with epoch, need to shift to 1601.
On 15/10/2014 22:46, Thomas Faber wrote:
On 2014-10-15 22:23, pschweit...@svn.reactos.org wrote:
+/* See:
+ - http://msdn.microsoft.com/en-us/library/ms724228
+ - http://bos.asmhackers.net/docs/filesystems/ntfs/standard.html#layout
+ */
+VOID
+NtfsDateTimeToFileTime(ULONGLONG NtfsTime,
+ PLARGE_INTEGER SystemTime)
+{
+
+SystemTime-QuadPart = NtfsTime + 1164447360;
+}
Doesn't NTFS use FILETIME directly? I thought that's the reason it's
called file time in the first place. ;)
Wikipedia says
Date range: 1 January 1601 – 28 May 60056 (File times are 64-bit
numbers counting 100-nanosecond intervals (ten million per second)
since 1601, which is 58,000+ years)
and your link doesn't seem to disagree.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 64617: [NTFS] - Add a directory entry into FCB which will be a copy of the $FILE_NAME attribute of the FILE record. Though, it won't contain the name itself (in
Ah yes! Oopsie :-$
Let's not add more leaks into it!
On 08/10/2014 21:54, Thomas Faber wrote:
On 2014-10-08 21:32, pschweit...@svn.reactos.org wrote:
+MftRecord = ExAllocatePoolWithTag(NonPagedPool,
+ Vcb-NtfsInfo.BytesPerFileRecord,
+ TAG_NTFS);
+if (MftRecord == NULL)
+{
+return NULL;
+}
+
+if (!NT_SUCCESS(ReadFileRecord(Vcb, NTFS_FILE_ROOT, MftRecord)))
+{
+return NULL;
+}
+
+FileName = GetFileNameFromRecord(MftRecord);
+if (!FileName)
+{
+return NULL;
+}
Fcb = NtfsCreateFCB(L\\, Vcb);
-
-//memset(Fcb-entry.Filename, ' ', 11);
-
-//Fcb-Entry.DataLengthL = Vcb-CdInfo.RootSize;
-//Fcb-Entry.ExtentLocationL = Vcb-CdInfo.RootStart;
-//Fcb-Entry.FileFlags = 0x02; // FILE_ATTRIBUTE_DIRECTORY;
+if (!Fcb)
+{
+return NULL;
+}
These failure cases look like they're all at least leaking MftRecord :p
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzer pierre at reactos.org
System Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Topics for next meeting
Hi, For Jira issues (whatever it is), please report to Ziliang. For on-demand builders, the replacement Windows machine is being worked on by Colin. So, it should provide again MSVC. Patch builder already exists. There have been a request to make it hybrid on-demand. CLang, x64 ARM would require some work on RosBE first. For testot on Windows 2003, refer to: https://jira.reactos.org/browse/ONLINE-441 Cheers, On 15/09/2014 21:43, Timo Kreuzer wrote: Hi, I'd like to propose some topics for the next meeting: - Agile missing in Jira (looks like an incompatible version) - new on-demand builders (Clang, VC, x64, arm, branch, patch) - testbot on a win 2003 machine Timo ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [jgardou] 64121: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permit
Awesome, indeed! Any info or tuto about how to use it? About how to plug GDB to it? Cheers, On 09/12/2014 12:57 AM, Timo Kreuzer wrote: Awesome stuff! Am 11.09.2014 22:55, schrieb jgar...@svn.reactos.org: Author: jgardou Date: Thu Sep 11 20:55:42 2014 New Revision: 64121 URL: http://svn.reactos.org/svn/reactos?rev=64121view=rev Log: [KDGDB] - introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together. It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work) To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pie...@reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Fezile server down
Proxmox VE is an hypervisor (and thus an OS). We're talking about hardware here. IPMI like and so on. On 31/07/2014 19:14, Stefan L. wrote: what about going proxmox ve? You don't need a management card necessarily. Best regards, Stefan 2014-07-31 10:36 GMT+02:00 Colin Finck co...@reactos.org: Colin Finck co...@reactos.org wrote: Checked shipping with all vendors now. The Portuguese one for the ASMB3-iKVM did not reply while the Australian one did. Their total price incl. shipping is around 158$, which is ~116 EUR. Unfortunately, we have to start over on this again. I've been struggling with the Australian dealer for over one month now, as it decided to raise shipping costs tenfold and then expected me to submit my credit card details over plain E-Mail... They finally cancelled the transaction today and issued a refund for my already paid costs. So, suggestions are welcome again for alternative dealers :) The Portuguese ones still don't reply. Has anybody seen other locations for getting an ASMB3-iKVM? The Tyan board has been shipped and will be tested when Jan is back from vacations. Cheers, Colin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Status Meeting (July 2014)
Hi, The credentials just have been sent and the server started. As a reminder, the server is running on fezile.reactos.org:6667, channel #meeting. No SSL (yet). In case you didn't have your credentials, you cannot attend the meeting (private). Contact me if anything wrong. Regards, On 30/07/2014 11:11, Aleksey Bragin wrote: Hello, Let me invite you to the monthly status meeting taking place tomorrow, 31st of July, 19:00 UTC. If there are any proposals regarding moving the meeting date/time - please send them today. 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. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Also all developers, please, may I so kindly ask you to prepare a very brief one-two lines message containing two things: 1. What you did since the previous meeting 2. What you are going to do in the coming month This is needed to understand who is working on what, to plan things, etc. Prepare that in advance! Everyone will have max 1 minute! Regards, Aleksey Bragin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzer pierre at reactos.org System Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Jira comments
Fisheye has been upgraded to a release that fixes ONLINE-461 (and hence smart commits). No announcement yet, nor issue closing. We need to make sure it's working 100%. On 26/06/2014 21:51, Hermès BÉLUSCA - MAÏTO wrote: Hey guys ! It seems that suddently Jira SVN comments work again How is it possible? H. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 63599: [TASKMGR]: Use the EndTask API to kill tasks.
On 15/06/2014 19:47, hbelu...@svn.reactos.org wrote: +/* Trick: on Windows, pressing the CTRL key forces the task to be ended */ +BOOL ForceEndTask = !!(GetKeyState(VK_CONTROL) 0x8000); + Was it really meant to be '!!'? -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Upgrade complete
As a side note, upgrade to Fisheye 3.4.4 didn't fix ONLINE-461 (which was the main reason behind the upgrade). On 15/06/2014 00:36, Zachary Gorden wrote: Fisheye was upgraded successfully, Jira went off the rails and took us about three hours to recover from. Please report any data loss as we had to restore from backups. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Upgrade complete
Fixed. On 15/06/2014 00:56, Alexander Rechitskiy wrote: https://code.reactos.org/ does NOT work 15.06.2014, 02:40, Pierre Schweitzer pie...@reactos.org: As a side note, upgrade to Fisheye 3.4.4 didn't fix ONLINE-461 (which was the main reason behind the upgrade). On 15/06/2014 00:36, Zachary Gorden wrote: Fisheye was upgraded successfully, Jira went off the rails and took us about three hours to recover from. Please report any data loss as we had to restore from backups. ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation , ___ Ros-dev mailing list Ros-dev@reactos.org mailto:Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Best regards, ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Status Meeting (May 2014)
Hi, The credentials for the meeting just have been sent. If you didn't receive them whereas you should, please contact me. The meeting will take place in ~45 mins, in #meeting on fezile.reactos.org (6667, no SSL). Unless you have credentials, you won't be able to join the meeting. With my best regards, On 02/06/2014 21:32, Aleksey Bragin wrote: Hello, Let me invite you to the monthly status meeting taking place first Thursday of this month, 5th of June, 19:00 UTC. And this date is very close to now! The meeting was rescheduled from the usual date because of my trips and my illness. Sorry about that. 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. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. However the most demanded topic is ReactOS fundraising campaign and its outcome :-) Also all developers, please, may I so kindly ask you to prepare a very brief one-two lines message containing two things: 1. What you did since the previous meeting 2. What you are going to do in the coming month This is needed to understand who is working on what, to plan things, etc. Thanks, I hope it's not that much to ask for. Regards, Aleksey Bragin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [hbelusca] 63398: [USETUP] - Fix a bit the translation of yesterday; - Use TEXT_PADDING_BIG instead of hardcoding 3 spaces in the status messages.
On 05/21/2014 02:23 PM, hbelu...@svn.reactos.org wrote:
Author: hbelusca
Date: Wed May 21 12:23:04 2014
New Revision: 63398
URL: http://svn.reactos.org/svn/reactos?rev=63398view=rev
Log:
[USETUP]
- Fix a bit the translation of yesterday;
- Use TEXT_PADDING_BIG instead of hardcoding 3 spaces in the status messages.
Modified:
trunk/reactos/base/setup/usetup/lang/fr-FR.h
Modified: trunk/reactos/base/setup/usetup/lang/fr-FR.h
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/base/setup/usetup/lang/fr-FR.h?rev=63398r1=63397r2=63398view=diff
==
--- trunk/reactos/base/setup/usetup/lang/fr-FR.h [iso-8859-1] (original)
+++ trunk/reactos/base/setup/usetup/lang/fr-FR.h [iso-8859-1] Wed May 21
12:23:04 2014
@@ -642,8 +642,8 @@
{
0,
0,
- Veuillez attendre ...,
-TEXT_TYPE_STATUS,
+Veuillez attendre ...,
+TEXT_TYPE_STATUS | TEXT_PADDING_BIG
},
{
0,
It would be better to have Veuillez patienter...
Attendre sounds so weird in that context.
@@ -850,8 +850,8 @@
{
0,
0,
- Patienter...,
-TEXT_TYPE_STATUS
+Patienter...,
+TEXT_TYPE_STATUS | TEXT_PADDING_BIG
},
{
0,
Here, it's likely to be Patientez... (to be checked though).
--
Pierre Schweitzer pie...@reactos.org
System Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [ekohl] 63326: [NTOSKRNL] xHalIoReadPartitionTable: Only used non-container partition entries have a non-zero partition number.
Hey Eric,
This fix unfortunately broke trunk. Our four testbots are red.
Have a look here, for instance:
http://build.reactos.org/builders/Linux_AMD64_1%20KVM-Test/builds/6442/steps/test/logs/stdio
Cheers,
Pierre
On 17/05/2014 14:55, ek...@svn.reactos.org wrote:
Author: ekohl
Date: Sat May 17 12:55:06 2014
New Revision: 63326
URL: http://svn.reactos.org/svn/reactos?rev=63326view=rev
Log:
[NTOSKRNL]
xHalIoReadPartitionTable: Only used non-container partition entries have a
non-zero partition number.
Modified:
trunk/reactos/ntoskrnl/fstub/disksup.c
Modified: trunk/reactos/ntoskrnl/fstub/disksup.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fstub/disksup.c?rev=63326r1=63325r2=63326view=diff
==
--- trunk/reactos/ntoskrnl/fstub/disksup.c[iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/fstub/disksup.c[iso-8859-1] Sat May 17
12:55:06 2014
@@ -1655,8 +1655,7 @@
UInt32x32To64(GET_PARTITION_LENGTH(PartitionDescriptor),
SectorSize);
-/* FIXME: REACTOS HACK */
-PartitionInfo-PartitionNumber = i + 1;
+PartitionInfo-PartitionNumber =
(!IsContainerPartition(PartitionType)) ? i : 0;
}
else
{
@@ -1667,7 +1666,6 @@
PartitionInfo-PartitionLength.QuadPart = 0;
PartitionInfo-HiddenSectors = 0;
-/* FIXME: REACTOS HACK */
PartitionInfo-PartitionNumber = 0;
}
}
--
Pierre Schweitzerpierre at reactos.org
System Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Status Meeting (April 2014)
The credentials for the meeting just have been sent, and the server has been started. As a reminder, the meeting will be on fezile.reactos.org, port 6667 (no SSL), channel #meeting. The meeting will be private. If you don't have credentials, you cannot attend it. In case you didn't receive your credentials where you should, please contact me. Regards, On 23/04/2014 23:02, Aleksey Bragin wrote: Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 24th of April, 19:00 UTC. And this date is very close to now! 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. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev -- Pierre Schweitzerpierre at reactos.org System Administrator ReactOS Foundation smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] [ros-diffs] [pschweitzer] 62779: [CDFS] Convert FCB pathname from simple buffer to unicode string. Please carefully review if I missed something
Thanks for your feedback. I fixed these.
On 19/04/2014 09:31, Thomas Faber wrote:
On 2014-04-18 23:40, pschweit...@svn.reactos.org wrote:
--- trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] (original)
+++ trunk/reactos/drivers/filesystems/cdfs/fcb.c [iso-8859-1] Fri Apr 18
21:40:02 2014
@@ -129,7 +131,7 @@
BOOLEAN
CdfsFCBIsRoot(PFCB Fcb)
{
-return(wcscmp(Fcb-PathName, L\\) == 0);
+return (Fcb-PathName.Length = sizeof(WCHAR) Fcb-PathName.Buffer[0]
== L'\\');
}
==
Generally I'm seeing a lot of manual work where
RtlInitEmptyUnicodeString and RtlCopyUnicodeString could be used.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--
Pierre Schweitzerpierre at reactos.org
System Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
