2019-05-30 09:48:29 +00:00
|
|
|
|
/*
|
|
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
|
* PROJECT: ReactOS kernel
|
|
|
|
|
* FILE: base/services/umpnpmgr/install.c
|
|
|
|
|
* PURPOSE: Device installer
|
|
|
|
|
* PROGRAMMER: Eric Kohl (eric.kohl@reactos.org)
|
|
|
|
|
* Herv<EFBFBD> Poussineau (hpoussin@reactos.org)
|
|
|
|
|
* Colin Finck (colin@reactos.org)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _UMPNPMGR_PCH_
|
|
|
|
|
#define _UMPNPMGR_PCH_
|
|
|
|
|
|
|
|
|
|
#define WIN32_NO_STATUS
|
|
|
|
|
#define _INC_WINDOWS
|
|
|
|
|
#define COM_NO_WINDOWS_H
|
|
|
|
|
#include <stdarg.h>
|
|
|
|
|
#include <windef.h>
|
|
|
|
|
#include <winbase.h>
|
|
|
|
|
#include <winreg.h>
|
|
|
|
|
#include <winsvc.h>
|
|
|
|
|
#include <winuser.h>
|
|
|
|
|
#include <dbt.h>
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <cmfuncs.h>
|
|
|
|
|
#include <rtlfuncs.h>
|
|
|
|
|
#include <setypes.h>
|
|
|
|
|
#include <umpnpmgr/sysguid.h>
|
|
|
|
|
#include <cfgmgr32.h>
|
|
|
|
|
#include <regstr.h>
|
|
|
|
|
#include <userenv.h>
|
|
|
|
|
#include <shlwapi.h>
|
|
|
|
|
#include <pnp_s.h>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
typedef struct
|
|
|
|
|
{
|
[UMPNPMGR][USETUP] Fix the way device-install events are queued and dequeued. Fixes CORE-16103.
Dedicated to the hard work of Joachim Henze! xD
This reverts part of commit 043a98dd (see also commit b2aeafca).
Contrary to what I assumed in commit 043a98dd (and was also assumed in
the older commit b2aeafca), we cannot use the singled-linked lists to
queue and dequeue the PnP device-install events, because:
- the events must be treated from the oldest to the newest ones, for
consistency, otherwise this creates problems, as shown by e.g. CORE-16103;
- the system singled-linked lists only offer access to the top of the
list (like a stack) instead of to both the top and the bottom of the
list, as would be required for a queue. Using the SLISTs would mean
that only the newest-received events would be treated first, while the
oldest (which were the first received) events would be treated last,
and this is wrong.
Therefore one must use e.g. the standard doubly-linked list. Also, using
locked operations (insertion & removal) on the list of device-install
events is necessary, because these operations are done concurrently by
two different threads: PnpEventThread() and DeviceInstallThread().
Since the interlocked linked list functions are not available in user-mode,
we need to use instead locking access through e.g. a mutex.
2020-09-28 20:38:55 +00:00
|
|
|
|
LIST_ENTRY ListEntry;
|
|
|
|
|
WCHAR DeviceIds[ANYSIZE_ARRAY];
|
2019-05-30 09:48:29 +00:00
|
|
|
|
} DeviceInstallParams;
|
|
|
|
|
|
|
|
|
|
/* install.c */
|
|
|
|
|
|
|
|
|
|
extern HANDLE hUserToken;
|
|
|
|
|
extern HANDLE hInstallEvent;
|
|
|
|
|
extern HANDLE hNoPendingInstalls;
|
|
|
|
|
|
[UMPNPMGR][USETUP] Fix the way device-install events are queued and dequeued. Fixes CORE-16103.
Dedicated to the hard work of Joachim Henze! xD
This reverts part of commit 043a98dd (see also commit b2aeafca).
Contrary to what I assumed in commit 043a98dd (and was also assumed in
the older commit b2aeafca), we cannot use the singled-linked lists to
queue and dequeue the PnP device-install events, because:
- the events must be treated from the oldest to the newest ones, for
consistency, otherwise this creates problems, as shown by e.g. CORE-16103;
- the system singled-linked lists only offer access to the top of the
list (like a stack) instead of to both the top and the bottom of the
list, as would be required for a queue. Using the SLISTs would mean
that only the newest-received events would be treated first, while the
oldest (which were the first received) events would be treated last,
and this is wrong.
Therefore one must use e.g. the standard doubly-linked list. Also, using
locked operations (insertion & removal) on the list of device-install
events is necessary, because these operations are done concurrently by
two different threads: PnpEventThread() and DeviceInstallThread().
Since the interlocked linked list functions are not available in user-mode,
we need to use instead locking access through e.g. a mutex.
2020-09-28 20:38:55 +00:00
|
|
|
|
/* Device-install event list */
|
|
|
|
|
extern HANDLE hDeviceInstallListMutex;
|
|
|
|
|
extern LIST_ENTRY DeviceInstallListHead;
|
2019-05-30 09:48:29 +00:00
|
|
|
|
extern HANDLE hDeviceInstallListNotEmpty;
|
|
|
|
|
|
|
|
|
|
BOOL
|
|
|
|
|
SetupIsActive(VOID);
|
|
|
|
|
|
2019-06-19 15:51:11 +00:00
|
|
|
|
FORCEINLINE
|
|
|
|
|
BOOL
|
|
|
|
|
IsUISuppressionAllowed(VOID);
|
|
|
|
|
|
2019-05-30 09:48:29 +00:00
|
|
|
|
DWORD
|
|
|
|
|
WINAPI
|
|
|
|
|
DeviceInstallThread(
|
|
|
|
|
LPVOID lpParameter);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* rpcserver.c */
|
|
|
|
|
|
|
|
|
|
DWORD
|
|
|
|
|
WINAPI
|
|
|
|
|
RpcServerThread(
|
|
|
|
|
LPVOID lpParameter);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* umpnpmgr.c */
|
|
|
|
|
|
|
|
|
|
extern HKEY hEnumKey;
|
|
|
|
|
extern HKEY hClassKey;
|
2019-06-19 15:51:11 +00:00
|
|
|
|
extern BOOL g_IsUISuppressed;
|
2019-05-30 09:48:29 +00:00
|
|
|
|
|
2019-06-19 15:51:11 +00:00
|
|
|
|
BOOL
|
|
|
|
|
GetSuppressNewUIValue(VOID);
|
2019-05-30 09:48:29 +00:00
|
|
|
|
|
|
|
|
|
#endif /* _UMPNPMGR_PCH_ */
|