2004-05-30 14:54:02 +00:00
|
|
|
/*
|
|
|
|
* ReactOS kernel
|
|
|
|
* Copyright (C) 2004 ReactOS Team
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
2009-10-27 10:34:16 +00:00
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
2004-05-30 14:54:02 +00:00
|
|
|
*/
|
2005-09-19 08:11:43 +00:00
|
|
|
/* COPYRIGHT: See COPYING in the top level directory
|
2004-05-30 14:54:02 +00:00
|
|
|
* PROJECT: ReactOS text-mode setup
|
2015-09-13 16:40:36 +00:00
|
|
|
* FILE: base/setup/usetup/settings.c
|
2004-05-30 14:54:02 +00:00
|
|
|
* PURPOSE: Device settings support functions
|
2018-05-27 19:33:07 +00:00
|
|
|
* PROGRAMMERS: Colin Finck
|
2004-05-30 14:54:02 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES *****************************************************************/
|
|
|
|
|
2006-08-31 09:13:03 +00:00
|
|
|
#include "usetup.h"
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2010-06-07 21:38:49 +00:00
|
|
|
#define NDEBUG
|
2004-05-30 14:54:02 +00:00
|
|
|
#include <debug.h>
|
|
|
|
|
2014-05-12 16:14:19 +00:00
|
|
|
/* GLOBALS ******************************************************************/
|
|
|
|
|
|
|
|
ULONG DefaultLanguageIndex = 0;
|
|
|
|
|
2004-05-30 14:54:02 +00:00
|
|
|
/* FUNCTIONS ****************************************************************/
|
|
|
|
|
2014-05-12 16:14:19 +00:00
|
|
|
static
|
|
|
|
BOOLEAN
|
2011-08-15 06:27:23 +00:00
|
|
|
IsAcpiComputer(VOID)
|
|
|
|
{
|
2014-05-12 16:14:19 +00:00
|
|
|
UNICODE_STRING MultiKeyPathU = RTL_CONSTANT_STRING(L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\MultifunctionAdapter");
|
|
|
|
UNICODE_STRING IdentifierU = RTL_CONSTANT_STRING(L"Identifier");
|
|
|
|
UNICODE_STRING AcpiBiosIdentifier = RTL_CONSTANT_STRING(L"ACPI BIOS");
|
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
PKEY_BASIC_INFORMATION pDeviceInformation = NULL;
|
|
|
|
ULONG DeviceInfoLength = sizeof(KEY_BASIC_INFORMATION) + 50 * sizeof(WCHAR);
|
|
|
|
PKEY_VALUE_PARTIAL_INFORMATION pValueInformation = NULL;
|
|
|
|
ULONG ValueInfoLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION) + 50 * sizeof(WCHAR);
|
|
|
|
ULONG RequiredSize;
|
|
|
|
ULONG IndexDevice = 0;
|
|
|
|
UNICODE_STRING DeviceName, ValueName;
|
|
|
|
HANDLE hDevicesKey = NULL;
|
|
|
|
HANDLE hDeviceKey = NULL;
|
|
|
|
NTSTATUS Status;
|
|
|
|
BOOLEAN ret = FALSE;
|
|
|
|
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&MultiKeyPathU,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
Status = NtOpenKey(&hDevicesKey,
|
|
|
|
KEY_ENUMERATE_SUB_KEYS,
|
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtOpenKey() failed with status 0x%08lx\n", Status);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-08-15 06:27:23 +00:00
|
|
|
|
2017-08-28 13:50:40 +00:00
|
|
|
pDeviceInformation = RtlAllocateHeap(RtlGetProcessHeap(), 0, DeviceInfoLength);
|
|
|
|
if (!pDeviceInformation)
|
|
|
|
{
|
|
|
|
DPRINT("RtlAllocateHeap() failed\n");
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
pValueInformation = RtlAllocateHeap(RtlGetProcessHeap(), 0, ValueInfoLength);
|
|
|
|
if (!pValueInformation)
|
|
|
|
{
|
|
|
|
DPRINT("RtlAllocateHeap() failed\n");
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (TRUE)
|
|
|
|
{
|
|
|
|
Status = NtEnumerateKey(hDevicesKey,
|
|
|
|
IndexDevice,
|
|
|
|
KeyBasicInformation,
|
|
|
|
pDeviceInformation,
|
|
|
|
DeviceInfoLength,
|
|
|
|
&RequiredSize);
|
|
|
|
if (Status == STATUS_NO_MORE_ENTRIES)
|
|
|
|
break;
|
|
|
|
else if (Status == STATUS_BUFFER_OVERFLOW || Status == STATUS_BUFFER_TOO_SMALL)
|
|
|
|
{
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pDeviceInformation);
|
|
|
|
DeviceInfoLength = RequiredSize;
|
|
|
|
pDeviceInformation = RtlAllocateHeap(RtlGetProcessHeap(), 0, DeviceInfoLength);
|
|
|
|
if (!pDeviceInformation)
|
|
|
|
{
|
|
|
|
DPRINT("RtlAllocateHeap() failed\n");
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
Status = NtEnumerateKey(hDevicesKey,
|
|
|
|
IndexDevice,
|
|
|
|
KeyBasicInformation,
|
|
|
|
pDeviceInformation,
|
|
|
|
DeviceInfoLength,
|
|
|
|
&RequiredSize);
|
|
|
|
}
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtEnumerateKey() failed with status 0x%08lx\n", Status);
|
2011-08-15 06:27:23 +00:00
|
|
|
goto cleanup;
|
2017-08-28 13:50:40 +00:00
|
|
|
}
|
|
|
|
IndexDevice++;
|
|
|
|
|
|
|
|
/* Open device key */
|
|
|
|
DeviceName.Length = DeviceName.MaximumLength = pDeviceInformation->NameLength;
|
|
|
|
DeviceName.Buffer = pDeviceInformation->Name;
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&DeviceName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
hDevicesKey,
|
|
|
|
NULL);
|
|
|
|
Status = NtOpenKey(&hDeviceKey,
|
|
|
|
KEY_QUERY_VALUE,
|
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtOpenKey() failed with status 0x%08lx\n", Status);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read identifier */
|
|
|
|
Status = NtQueryValueKey(hDeviceKey,
|
|
|
|
&IdentifierU,
|
|
|
|
KeyValuePartialInformation,
|
|
|
|
pValueInformation,
|
|
|
|
ValueInfoLength,
|
|
|
|
&RequiredSize);
|
|
|
|
if (Status == STATUS_BUFFER_OVERFLOW || Status == STATUS_BUFFER_TOO_SMALL)
|
|
|
|
{
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pValueInformation);
|
|
|
|
ValueInfoLength = RequiredSize;
|
|
|
|
pValueInformation = RtlAllocateHeap(RtlGetProcessHeap(), 0, ValueInfoLength);
|
|
|
|
if (!pValueInformation)
|
|
|
|
{
|
|
|
|
DPRINT("RtlAllocateHeap() failed\n");
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
Status = NtQueryValueKey(hDeviceKey,
|
|
|
|
&IdentifierU,
|
|
|
|
KeyValuePartialInformation,
|
|
|
|
pValueInformation,
|
|
|
|
ValueInfoLength,
|
|
|
|
&RequiredSize);
|
|
|
|
}
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtQueryValueKey() failed with status 0x%08lx\n", Status);
|
|
|
|
goto nextdevice;
|
|
|
|
}
|
|
|
|
else if (pValueInformation->Type != REG_SZ)
|
|
|
|
{
|
|
|
|
DPRINT("Wrong registry type: got 0x%lx, expected 0x%lx\n", pValueInformation->Type, REG_SZ);
|
|
|
|
goto nextdevice;
|
|
|
|
}
|
|
|
|
|
|
|
|
ValueName.Length = ValueName.MaximumLength = pValueInformation->DataLength;
|
|
|
|
ValueName.Buffer = (PWCHAR)pValueInformation->Data;
|
|
|
|
if (ValueName.Length >= sizeof(WCHAR) && ValueName.Buffer[ValueName.Length / sizeof(WCHAR) - 1] == UNICODE_NULL)
|
|
|
|
ValueName.Length -= sizeof(WCHAR);
|
|
|
|
if (RtlEqualUnicodeString(&ValueName, &AcpiBiosIdentifier, FALSE))
|
|
|
|
{
|
|
|
|
DPRINT("Found ACPI BIOS\n");
|
|
|
|
ret = TRUE;
|
2011-08-15 06:27:23 +00:00
|
|
|
goto cleanup;
|
2017-08-28 13:50:40 +00:00
|
|
|
}
|
2011-08-15 06:27:23 +00:00
|
|
|
|
|
|
|
nextdevice:
|
2017-08-28 13:50:40 +00:00
|
|
|
NtClose(hDeviceKey);
|
|
|
|
hDeviceKey = NULL;
|
|
|
|
}
|
2011-08-15 06:27:23 +00:00
|
|
|
|
|
|
|
cleanup:
|
2017-08-28 13:50:40 +00:00
|
|
|
if (pDeviceInformation)
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pDeviceInformation);
|
|
|
|
if (pValueInformation)
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pValueInformation);
|
|
|
|
if (hDevicesKey)
|
|
|
|
NtClose(hDevicesKey);
|
|
|
|
if (hDeviceKey)
|
|
|
|
NtClose(hDeviceKey);
|
|
|
|
return ret;
|
2011-08-15 06:27:23 +00:00
|
|
|
}
|
|
|
|
|
2014-05-12 16:14:19 +00:00
|
|
|
static
|
|
|
|
BOOLEAN
|
|
|
|
GetComputerIdentifier(
|
|
|
|
PWSTR Identifier,
|
|
|
|
ULONG IdentifierLength)
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
UNICODE_STRING KeyName;
|
|
|
|
LPCWSTR ComputerIdentifier;
|
|
|
|
HANDLE ProcessorsKey;
|
|
|
|
PKEY_FULL_INFORMATION pFullInfo;
|
|
|
|
ULONG Size, SizeNeeded;
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
|
|
|
DPRINT("GetComputerIdentifier() called\n");
|
|
|
|
|
|
|
|
Size = sizeof(KEY_FULL_INFORMATION);
|
|
|
|
pFullInfo = (PKEY_FULL_INFORMATION)RtlAllocateHeap(RtlGetProcessHeap(), 0, Size);
|
|
|
|
if (!pFullInfo)
|
|
|
|
{
|
|
|
|
DPRINT("RtlAllocateHeap() failed\n");
|
|
|
|
return FALSE;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Open the processors key */
|
|
|
|
RtlInitUnicodeString(&KeyName,
|
|
|
|
L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor");
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenKey(&ProcessorsKey,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
KEY_QUERY_VALUE,
|
2008-01-07 17:22:05 +00:00
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtOpenKey() failed (Status 0x%lx)\n", Status);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pFullInfo);
|
|
|
|
return FALSE;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Get number of subkeys */
|
2014-05-12 16:14:19 +00:00
|
|
|
Status = NtQueryKey(ProcessorsKey,
|
|
|
|
KeyFullInformation,
|
|
|
|
pFullInfo,
|
|
|
|
Size,
|
|
|
|
&Size);
|
2008-01-07 17:22:05 +00:00
|
|
|
NtClose(ProcessorsKey);
|
|
|
|
if (!NT_SUCCESS(Status) && Status != STATUS_BUFFER_OVERFLOW)
|
|
|
|
{
|
|
|
|
DPRINT("NtQueryKey() failed (Status 0x%lx)\n", Status);
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pFullInfo);
|
|
|
|
return FALSE;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Find computer identifier */
|
|
|
|
if (pFullInfo->SubKeys == 0)
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Something strange happened. No processor detected */
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pFullInfo);
|
|
|
|
return FALSE;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2011-08-15 06:27:23 +00:00
|
|
|
if (IsAcpiComputer())
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2011-08-15 06:27:23 +00:00
|
|
|
if (pFullInfo->SubKeys == 1)
|
|
|
|
{
|
|
|
|
/* Computer is mono-CPU */
|
|
|
|
ComputerIdentifier = L"ACPI UP";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Computer is multi-CPUs */
|
|
|
|
ComputerIdentifier = L"ACPI MP";
|
|
|
|
}
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
2008-01-07 17:22:05 +00:00
|
|
|
else
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2011-08-15 06:27:23 +00:00
|
|
|
if (pFullInfo->SubKeys == 1)
|
|
|
|
{
|
|
|
|
/* Computer is mono-CPU */
|
|
|
|
ComputerIdentifier = L"PC UP";
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Computer is multi-CPUs */
|
|
|
|
ComputerIdentifier = L"PC MP";
|
|
|
|
}
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, pFullInfo);
|
|
|
|
|
|
|
|
/* Copy computer identifier to return buffer */
|
|
|
|
SizeNeeded = (wcslen(ComputerIdentifier) + 1) * sizeof(WCHAR);
|
|
|
|
if (SizeNeeded > IdentifierLength)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
RtlCopyMemory(Identifier, ComputerIdentifier, SizeNeeded);
|
|
|
|
|
|
|
|
return TRUE;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
/*
|
|
|
|
* Return values:
|
|
|
|
* 0x00: Failure, stop the enumeration;
|
|
|
|
* 0x01: Add the entry and continue the enumeration;
|
|
|
|
* 0x02: Skip the entry but continue the enumeration.
|
|
|
|
*/
|
|
|
|
typedef UCHAR
|
|
|
|
(NTAPI *PPROCESS_ENTRY_ROUTINE)(
|
|
|
|
IN PWCHAR KeyName,
|
|
|
|
IN PWCHAR KeyValue,
|
|
|
|
IN PCHAR DisplayText,
|
|
|
|
IN SIZE_T DisplayTextSize,
|
|
|
|
OUT PVOID* UserData,
|
|
|
|
OUT PBOOLEAN Current,
|
|
|
|
IN PVOID Parameter OPTIONAL);
|
|
|
|
|
|
|
|
LONG
|
|
|
|
AddEntriesFromInfSection(
|
|
|
|
IN OUT PGENERIC_LIST List,
|
|
|
|
IN HINF InfFile,
|
|
|
|
IN PCWSTR SectionName,
|
|
|
|
IN PINFCONTEXT pContext,
|
|
|
|
IN PPROCESS_ENTRY_ROUTINE ProcessEntry,
|
|
|
|
IN PVOID Parameter OPTIONAL)
|
|
|
|
{
|
|
|
|
LONG TotalCount = 0;
|
|
|
|
PWCHAR KeyName;
|
|
|
|
PWCHAR KeyValue;
|
|
|
|
PVOID UserData;
|
|
|
|
BOOLEAN Current;
|
|
|
|
UCHAR RetVal;
|
|
|
|
CHAR DisplayText[128];
|
|
|
|
|
|
|
|
if (!SetupFindFirstLineW(InfFile, SectionName, NULL, pContext))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
do
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* NOTE: Do not use INF_GetData() as it expects INF entries of exactly
|
|
|
|
* two fields ("key = value"); however we expect to be able to deal with
|
|
|
|
* entries having more than two fields, the only requirement being that
|
|
|
|
* the second field (field number 1) contains the field description.
|
|
|
|
*/
|
|
|
|
if (!INF_GetDataField(pContext, 0, &KeyName))
|
|
|
|
{
|
|
|
|
DPRINT("INF_GetDataField() failed\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!INF_GetDataField(pContext, 1, &KeyValue))
|
|
|
|
{
|
|
|
|
DPRINT("INF_GetDataField() failed\n");
|
|
|
|
INF_FreeData(KeyName);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
UserData = NULL;
|
|
|
|
Current = FALSE;
|
|
|
|
RetVal = ProcessEntry(KeyName,
|
|
|
|
KeyValue,
|
|
|
|
DisplayText,
|
|
|
|
sizeof(DisplayText),
|
|
|
|
&UserData,
|
|
|
|
&Current,
|
|
|
|
Parameter);
|
|
|
|
INF_FreeData(KeyName);
|
|
|
|
INF_FreeData(KeyValue);
|
|
|
|
|
|
|
|
if (RetVal == 0)
|
|
|
|
{
|
|
|
|
DPRINT("ProcessEntry() failed\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
else if (RetVal == 1)
|
|
|
|
{
|
|
|
|
AppendGenericListEntry(List, DisplayText, UserData, Current);
|
|
|
|
++TotalCount;
|
|
|
|
}
|
|
|
|
// else if (RetVal == 2), skip the entry.
|
|
|
|
|
|
|
|
} while (SetupFindNextLine(pContext, pContext));
|
|
|
|
|
|
|
|
return TotalCount;
|
|
|
|
}
|
|
|
|
|
|
|
|
static UCHAR
|
|
|
|
NTAPI
|
|
|
|
DefaultProcessEntry(
|
|
|
|
IN PWCHAR KeyName,
|
|
|
|
IN PWCHAR KeyValue,
|
|
|
|
IN PCHAR DisplayText,
|
|
|
|
IN SIZE_T DisplayTextSize,
|
|
|
|
OUT PVOID* UserData,
|
|
|
|
OUT PBOOLEAN Current,
|
|
|
|
IN PVOID Parameter OPTIONAL)
|
|
|
|
{
|
|
|
|
PWSTR CompareKey = (PWSTR)Parameter;
|
|
|
|
|
|
|
|
*UserData = RtlAllocateHeap(ProcessHeap, 0,
|
|
|
|
(wcslen(KeyName) + 1) * sizeof(WCHAR));
|
|
|
|
if (*UserData == NULL)
|
|
|
|
{
|
|
|
|
/* Failure, stop enumeration */
|
|
|
|
DPRINT1("RtlAllocateHeap() failed\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
wcscpy((PWCHAR)*UserData, KeyName);
|
|
|
|
sprintf(DisplayText, "%S", KeyValue);
|
|
|
|
|
|
|
|
*Current = (CompareKey ? !_wcsicmp(KeyName, CompareKey) : FALSE);
|
|
|
|
|
|
|
|
/* Add the entry */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-05-30 14:54:02 +00:00
|
|
|
PGENERIC_LIST
|
2014-05-12 16:14:19 +00:00
|
|
|
CreateComputerTypeList(
|
|
|
|
HINF InfFile)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
PGENERIC_LIST List;
|
|
|
|
INFCONTEXT Context;
|
|
|
|
PWCHAR KeyName;
|
|
|
|
PWCHAR KeyValue;
|
|
|
|
WCHAR ComputerIdentifier[128];
|
|
|
|
WCHAR ComputerKey[32];
|
|
|
|
|
|
|
|
/* Get the computer identification */
|
|
|
|
if (!GetComputerIdentifier(ComputerIdentifier, 128))
|
|
|
|
{
|
|
|
|
ComputerIdentifier[0] = 0;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2011-08-15 07:36:58 +00:00
|
|
|
DPRINT("Computer identifier: '%S'\n", ComputerIdentifier);
|
2005-09-19 08:11:43 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Search for matching device identifier */
|
|
|
|
if (!SetupFindFirstLineW(InfFile, L"Map.Computer", NULL, &Context))
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
/* FIXME: error message */
|
|
|
|
return NULL;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
do
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2017-08-28 13:51:25 +00:00
|
|
|
BOOLEAN FoundId;
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!INF_GetDataField(&Context, 1, &KeyValue))
|
2005-09-19 08:11:43 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
/* FIXME: Handle error! */
|
|
|
|
DPRINT("INF_GetDataField() failed\n");
|
|
|
|
return NULL;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
|
|
|
|
2011-08-15 07:36:58 +00:00
|
|
|
DPRINT("KeyValue: %S\n", KeyValue);
|
2017-08-28 13:51:25 +00:00
|
|
|
FoundId = !!wcsstr(ComputerIdentifier, KeyValue);
|
|
|
|
INF_FreeData(KeyValue);
|
|
|
|
|
|
|
|
if (!FoundId)
|
|
|
|
continue;
|
2005-09-19 08:11:43 +00:00
|
|
|
|
2017-08-28 13:51:25 +00:00
|
|
|
if (!INF_GetDataField(&Context, 0, &KeyName))
|
|
|
|
{
|
|
|
|
/* FIXME: Handle error! */
|
|
|
|
DPRINT("INF_GetDataField() failed\n");
|
|
|
|
return NULL;
|
2005-09-19 08:11:43 +00:00
|
|
|
}
|
2017-08-28 13:51:25 +00:00
|
|
|
|
|
|
|
DPRINT("Computer key: %S\n", KeyName);
|
|
|
|
wcscpy(ComputerKey, KeyName);
|
|
|
|
INF_FreeData(KeyName);
|
2008-01-07 17:22:05 +00:00
|
|
|
} while (SetupFindNextLine(&Context, &Context));
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
List = CreateGenericList();
|
|
|
|
if (List == NULL)
|
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
if (AddEntriesFromInfSection(List,
|
|
|
|
InfFile,
|
|
|
|
L"Computer",
|
|
|
|
&Context,
|
|
|
|
DefaultProcessEntry,
|
|
|
|
ComputerKey) == -1)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2017-08-28 14:01:30 +00:00
|
|
|
DestroyGenericList(List, TRUE);
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return List;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2014-05-12 16:14:19 +00:00
|
|
|
static
|
|
|
|
BOOLEAN
|
|
|
|
GetDisplayIdentifier(
|
|
|
|
PWSTR Identifier,
|
2008-01-07 17:22:05 +00:00
|
|
|
ULONG IdentifierLength)
|
2004-06-20 12:18:08 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
UNICODE_STRING KeyName;
|
|
|
|
WCHAR Buffer[32];
|
|
|
|
HANDLE BusKey;
|
|
|
|
HANDLE BusInstanceKey;
|
|
|
|
HANDLE ControllerKey;
|
|
|
|
HANDLE ControllerInstanceKey;
|
|
|
|
ULONG BusInstance;
|
|
|
|
ULONG ControllerInstance;
|
|
|
|
ULONG BufferLength;
|
|
|
|
ULONG ReturnedLength;
|
|
|
|
PKEY_VALUE_PARTIAL_INFORMATION ValueInfo;
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
|
|
|
DPRINT("GetDisplayIdentifier() called\n");
|
|
|
|
|
|
|
|
/* Open the bus key */
|
|
|
|
RtlInitUnicodeString(&KeyName,
|
|
|
|
L"\\Registry\\Machine\\HARDWARE\\Description\\System\\MultifunctionAdapter");
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenKey(&BusKey,
|
2009-08-23 08:29:23 +00:00
|
|
|
KEY_ENUMERATE_SUB_KEYS,
|
2008-01-07 17:22:05 +00:00
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
BusInstance = 0;
|
|
|
|
while (TRUE)
|
|
|
|
{
|
|
|
|
swprintf(Buffer, L"%lu", BusInstance);
|
2017-08-28 13:50:40 +00:00
|
|
|
RtlInitUnicodeString(&KeyName, Buffer);
|
2008-01-07 17:22:05 +00:00
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
BusKey,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenKey(&BusInstanceKey,
|
2009-08-23 08:29:23 +00:00
|
|
|
KEY_ENUMERATE_SUB_KEYS,
|
2008-01-07 17:22:05 +00:00
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
NtClose(BusKey);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Open the controller type key */
|
2017-08-28 13:50:40 +00:00
|
|
|
RtlInitUnicodeString(&KeyName, L"DisplayController");
|
2008-01-07 17:22:05 +00:00
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
BusInstanceKey,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenKey(&ControllerKey,
|
2009-08-23 08:29:23 +00:00
|
|
|
KEY_ENUMERATE_SUB_KEYS,
|
2008-01-07 17:22:05 +00:00
|
|
|
&ObjectAttributes);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
ControllerInstance = 0;
|
2004-06-20 12:18:08 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
while (TRUE)
|
|
|
|
{
|
|
|
|
/* Open the pointer controller instance key */
|
|
|
|
swprintf(Buffer, L"%lu", ControllerInstance);
|
2017-08-28 13:50:40 +00:00
|
|
|
RtlInitUnicodeString(&KeyName, Buffer);
|
2008-01-07 17:22:05 +00:00
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
ControllerKey,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenKey(&ControllerInstanceKey,
|
2009-08-23 08:29:23 +00:00
|
|
|
KEY_QUERY_VALUE,
|
2008-01-07 17:22:05 +00:00
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
NtClose(ControllerKey);
|
|
|
|
NtClose(BusInstanceKey);
|
|
|
|
NtClose(BusKey);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get controller identifier */
|
2017-08-28 13:50:40 +00:00
|
|
|
RtlInitUnicodeString(&KeyName, L"Identifier");
|
2008-01-07 17:22:05 +00:00
|
|
|
|
|
|
|
BufferLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION) +
|
|
|
|
256 * sizeof(WCHAR);
|
|
|
|
ValueInfo = (KEY_VALUE_PARTIAL_INFORMATION*) RtlAllocateHeap(RtlGetProcessHeap(),
|
|
|
|
0,
|
|
|
|
BufferLength);
|
|
|
|
if (ValueInfo == NULL)
|
|
|
|
{
|
|
|
|
DPRINT("RtlAllocateHeap() failed\n");
|
|
|
|
NtClose(ControllerInstanceKey);
|
|
|
|
NtClose(ControllerKey);
|
|
|
|
NtClose(BusInstanceKey);
|
|
|
|
NtClose(BusKey);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status = NtQueryValueKey(ControllerInstanceKey,
|
|
|
|
&KeyName,
|
|
|
|
KeyValuePartialInformation,
|
|
|
|
ValueInfo,
|
|
|
|
BufferLength,
|
|
|
|
&ReturnedLength);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT("Identifier: %S\n", (PWSTR)ValueInfo->Data);
|
|
|
|
|
|
|
|
BufferLength = min(ValueInfo->DataLength / sizeof(WCHAR), IdentifierLength);
|
2017-08-28 14:01:30 +00:00
|
|
|
RtlCopyMemory(Identifier,
|
|
|
|
ValueInfo->Data,
|
|
|
|
BufferLength * sizeof(WCHAR));
|
2008-01-07 17:22:05 +00:00
|
|
|
Identifier[BufferLength] = 0;
|
|
|
|
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(),
|
|
|
|
0,
|
|
|
|
ValueInfo);
|
|
|
|
|
|
|
|
NtClose(ControllerInstanceKey);
|
|
|
|
NtClose(ControllerKey);
|
|
|
|
NtClose(BusInstanceKey);
|
|
|
|
NtClose(BusKey);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
NtClose(ControllerInstanceKey);
|
|
|
|
|
|
|
|
ControllerInstance++;
|
|
|
|
}
|
|
|
|
|
|
|
|
NtClose(ControllerKey);
|
|
|
|
}
|
|
|
|
|
|
|
|
NtClose(BusInstanceKey);
|
|
|
|
|
|
|
|
BusInstance++;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
NtClose(BusKey);
|
2004-06-20 12:18:08 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2004-05-30 14:54:02 +00:00
|
|
|
PGENERIC_LIST
|
2014-05-12 16:14:19 +00:00
|
|
|
CreateDisplayDriverList(
|
|
|
|
HINF InfFile)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
PGENERIC_LIST List;
|
|
|
|
INFCONTEXT Context;
|
|
|
|
PWCHAR KeyName;
|
|
|
|
PWCHAR KeyValue;
|
|
|
|
WCHAR DisplayIdentifier[128];
|
|
|
|
WCHAR DisplayKey[32];
|
|
|
|
|
|
|
|
/* Get the display identification */
|
|
|
|
if (!GetDisplayIdentifier(DisplayIdentifier, 128))
|
|
|
|
{
|
|
|
|
DisplayIdentifier[0] = 0;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
DPRINT("Display identifier: '%S'\n", DisplayIdentifier);
|
2004-06-20 12:18:08 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Search for matching device identifier */
|
|
|
|
if (!SetupFindFirstLineW(InfFile, L"Map.Display", NULL, &Context))
|
2004-06-20 12:18:08 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
/* FIXME: error message */
|
|
|
|
return NULL;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
do
|
|
|
|
{
|
2017-08-28 13:51:25 +00:00
|
|
|
BOOLEAN FoundId;
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!INF_GetDataField(&Context, 1, &KeyValue))
|
|
|
|
{
|
|
|
|
/* FIXME: Handle error! */
|
|
|
|
DPRINT("INF_GetDataField() failed\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
2004-06-20 12:18:08 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
DPRINT("KeyValue: %S\n", KeyValue);
|
2017-08-28 13:51:25 +00:00
|
|
|
FoundId = !!wcsstr(DisplayIdentifier, KeyValue);
|
|
|
|
INF_FreeData(KeyValue);
|
|
|
|
|
|
|
|
if (!FoundId)
|
|
|
|
continue;
|
2008-01-07 17:22:05 +00:00
|
|
|
|
2017-08-28 13:51:25 +00:00
|
|
|
if (!INF_GetDataField(&Context, 0, &KeyName))
|
|
|
|
{
|
|
|
|
/* FIXME: Handle error! */
|
|
|
|
DPRINT("INF_GetDataField() failed\n");
|
|
|
|
return NULL;
|
2008-01-07 17:22:05 +00:00
|
|
|
}
|
2017-08-28 13:51:25 +00:00
|
|
|
|
|
|
|
DPRINT("Display key: %S\n", KeyName);
|
|
|
|
wcscpy(DisplayKey, KeyName);
|
|
|
|
INF_FreeData(KeyName);
|
2008-01-07 17:22:05 +00:00
|
|
|
} while (SetupFindNextLine(&Context, &Context));
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
List = CreateGenericList();
|
|
|
|
if (List == NULL)
|
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
if (AddEntriesFromInfSection(List,
|
|
|
|
InfFile,
|
|
|
|
L"Display",
|
|
|
|
&Context,
|
|
|
|
DefaultProcessEntry,
|
|
|
|
DisplayKey) == -1)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2017-08-28 14:01:30 +00:00
|
|
|
DestroyGenericList(List, TRUE);
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2004-06-20 12:18:08 +00:00
|
|
|
#if 0
|
2008-01-07 17:22:05 +00:00
|
|
|
AppendGenericListEntry(List, "Other display driver", NULL, TRUE);
|
2004-06-20 12:18:08 +00:00
|
|
|
#endif
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return List;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2014-05-12 16:14:19 +00:00
|
|
|
|
2005-02-20 22:40:30 +00:00
|
|
|
BOOLEAN
|
2014-05-12 16:14:19 +00:00
|
|
|
ProcessComputerFiles(
|
|
|
|
HINF InfFile,
|
|
|
|
PGENERIC_LIST List,
|
|
|
|
PWCHAR *AdditionalSectionName)
|
2005-02-20 22:40:30 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
PGENERIC_LIST_ENTRY Entry;
|
|
|
|
static WCHAR SectionName[128];
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
DPRINT("ProcessComputerFiles() called\n");
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2008-05-11 21:17:57 +00:00
|
|
|
Entry = GetCurrentListEntry(List);
|
2008-01-07 17:22:05 +00:00
|
|
|
if (Entry == NULL)
|
|
|
|
{
|
2008-05-11 21:17:57 +00:00
|
|
|
DPRINT("GetCurrentListEntry() failed\n");
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
wcscpy(SectionName, L"Files.");
|
2008-05-11 21:17:57 +00:00
|
|
|
wcscat(SectionName, (const wchar_t*)GetListEntryUserData(Entry));
|
2008-01-07 17:22:05 +00:00
|
|
|
*AdditionalSectionName = SectionName;
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return TRUE;
|
2005-02-20 22:40:30 +00:00
|
|
|
}
|
|
|
|
|
2004-06-20 12:18:08 +00:00
|
|
|
BOOLEAN
|
2014-05-12 16:14:19 +00:00
|
|
|
ProcessDisplayRegistry(
|
|
|
|
HINF InfFile,
|
|
|
|
PGENERIC_LIST List)
|
2004-06-20 12:18:08 +00:00
|
|
|
{
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NTSTATUS Status;
|
2008-01-07 17:22:05 +00:00
|
|
|
PGENERIC_LIST_ENTRY Entry;
|
|
|
|
INFCONTEXT Context;
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
PWCHAR Buffer;
|
2008-01-07 17:22:05 +00:00
|
|
|
PWCHAR ServiceName;
|
|
|
|
ULONG StartValue;
|
|
|
|
ULONG Width, Height, Bpp;
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
UNICODE_STRING KeyName;
|
|
|
|
HANDLE KeyHandle;
|
|
|
|
WCHAR RegPath[255];
|
2008-01-07 17:22:05 +00:00
|
|
|
|
|
|
|
DPRINT("ProcessDisplayRegistry() called\n");
|
|
|
|
|
2008-05-11 21:17:57 +00:00
|
|
|
Entry = GetCurrentListEntry(List);
|
2008-01-07 17:22:05 +00:00
|
|
|
if (Entry == NULL)
|
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("GetCurrentListEntry() failed\n");
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-05-11 21:17:57 +00:00
|
|
|
if (!SetupFindFirstLineW(InfFile, L"Display", (WCHAR*)GetListEntryUserData(Entry), &Context))
|
2004-06-20 12:18:08 +00:00
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("SetupFindFirstLineW() failed\n");
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
/* Enable the correct driver */
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!INF_GetDataField(&Context, 3, &ServiceName))
|
2004-06-20 12:18:08 +00:00
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("INF_GetDataField() failed\n");
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
ASSERT(wcslen(ServiceName) < 10);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
DPRINT1("Service name: '%S'\n", ServiceName);
|
|
|
|
|
|
|
|
swprintf(RegPath, L"System\\CurrentControlSet\\Services\\%s", ServiceName);
|
|
|
|
RtlInitUnicodeString(&KeyName, RegPath);
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
GetRootKeyByPredefKey(HKEY_LOCAL_MACHINE, NULL),
|
|
|
|
NULL);
|
|
|
|
Status = NtOpenKey(&KeyHandle,
|
|
|
|
KEY_SET_VALUE,
|
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
2004-06-20 12:18:08 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
StartValue = 1;
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
Status = RtlWriteRegistryValue(RTL_REGISTRY_HANDLE, KeyHandle,
|
2014-05-12 16:14:19 +00:00
|
|
|
L"Start",
|
|
|
|
REG_DWORD,
|
|
|
|
&StartValue,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
sizeof(StartValue));
|
|
|
|
NtClose(KeyHandle);
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2004-06-20 12:18:08 +00:00
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("RtlWriteRegistryValue() failed (Status %lx)\n", Status);
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Set the resolution */
|
2005-12-23 18:03:12 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!INF_GetDataField(&Context, 4, &Buffer))
|
2005-12-23 18:03:12 +00:00
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("INF_GetDataField() failed\n");
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2005-12-23 18:03:12 +00:00
|
|
|
}
|
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
swprintf(RegPath,
|
|
|
|
L"System\\CurrentControlSet\\Hardware Profiles\\Current\\System\\CurrentControlSet\\Services\\%s\\Device0",
|
|
|
|
ServiceName);
|
|
|
|
DPRINT1("RegPath: '%S'\n", RegPath);
|
|
|
|
RtlInitUnicodeString(&KeyName, RegPath);
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
GetRootKeyByPredefKey(HKEY_LOCAL_MACHINE, NULL),
|
|
|
|
NULL);
|
|
|
|
Status = NtOpenKey(&KeyHandle,
|
|
|
|
KEY_SET_VALUE,
|
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
Width = wcstoul(Buffer, NULL, 10);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
Status = RtlWriteRegistryValue(RTL_REGISTRY_HANDLE, KeyHandle,
|
2014-05-12 16:14:19 +00:00
|
|
|
L"DefaultSettings.XResolution",
|
|
|
|
REG_DWORD,
|
|
|
|
&Width,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
sizeof(Width));
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("RtlWriteRegistryValue() failed (Status %lx)\n", Status);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NtClose(KeyHandle);
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
2007-01-05 20:19:21 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!INF_GetDataField(&Context, 5, &Buffer))
|
2005-12-23 18:03:12 +00:00
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("INF_GetDataField() failed\n");
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NtClose(KeyHandle);
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2005-12-23 18:03:12 +00:00
|
|
|
}
|
2008-01-07 17:22:05 +00:00
|
|
|
|
|
|
|
Height = wcstoul(Buffer, 0, 0);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
Status = RtlWriteRegistryValue(RTL_REGISTRY_HANDLE, KeyHandle,
|
2014-05-12 16:14:19 +00:00
|
|
|
L"DefaultSettings.YResolution",
|
|
|
|
REG_DWORD,
|
|
|
|
&Height,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
sizeof(Height));
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("RtlWriteRegistryValue() failed (Status %lx)\n", Status);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NtClose(KeyHandle);
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2005-12-23 18:03:12 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!INF_GetDataField(&Context, 6, &Buffer))
|
2005-12-23 18:03:12 +00:00
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("INF_GetDataField() failed\n");
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NtClose(KeyHandle);
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2005-12-23 18:03:12 +00:00
|
|
|
}
|
2008-01-07 17:22:05 +00:00
|
|
|
|
|
|
|
Bpp = wcstoul(Buffer, 0, 0);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
Status = RtlWriteRegistryValue(RTL_REGISTRY_HANDLE, KeyHandle,
|
2014-05-12 16:14:19 +00:00
|
|
|
L"DefaultSettings.BitsPerPel",
|
|
|
|
REG_DWORD,
|
|
|
|
&Bpp,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
sizeof(Bpp));
|
2008-01-07 17:22:05 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
2015-03-29 11:29:02 +00:00
|
|
|
DPRINT1("RtlWriteRegistryValue() failed (Status %lx)\n", Status);
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NtClose(KeyHandle);
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2005-12-23 18:03:12 +00:00
|
|
|
}
|
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NtClose(KeyHandle);
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
DPRINT("ProcessDisplayRegistry() done\n");
|
2004-06-20 12:18:08 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return TRUE;
|
2004-06-20 12:18:08 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 21:34:56 +00:00
|
|
|
BOOLEAN
|
2014-05-12 16:14:19 +00:00
|
|
|
ProcessLocaleRegistry(
|
|
|
|
PGENERIC_LIST List)
|
2008-01-07 21:34:56 +00:00
|
|
|
{
|
|
|
|
PGENERIC_LIST_ENTRY Entry;
|
|
|
|
PWCHAR LanguageId;
|
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
UNICODE_STRING KeyName;
|
|
|
|
UNICODE_STRING ValueName;
|
|
|
|
|
|
|
|
HANDLE KeyHandle;
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
2008-05-11 21:17:57 +00:00
|
|
|
Entry = GetCurrentListEntry(List);
|
2008-01-07 21:34:56 +00:00
|
|
|
if (Entry == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
2008-05-11 21:17:57 +00:00
|
|
|
LanguageId = (PWCHAR)GetListEntryUserData(Entry);
|
2008-01-07 21:34:56 +00:00
|
|
|
if (LanguageId == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
2015-12-18 21:36:16 +00:00
|
|
|
DPRINT("LanguageId: %S\n", LanguageId);
|
|
|
|
|
|
|
|
/* Open the default users locale key */
|
|
|
|
RtlInitUnicodeString(&KeyName,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
L".DEFAULT\\Control Panel\\International");
|
2015-12-18 21:36:16 +00:00
|
|
|
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
GetRootKeyByPredefKey(HKEY_USERS, NULL),
|
2015-12-18 21:36:16 +00:00
|
|
|
NULL);
|
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
Status = NtOpenKey(&KeyHandle,
|
|
|
|
KEY_SET_VALUE,
|
|
|
|
&ObjectAttributes);
|
2015-12-18 21:36:16 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set default user locale */
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
RtlInitUnicodeString(&ValueName, L"Locale");
|
2015-12-18 21:36:16 +00:00
|
|
|
Status = NtSetValueKey(KeyHandle,
|
|
|
|
&ValueName,
|
|
|
|
0,
|
|
|
|
REG_SZ,
|
|
|
|
(PVOID)LanguageId,
|
|
|
|
(wcslen(LanguageId) + 1) * sizeof(WCHAR));
|
|
|
|
NtClose(KeyHandle);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtSetValueKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
[USETUP]
- Fix a buffer overflow (overread) when adding a locale key to the registry. The history of this bug is funny:
1. Eric wrote the code, which sets a key of REG_SZ type, as 4 widechars plus terminating zero, but passes 8 as the bytesize of the buffer. It's not fully correct (a terminating zero is absent from the bytesize of the buffer, but MSDN doesn't specify if it should be added or not, and hardcoding "8" is not the best idea too) but not dramatic. That was revision 9596, 7 years ago.
2. Lentin notices something is not right in this code, and decides to "fix" it by multiplying that same hardcoded value by.... guess what? sizeof(PWCHAR)! That is, size of a pointer, which on an x86 would be 4 bytes. Massive out of bounds access obviously happens. That was revision 31642, 3 years ago.
3. Very soon Colin reshuffles and improves the code based on patch #2635, however the problem still goes unnoticed (r31655+).
See issue #5810 for more details.
svn path=/trunk/; revision=50968
2011-03-04 18:18:05 +00:00
|
|
|
/* Skip first 4 zeroes */
|
|
|
|
if (wcslen(LanguageId) >= 4)
|
|
|
|
LanguageId += 4;
|
|
|
|
|
2008-01-07 21:34:56 +00:00
|
|
|
/* Open the NLS language key */
|
|
|
|
RtlInitUnicodeString(&KeyName,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
L"SYSTEM\\CurrentControlSet\\Control\\NLS\\Language");
|
2008-01-07 21:34:56 +00:00
|
|
|
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
GetRootKeyByPredefKey(HKEY_LOCAL_MACHINE, NULL),
|
2008-01-07 21:34:56 +00:00
|
|
|
NULL);
|
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
Status = NtOpenKey(&KeyHandle,
|
|
|
|
KEY_SET_VALUE,
|
|
|
|
&ObjectAttributes);
|
2008-01-07 21:34:56 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set default language */
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
RtlInitUnicodeString(&ValueName, L"Default");
|
2008-01-07 21:34:56 +00:00
|
|
|
Status = NtSetValueKey(KeyHandle,
|
|
|
|
&ValueName,
|
|
|
|
0,
|
|
|
|
REG_SZ,
|
[USETUP]
- Fix a buffer overflow (overread) when adding a locale key to the registry. The history of this bug is funny:
1. Eric wrote the code, which sets a key of REG_SZ type, as 4 widechars plus terminating zero, but passes 8 as the bytesize of the buffer. It's not fully correct (a terminating zero is absent from the bytesize of the buffer, but MSDN doesn't specify if it should be added or not, and hardcoding "8" is not the best idea too) but not dramatic. That was revision 9596, 7 years ago.
2. Lentin notices something is not right in this code, and decides to "fix" it by multiplying that same hardcoded value by.... guess what? sizeof(PWCHAR)! That is, size of a pointer, which on an x86 would be 4 bytes. Massive out of bounds access obviously happens. That was revision 31642, 3 years ago.
3. Very soon Colin reshuffles and improves the code based on patch #2635, however the problem still goes unnoticed (r31655+).
See issue #5810 for more details.
svn path=/trunk/; revision=50968
2011-03-04 18:18:05 +00:00
|
|
|
(PVOID)LanguageId,
|
|
|
|
(wcslen(LanguageId) + 1) * sizeof(WCHAR));
|
2008-01-07 21:34:56 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtSetValueKey() failed (Status %lx)\n", Status);
|
|
|
|
NtClose(KeyHandle);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set install language */
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
RtlInitUnicodeString(&ValueName, L"InstallLanguage");
|
|
|
|
Status = NtSetValueKey(KeyHandle,
|
|
|
|
&ValueName,
|
|
|
|
0,
|
|
|
|
REG_SZ,
|
|
|
|
(PVOID)LanguageId,
|
|
|
|
(wcslen(LanguageId) + 1) * sizeof(WCHAR));
|
2010-09-25 19:24:03 +00:00
|
|
|
NtClose(KeyHandle);
|
2008-01-07 21:34:56 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtSetValueKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2004-05-30 14:54:02 +00:00
|
|
|
PGENERIC_LIST
|
2014-05-12 16:14:19 +00:00
|
|
|
CreateKeyboardDriverList(
|
|
|
|
HINF InfFile)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
PGENERIC_LIST List;
|
|
|
|
INFCONTEXT Context;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
List = CreateGenericList();
|
|
|
|
if (List == NULL)
|
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
if (AddEntriesFromInfSection(List,
|
|
|
|
InfFile,
|
|
|
|
L"Keyboard",
|
|
|
|
&Context,
|
|
|
|
DefaultProcessEntry,
|
|
|
|
NULL) == -1)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2017-08-28 14:01:30 +00:00
|
|
|
DestroyGenericList(List, TRUE);
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return List;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2008-06-02 15:34:57 +00:00
|
|
|
ULONG
|
|
|
|
GetDefaultLanguageIndex(VOID)
|
|
|
|
{
|
|
|
|
return DefaultLanguageIndex;
|
|
|
|
}
|
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
typedef struct _LANG_ENTRY_PARAM
|
|
|
|
{
|
|
|
|
ULONG uIndex;
|
|
|
|
PWCHAR DefaultLanguage;
|
|
|
|
} LANG_ENTRY_PARAM, *PLANG_ENTRY_PARAM;
|
|
|
|
|
|
|
|
static UCHAR
|
|
|
|
NTAPI
|
|
|
|
ProcessLangEntry(
|
|
|
|
IN PWCHAR KeyName,
|
|
|
|
IN PWCHAR KeyValue,
|
|
|
|
IN PCHAR DisplayText,
|
|
|
|
IN SIZE_T DisplayTextSize,
|
|
|
|
OUT PVOID* UserData,
|
|
|
|
OUT PBOOLEAN Current,
|
|
|
|
IN PVOID Parameter OPTIONAL)
|
|
|
|
{
|
|
|
|
PLANG_ENTRY_PARAM LangEntryParam = (PLANG_ENTRY_PARAM)Parameter;
|
|
|
|
|
|
|
|
if (!IsLanguageAvailable(KeyName))
|
|
|
|
{
|
|
|
|
/* The specified language is unavailable, skip the entry */
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
*UserData = RtlAllocateHeap(ProcessHeap, 0,
|
|
|
|
(wcslen(KeyName) + 1) * sizeof(WCHAR));
|
|
|
|
if (*UserData == NULL)
|
|
|
|
{
|
|
|
|
/* Failure, stop enumeration */
|
|
|
|
DPRINT1("RtlAllocateHeap() failed\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
wcscpy((PWCHAR)*UserData, KeyName);
|
|
|
|
sprintf(DisplayText, "%S", KeyValue);
|
|
|
|
|
|
|
|
*Current = FALSE;
|
|
|
|
|
|
|
|
if (!_wcsicmp(KeyName, LangEntryParam->DefaultLanguage))
|
|
|
|
DefaultLanguageIndex = LangEntryParam->uIndex;
|
|
|
|
|
|
|
|
LangEntryParam->uIndex++;
|
|
|
|
|
|
|
|
/* Add the entry */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2008-06-02 15:34:57 +00:00
|
|
|
PGENERIC_LIST
|
2014-05-12 16:14:19 +00:00
|
|
|
CreateLanguageList(
|
|
|
|
HINF InfFile,
|
2015-03-29 11:29:02 +00:00
|
|
|
WCHAR *DefaultLanguage)
|
2008-01-07 17:22:05 +00:00
|
|
|
{
|
|
|
|
PGENERIC_LIST List;
|
|
|
|
INFCONTEXT Context;
|
|
|
|
PWCHAR KeyValue;
|
2017-08-28 14:01:30 +00:00
|
|
|
|
|
|
|
LANG_ENTRY_PARAM LangEntryParam;
|
|
|
|
|
|
|
|
LangEntryParam.uIndex = 0;
|
|
|
|
LangEntryParam.DefaultLanguage = DefaultLanguage;
|
2008-01-07 17:22:05 +00:00
|
|
|
|
|
|
|
/* Get default language id */
|
2017-08-28 13:50:40 +00:00
|
|
|
if (!SetupFindFirstLineW(InfFile, L"NLS", L"DefaultLanguage", &Context))
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
|
|
|
|
2017-08-28 13:50:40 +00:00
|
|
|
if (!INF_GetData(&Context, NULL, &KeyValue))
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
wcscpy(DefaultLanguage, KeyValue);
|
2007-12-25 20:24:19 +00:00
|
|
|
SelectedLanguageId = KeyValue;
|
2007-12-23 20:29:52 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
List = CreateGenericList();
|
|
|
|
if (List == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
if (AddEntriesFromInfSection(List,
|
|
|
|
InfFile,
|
|
|
|
L"Language",
|
|
|
|
&Context,
|
|
|
|
ProcessLangEntry,
|
|
|
|
&LangEntryParam) == -1)
|
2008-01-07 17:22:05 +00:00
|
|
|
{
|
2017-08-28 14:01:30 +00:00
|
|
|
DestroyGenericList(List, TRUE);
|
2015-03-29 11:29:02 +00:00
|
|
|
return NULL;
|
2008-01-07 17:22:05 +00:00
|
|
|
}
|
|
|
|
|
2012-02-27 22:46:20 +00:00
|
|
|
/* Only one language available, make it the default one */
|
2017-08-28 14:01:30 +00:00
|
|
|
if (LangEntryParam.uIndex == 1)
|
2012-02-27 22:46:20 +00:00
|
|
|
{
|
|
|
|
DefaultLanguageIndex = 0;
|
2017-08-28 14:01:30 +00:00
|
|
|
wcscpy(DefaultLanguage,
|
|
|
|
(PWSTR)GetListEntryUserData(GetFirstListEntry(List)));
|
2012-02-27 22:46:20 +00:00
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return List;
|
2007-12-23 20:29:52 +00:00
|
|
|
}
|
2004-05-30 14:54:02 +00:00
|
|
|
|
|
|
|
PGENERIC_LIST
|
2014-05-12 16:14:19 +00:00
|
|
|
CreateKeyboardLayoutList(
|
|
|
|
HINF InfFile,
|
|
|
|
WCHAR *DefaultKBLayout)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
PGENERIC_LIST List;
|
|
|
|
INFCONTEXT Context;
|
|
|
|
PWCHAR KeyValue;
|
2008-06-01 12:52:18 +00:00
|
|
|
const MUI_LAYOUTS * LayoutsList;
|
|
|
|
ULONG uIndex = 0;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
/* Get default layout id */
|
2017-08-28 13:50:40 +00:00
|
|
|
if (!SetupFindFirstLineW(InfFile, L"NLS", L"DefaultLayout", &Context))
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2017-08-28 13:50:40 +00:00
|
|
|
if (!INF_GetData(&Context, NULL, &KeyValue))
|
2008-01-07 17:22:05 +00:00
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
wcscpy(DefaultKBLayout, KeyValue);
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
List = CreateGenericList();
|
|
|
|
if (List == NULL)
|
|
|
|
return NULL;
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
LayoutsList = MUIGetLayoutsList();
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
do
|
|
|
|
{
|
2017-08-28 14:01:30 +00:00
|
|
|
// NOTE: See https://svn.reactos.org/svn/reactos?view=revision&revision=68354
|
|
|
|
if (AddEntriesFromInfSection(List,
|
|
|
|
InfFile,
|
|
|
|
L"KeyboardLayout",
|
|
|
|
&Context,
|
|
|
|
DefaultProcessEntry,
|
|
|
|
DefaultKBLayout) == -1)
|
2008-01-07 17:22:05 +00:00
|
|
|
{
|
2017-08-28 14:01:30 +00:00
|
|
|
DestroyGenericList(List, TRUE);
|
2008-06-01 12:52:18 +00:00
|
|
|
return NULL;
|
2008-01-07 17:22:05 +00:00
|
|
|
}
|
2004-05-30 14:54:02 +00:00
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
uIndex++;
|
|
|
|
|
|
|
|
} while (LayoutsList[uIndex].LangID != NULL);
|
2004-06-02 22:18:06 +00:00
|
|
|
|
2017-08-28 14:01:30 +00:00
|
|
|
/* Check whether some keyboard layouts have been found */
|
2009-04-20 03:16:12 +00:00
|
|
|
/* FIXME: Handle this case */
|
2017-08-28 14:01:30 +00:00
|
|
|
if (GetNumberOfListEntries(List) == 0)
|
2009-04-20 03:16:12 +00:00
|
|
|
{
|
|
|
|
DPRINT1("No keyboard layouts have been found\n");
|
2017-08-28 14:01:30 +00:00
|
|
|
DestroyGenericList(List, TRUE);
|
2009-04-20 03:16:12 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
return List;
|
|
|
|
}
|
2004-06-02 22:18:06 +00:00
|
|
|
|
2014-05-12 16:14:19 +00:00
|
|
|
|
2008-01-07 17:22:05 +00:00
|
|
|
BOOLEAN
|
2014-05-12 16:14:19 +00:00
|
|
|
ProcessKeyboardLayoutRegistry(
|
|
|
|
PGENERIC_LIST List)
|
2008-01-07 17:22:05 +00:00
|
|
|
{
|
|
|
|
PGENERIC_LIST_ENTRY Entry;
|
2008-06-01 12:52:18 +00:00
|
|
|
PWCHAR LayoutId;
|
|
|
|
const MUI_LAYOUTS * LayoutsList;
|
|
|
|
MUI_LAYOUTS NewLayoutsList[20];
|
2008-12-18 12:26:47 +00:00
|
|
|
ULONG uIndex;
|
2008-06-01 12:52:18 +00:00
|
|
|
ULONG uOldPos = 0;
|
2008-01-07 17:22:05 +00:00
|
|
|
|
2008-05-11 21:17:57 +00:00
|
|
|
Entry = GetCurrentListEntry(List);
|
2008-01-07 17:22:05 +00:00
|
|
|
if (Entry == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
LayoutId = (PWCHAR)GetListEntryUserData(Entry);
|
|
|
|
if (LayoutId == NULL)
|
2008-01-07 17:22:05 +00:00
|
|
|
return FALSE;
|
2008-04-28 14:04:22 +00:00
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
LayoutsList = MUIGetLayoutsList();
|
2008-04-28 14:04:22 +00:00
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
if (_wcsicmp(LayoutsList[0].LayoutID, LayoutId) != 0)
|
2008-01-07 17:22:05 +00:00
|
|
|
{
|
2008-12-18 12:26:47 +00:00
|
|
|
for (uIndex = 1; LayoutsList[uIndex].LangID != NULL; uIndex++)
|
2008-04-28 14:04:22 +00:00
|
|
|
{
|
2008-06-01 12:52:18 +00:00
|
|
|
if (_wcsicmp(LayoutsList[uIndex].LayoutID, LayoutId) == 0)
|
|
|
|
{
|
|
|
|
uOldPos = uIndex;
|
2008-12-18 12:26:47 +00:00
|
|
|
continue;
|
2008-06-01 12:52:18 +00:00
|
|
|
}
|
2008-04-28 14:04:22 +00:00
|
|
|
|
2008-12-18 12:26:47 +00:00
|
|
|
NewLayoutsList[uIndex].LangID = LayoutsList[uIndex].LangID;
|
|
|
|
NewLayoutsList[uIndex].LayoutID = LayoutsList[uIndex].LayoutID;
|
|
|
|
}
|
2008-04-28 14:04:22 +00:00
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
NewLayoutsList[uIndex].LangID = NULL;
|
|
|
|
NewLayoutsList[uIndex].LayoutID = NULL;
|
|
|
|
NewLayoutsList[uOldPos].LangID = LayoutsList[0].LangID;
|
|
|
|
NewLayoutsList[uOldPos].LayoutID = LayoutsList[0].LayoutID;
|
|
|
|
NewLayoutsList[0].LangID = LayoutsList[uOldPos].LangID;
|
|
|
|
NewLayoutsList[0].LayoutID = LayoutsList[uOldPos].LayoutID;
|
2008-01-07 17:22:05 +00:00
|
|
|
|
2008-06-01 12:52:18 +00:00
|
|
|
return AddKbLayoutsToRegistry(NewLayoutsList);
|
|
|
|
}
|
2008-01-07 17:22:05 +00:00
|
|
|
|
|
|
|
return TRUE;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
|
|
|
|
2004-06-07 12:24:00 +00:00
|
|
|
#if 0
|
2004-05-30 14:54:02 +00:00
|
|
|
BOOLEAN
|
2014-05-12 16:14:19 +00:00
|
|
|
ProcessKeyboardLayoutFiles(
|
|
|
|
PGENERIC_LIST List)
|
2004-05-30 14:54:02 +00:00
|
|
|
{
|
2008-01-07 17:22:05 +00:00
|
|
|
return TRUE;
|
2004-05-30 14:54:02 +00:00
|
|
|
}
|
2004-06-07 12:24:00 +00:00
|
|
|
#endif
|
|
|
|
|
2009-02-05 13:50:49 +00:00
|
|
|
BOOLEAN
|
2014-05-12 16:14:19 +00:00
|
|
|
SetGeoID(
|
|
|
|
PWCHAR Id)
|
2009-02-05 13:50:49 +00:00
|
|
|
{
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
NTSTATUS Status;
|
2009-02-05 13:50:49 +00:00
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
UNICODE_STRING Name;
|
2009-02-05 13:50:49 +00:00
|
|
|
HANDLE KeyHandle;
|
2014-05-12 16:14:19 +00:00
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
RtlInitUnicodeString(&Name,
|
|
|
|
L".DEFAULT\\Control Panel\\International\\Geo");
|
2009-02-05 13:50:49 +00:00
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
&Name,
|
2009-02-05 13:50:49 +00:00
|
|
|
OBJ_CASE_INSENSITIVE,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
GetRootKeyByPredefKey(HKEY_USERS, NULL),
|
2009-02-05 13:50:49 +00:00
|
|
|
NULL);
|
|
|
|
Status = NtOpenKey(&KeyHandle,
|
2009-08-23 08:29:23 +00:00
|
|
|
KEY_SET_VALUE,
|
2014-05-12 16:14:19 +00:00
|
|
|
&ObjectAttributes);
|
2017-08-09 20:24:24 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2009-02-05 13:50:49 +00:00
|
|
|
{
|
|
|
|
DPRINT1("NtOpenKey() failed (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
2014-05-12 16:14:19 +00:00
|
|
|
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
RtlInitUnicodeString(&Name, L"Nation");
|
2009-02-05 13:50:49 +00:00
|
|
|
Status = NtSetValueKey(KeyHandle,
|
[USETUP] Implement offline ReactOS registry initialization in USetup (equivalent of mkhive, but using OS functionality).
The rationale is as follows.
We now have the 1st-stage ReactOS setup running with its own registry SYSTEM hive,
similarly to regular ROS running instances (livecd, regular installation...).
The ReactOS-specific SetInstallPathValue() hack, introduced in a76689e9 (r3794)
and 5f973ce0 (r3795), is removed. This hack told the kernel that, during the setup,
it had to "switch" the used registry hives and instead use the ones of the ROS
installation being prepared.
This was really hackish because this means, mixing between registry settings used only
for the setup running instance, that could use different registry settings
than the ones that should be set for the ROS installation being actually performed.
Also, note that in the case of a 1st-stage GUI setup, consisting in running the
LiveCD + the GUI setup program, this situation would be untenable. Note also that
for people willing to use the Setup*** functions exported by setupapi.dll to parse
the registry INF files to initialize the registry of the ROS installation being
prepared, this would be impossible either.
Hence the need to have offline registry modification functionality.
svn path=/branches/setup_improvements/; revision=74766
2017-06-03 16:22:42 +00:00
|
|
|
&Name,
|
2014-05-12 16:14:19 +00:00
|
|
|
0,
|
|
|
|
REG_SZ,
|
|
|
|
(PVOID)Id,
|
|
|
|
(wcslen(Id) + 1) * sizeof(WCHAR));
|
2010-09-25 19:24:03 +00:00
|
|
|
NtClose(KeyHandle);
|
2009-02-05 13:50:49 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
2014-05-12 16:14:19 +00:00
|
|
|
DPRINT1("NtSetValueKey() failed (Status = %lx)\n", Status);
|
|
|
|
return FALSE;
|
2009-02-05 13:50:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2017-06-30 22:46:15 +00:00
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
SetDefaultPagefile(
|
|
|
|
WCHAR Drive)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
HANDLE KeyHandle;
|
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
UNICODE_STRING KeyName = RTL_CONSTANT_STRING(L"SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management");
|
|
|
|
UNICODE_STRING ValueName = RTL_CONSTANT_STRING(L"PagingFiles");
|
|
|
|
WCHAR ValueBuffer[] = L"?:\\pagefile.sys 0 0\0";
|
|
|
|
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&KeyName,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
GetRootKeyByPredefKey(HKEY_LOCAL_MACHINE, NULL),
|
|
|
|
NULL);
|
|
|
|
Status = NtOpenKey(&KeyHandle,
|
|
|
|
KEY_ALL_ACCESS,
|
|
|
|
&ObjectAttributes);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
ValueBuffer[0] = Drive;
|
|
|
|
|
|
|
|
NtSetValueKey(KeyHandle,
|
|
|
|
&ValueName,
|
|
|
|
0,
|
|
|
|
REG_MULTI_SZ,
|
|
|
|
(PVOID)&ValueBuffer,
|
|
|
|
sizeof(ValueBuffer));
|
|
|
|
|
|
|
|
NtClose(KeyHandle);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2004-05-30 14:54:02 +00:00
|
|
|
/* EOF */
|