Files
reactos/sdk/include/psdk
Whindmar Saksit d41dec2e07 [SHELL32][CONTROL] Added basic IOpenControlPanel support (#6248)
Add a basic IOpenControlPanel implementation that supports Vista canonical registry names.

Implements `control.exe /name company.name [/page id]` and `IOpenControlPanel`
handling of Vista-style canonical registry names.

The documented `Microsoft.*` names don't work because they are simply not
in our registry but "[Executable Control Panel Items](https://learn.microsoft.com/en-us/windows/win32/shell/how-to-register-an-executable-control-panel-item-registration-)" registered by 3rd-party ISVs
will function correctly in control.exe and the COM API.

Notes:

- `IOpenControlPanel` is implemented in CControlPanelFolder.cpp because
  it is supposed to have tighter integration with that shell folder than
  it does in this PR.

- `IOpenControlPanel` is also supposed to handle .cpl files with canonical
  names registered under [`Extended Properties`](https://learn.microsoft.com/en-us/windows/win32/shell/how-to-register-dll-control-panel-item-registration-#step-3) but the control panel folder
  does not implement `IShellFolder2::GetDetailsEx` yet, so it will have to wait.

- These "Executable Control Panel Items" are also supposed to be displayed
  in the control panel itself but this PR does not address that. The
  `ITEMIDLIST` format for those needs investigation...

- The Wow64 handling is perhaps not correct but it does not matter,
  `ShellExecuteEx` gets to deal with whatever is in the `...\shell\open\command` key.
  `CControlPanelFolder` would have to take more care when it starts
  reading those keys so it knows when to append "(32-bit)" to the display name.

- `%s%s` because .cpl canonical names don't have the `::` prefix according
  to Geoff Chappell.

- Always returns `CPVIEW_CLASSIC` because our `CControlPanelFolder` does
  not support the category view.
2024-01-17 17:07:21 +01:00
..
2023-12-23 21:37:08 +01:00

        Free headers and libraries for the Win32 API

        Originally written by Anders Norlander 
	Last known and not working email: <anorland@hem2.passagen.se>

	Now maintained by MinGW Developers
        Send bug reports and questions to MinGW-users@lists.sourceforge.net
	URL: http://www.mingw.org

* License 2.0

  You are free to use, modify and copy this package as long as this
  README.w32api file is included unmodified with any distribution, source or
  binary, of this package.  No restrictions are imposed on any package or 
  product using or incorporating this package.  You are free to license your 
  package as you see fit.
  
  You may not restrict others freedoms as set forth in the above paragraph.
  You may distribute this library as part of another package or as a
  modified package if and only if you do *not* restrict others freedoms as
  set forth in the above paragraph as it concerns this package.  You do have
  the right to restrict uses of any package using this package.

  This package 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.

* What is it?

  This is a free set of headers and import libraries for the Win32
  API.  The library differs from the GNU Windows32 library in that I
  have tried to use a file structure that mirrors Microsoft's.  I
  don't like having *all* definitions in one single header as in the
  GNU Windows32 library, I want a clean separation between different
  parts of the API.

  Daniel Guerrero Miralles contributed the DirectX 6.1 import
  libraries and DirectX GUID definitions.

  See the files NOTES and TODO for what needs to be done.

* Size does matter

  Since the WIN32 API is severely bloated (as most MS products seem to
  be) the headers are designed to be as compact as possible, while
  still being readable, in order to minimize parsing time.

  The convention is to omit parameter names for function prototypes,
  no excessive white space. Struct/union members are indented with tab
  characters to make them readable. Comment only when necessary.

  If you are contributing a patch please follow the above mentioned
  convention. Make sure your editor does not convert tabs to spaces.

* What do I need to use it?

  The library is intended for use with egcs 1.1 or later but it is
  possible to use with some other tools as well (although it is not
  very useful). LCC-Win32, MSVC and Borland C++ 5.01 or higher may
  work as well. The import libraries are for GNU tools only.

  The library requires egcs 1.1 or later, since the `#pragma pack'
  feature is used. Mumit Khan provides egcs patches and binaries for
  win32 at `http://www.xraylith.wisc.edu/~khan/software/gnu-win32/'.

  If you are going to use C++ COM objects, you will need a version of
  egcs that recognizes the `comobject' attribute and then define
  HAVE_COMOBJECT when compiling your program. Antonio Mendes de
  Oliveira Neto has a prebuilt version at
  `http://li.facens.br/EGCS-WIN32/english/index.html'. Note that this
  is very experimental. If you want to use COM objects in C++ but with
  C interfaces you must define CINTERFACE.

  Objective-C programs cannot use COM functionality because of
  conflicts between the interface define and the Objective-C
  @interface directive.  There is also a conflict between the windows
  Obj-C BOOL types. To avoid this conflict you should use WINBOOL in
  all places where you would use BOOL in a C/C++ windows program. If
  you include any windows headers *after* `windows.h' you must use the
  method outlined below:

  /* non-windows includes */
  #include <objc/objc.h>
  ...
  /* windows specific headers */
  #include <windows.h>
  #define BOOL WINBOOL
  #include <commctrl.h>
  ...
  #undef BOOL
  ...
  /* include other headers */