* Remove a hardcoded copyright string and move into localizable resources.
* Remove the PROMPT environment variable from clean installs of ReactOS. By default, the command prompt uses $P$G (path + '>') as its prompt settings and does not require this environment variable. Clean installs of Windows Server 2003 do not include this environment variable either. I documented this environment variable in our wiki if anyone would like to set it on their own ReactOS installs.
* Remove the new line above the copyright notice when the information line is turned off.
CORE-16193, CORE-17031
This removes all fake apiset forwarders,
and handles apisets inside ntdll.
This is not 100% compatible with how windows does it, but it should be good enough for us.
Supporting TIPs...
JIRA issue: CORE-19360
- Add "IME File" registry value
as "msctfime.ime" at
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IMM.
- Modify UserIsCiceroEnabled
function for preparation of
CTF IME.
Based on CORE-19346 "segoe-ui-symbo.patch".
In order to display gender glyphs (U+2642 and
U+2640; ♂ and ♀), we add a font substitute from
"Segoe UI Symbol" to "Arial".
ReactOS Arial has many symbol glyphs, so I think
we can use it for "Segoe UI Symbol" font substitute.
The glyph size problem will be fixed in #6156.
CORE-19346
These adapters were common in DEC Alpha boxes and they are really rare
nowadays. The 21140 chip is emulated in Connectix / Microsoft Virtual PC
and Hyper-V Gen 1 VM.
This is an experimental driver, not yet tested on real hardware.
CORE-8724
Adds the option to set the address edit box to use the display name or the full path. Also refreshes the window title and edit box in all open explorer windows when changing these settings using the folder options dialog.
## PROPOSED CHANGES ##
- Create a new CabinetStateSettings type that inherits from the CABINETSTATE type. This allows us to add additional cabinet state settings not exposed in the CABINETSTATE type as well as adding a Load() method to easily populate the cabinet state settings.
- Add a global cabinet state settings object. While most settings in browseui are stored independently in each shellbrowser window, cabinet state settings are global and apply to every shellbrowser window. This can be confirmed on Windows Server 2003 and Windows 7.
- When receiving the WM_SETTINGCHANGE window message from the folder options dialog, refresh the title of the window and the text in the address edit box. This is the same behavior as Windows Server 2003 and Windows 7.
Add a DWORD registry value to HKCU\...\Explorer\CabinetState\FullPathAddress to allow users to toggle this setting on or off in our folder options.
CORE-9277
This works similarly to how our shell stores its settings from a software design standpoint.
- Add settings.cpp file and ShellSettings structure to load and save settings.
- Add a registry value to hivedef.inf for the locked toolbar state.
This prevents a bug where the associated registry key cannot be opened or saved to.
- Add new BWM_SETTINGCHANGE window message to refresh the UI on setting changes
and send it to every open window when saving settings to the registry.
- Add new BWM_GETSETTINGSPTR window message to share the shellbrowser settings
structure pointer with child windows and toolbars.
- Set `HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CabinetState\FullPath` to 0 by default.
Adding this registry value also enables the "Display the full path in the title bar" option in our folder options window.
- Query the same registry key when the file explorer is started to determine whether to use the full path or the display name in the window title.
CORE-19046 CORE-18904
New ReactOS can zip/unzip files and folders in UTF-8 filenames.
You can also choose the codepage of filenames to zip/unzip via
the ZipCodePage / UnZipCodePage registry values on the registry
key HKEY_CURRENT_USER\Software\ReactOS.
Windows 8 or later also support UTF-8 zipped folders.
You can also use 3rd party software to zip/unzip in older Windows.
- Use <atlconv.h> for string conversion.
- Use zipOpenNewFileInZip4_64 instead of zipOpenNewFileInZip3_64,
and then add MINIZIP_UTF8_FLAG flag.
- Set the filenames in UTF-8 by using CP_UTF8 codepage.
- Codepage is user selectable via registry settings.
CORE-16668
Enable the explorer status bar by default, which
the vast majority of our community voted for.
Set `HKCU\Software\Microsoft\Internet Explorer\Main\StatusBarOther`
to 1 in hivedef.inf. This will show the status bar by default.
CORE-19028 CORE-19010
- Add registry key to show the time and date when two lines are available
in the taskbar clock area.
- Keep old behavior when `PreferDateOverWeekday` registry key in
`HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced`
is set to 0 or not present.
When three or more lines are available, the clock will continue to show
the time, day of the week, and the date. When only one line is visible,
the clock will continue to only display the time.
CORE-19018
Based on a commit by Vadim Galyant:
5ef5c11e7f
Also fix a minor type conversion warning. CORE-18963 CORE-17977
Co-authored-by: Vadim Galyant <vgal@rambler.ru>
For: hivedef.inf, powercfg.cpl, sysdm.cpl
and: netshell.dll, netcfgx.dll, shell32.dll, userenv.dll
Also fix "My Documents" and "My Network Places" folder names.
Miniport drivers import from NDIS, but NDIS does not support being
loaded as a dependent driver (it does not have DllInitialize).
Instead, NDIS needs to load before all possible miniport drivers,
even boot-start ones. We achieve this by placing it in its own service
order group, which loads before the NDIS group.
All our miniport drivers are demand-start, so would automatically start
later. The ndisprot driver from the ticket is likely the first boot-start
miniport we've encountered. Since DriverEntry did not run,
AdapterListHead was NULL, resulting in the crash.
This is what Windows does. And we forgot this location here.
This is an addendum to
0.4.15-dev-5365-g 9bb5627df6 [SETUP][INF] Use the standard "Helv" -> "MS Sans Serif" substitution... (#4864)
- Delete "DejaVu Sans Mono" font files (DejaVuSansMono.ttf etc.).
- Re-map "Terminal" font substitute to "Lucida Console" except for HebrewFonts and UnicodeFonts.
- Re-map HebrewFonts "Terminal" font substitute to "Courier New".
- Re-map UnicodeFonts "Terminal" font substitute to "Courier New". And then, re-map UnicodeFonts "Courier" font substitute to "Courier New". Delete UnicodeFonts "Courier New" font substitute.
CORE-18605
The keyboard layout file names of ReactOS are different from Windows' ones. It was one reason why ImmInstallIMEW fails.
- s/kbdbgm/kbdbu/ Bulgarian (Typewriter)
- s/kbdgrist/kbdgr1/ German_IBM
- s/kbdes/kbdsp/ Spanish (non-alternate!)
- s/kbdja/kbdjpn/ Japanese
- s/kbdko/kbdkor/ Korean
- s/kbdsk/kbdsl/ Slovak
- s/kbdsk1/kbdsl1/ Slovak (QWERTY)
CORE-11700
Restore MUP again back to its "Network" group. CORE-12107
This reverts commit 21fc538c (r75355), that reverted part of
commit e145ed06 (r72450).
In addition: noticed by Serge Gautherie (see CORE-12107):
- AudioSrv belongs to "AudioGroup" (and not "Audio" that doesn't exist).
- lanmanworkstation belongs to "NetworkProvider" (without a space).
- Fix the ErrorControl values to 1 (SERVICE_ERROR_NORMAL).
- Fix RamDisk driver type (it's SERVICE_KERNEL_DRIVER, not FS).
- btrfs.inf : This is a filesystem driver, so fix its ServiceType.
- Move 3rd-party FS data (btrfs, ext2, nfs(d)) from the system
hivesys.inf and into their dedicated **.reg.inf files.
They date back from commit a880f2ee (r9611), and were the root cause for
the bug that was tentatively fixed by commit 81a9ce44e (PR #755).
On Windows, boot file system drivers have either the SERVICE_DEMAND_START
or the SERVICE_DISABLED start type, and only the filesystem to access the
boot media is manually loaded by the OS loader (other FSes that are needed
later are loaded by the FSRecognizer).
Also there is no need to disable NTFS anymore.
Typos introduced in commit 4d1ea554c.
These had the effect of enumerating "NetworkProviderRemoteValidation"
and "Extended BasePCI Configuration" as groups, which were of course
invalid/non-existent.
The actual groups are: "NetworkProvider", "RemoteValidation",
"Extended Base", and "PCI Configuration".
Fixing this may correct the loading order of drivers that belong to
these groups (if we do have such drivers).
This includes:
- the default TimeText;
- the default colors.
They can however be changed by the user at one's convenience, by
explicitly specifying different values.
Suppose you copy a CPL file (e.g. console.dll renamed into console.cpl)
into a path containing spaces, for example into the Desktop:
C:\Documents and Settings\Administrator\Desktop\console.cpl
If the shell registry value for the "open" action of 'cplfile' does not
contain quotes around %1, then the Control_RunDLL function will attempt
to load "C:\Documents" as a file, which of course does not exist.
(NOTE: Missing in ReactOS: Doing a PathFindOnPath() or a PathFileExists()
call to verify that the file actually exists, instead of blindly trying
to run it and failing later in kernel32!LoadExecuteExW ...)
Adding quotes around the %1 fixes this and the correct file is being
loaded.
This behaviour has been confirmed to exist e.g. on Windows Server 2003
too (and is thus *NOT* a bug in ReactOS/Wine's Control_RunDLL
implementation).
----------------------
How to confirm this behaviour, in Win2k3 x86:
1. Start Win2k3 in debug mode under WinDbg. Ensure you have the debug
symbols available.
2. Once loaded, break into the debugger, attach context to explorer.exe,
and enter the magical :) single WinDbg command (all in one line, with
**NO inserted newlines!!**):
bp shell32!CPL_RunMeBaby ".echo \"CPL CmdLine:\"; ?? (wchar_t*)*(void**)(@esp+12);
bp SHLWAPI!PathIsFileSpecW \".echo \\\"CPL Path:\\\"; ?? (wchar_t*)*(void**)(@esp+4);
bc \\\"SHLWAPI!PathIsFileSpecW\\\"; g;\"; g"
(Explanation:
a breakpoint is placed in the internal shell32!CPL_RunMeBaby function.
When the bp is hit, it runs the large WinDbg command inside the quotes.
This command echoes an informative line, then dumps the 3rd parameter
of the function on the stack that contains the CPL command-line.
It then adds a new breakpoint in SHLWAPI!PathIsFileSpecW, which is the
function that is being called *just after* the internal parsing of the
CPL command-line, and will verify whether the extracted CPL path does
exist. That new breakpoint in turn will run a WinDbg command that will:
(i) Display the CPL file path (1st-param of that new function), then
(ii) Clear that breakpoint. Finally, automatic continuation ensues.)
3. On vanilla Win2k3, whose 'cplfile' "open" action does contain the
quotes around %1:
rundll32.exe shell32.dll,Control_RunDLL "%1",%*
you will observe the following:
CPL CmdLine:
wchar_t * 0x00094e30
""C:\Documents and Settings\Administrator\Desktop\console.cpl","
CPL Path:
wchar_t * 0x0007f898
"C:\Documents and Settings\Administrator\Desktop\console.cpl"
Notice the extra pair of quotes around the CPL filename in the CmdLine.
4. When modifying the 'cplfile' "open" action by *removing* the quotes
around %1, you will instead see the following, thereby confirming
the behaviour, which is now identical to what used to happen in ROS:
CPL CmdLine:
wchar_t * 0x00094e30
"C:\Documents and Settings\Administrator\Desktop\console.cpl,"
CPL Path:
wchar_t * 0x0007f898
"C:\Documents"
Due to the (now) absence of quotes around %1, the command-line gets
wrongly parsed and the extracted file path is incorrect.
