It contains both the text-mode 1st-stage installer and the LiveCD
functionality with the 1st-stage GUI installer.
Our separate LiveCD ISOs become obsolete, and this completely remove
the need for the so-called "hybridcd" ISO.
Some details:
- the "hybridcd" build target is completely removed, since now the new
BootCD *is* basically what we used to call "hybridcd";
- the "livecd" build target is kept so far (to minimize the code changes),
but internally I start to refer to it as "LiveImage", and it is reduced
to a minimum: currently a minimal non-bootable "liveimg.iso" is built
in order to implement the "ReactOS Live in RAMDISK" functionality
(we currently don't support other file formats apart from ISO and
flat disk for a RAMDISK), while the "ReactOS Live" (non-RAMDISK) is
implemented by adding to the BootCD file tree the files from the LiveImage.
These files add two root directories, "Profiles" and "reactos" (which is
the SystemRoot for the non-ramdisk LiveImage).
- The minimal text-mode ReactOS installation used during the 1st-stage
text-mode installer, including USETUP itself and the executable for
the 1st-stage GUI installer and the reactos.cab (installation source)
are moved to the root directory called "i386" (ideally, one directory
per architecture).
- the "bootcdregtest" target, i.e. the ISOs we feed our testbots with,
are left untouched, i.e. they are only constituted of the 1st-stage
text-mode installation, in the root directory named "reactos".
More details will be presented in a subsequent mail to the ros-dev mailing list.
svn path=/branches/setup_improvements/; revision=75273
It contains the functionality of both the original bootcd (text-mode
1st-stage installer) and the livecd (that will include the 1st-stage
GUI installer later).
Our separate livecd ISOs become obsolete, and this completely removes
the need for the so-called "hybridcd" ISO.
Some details:
- The "hybridcd" build target is completely removed, since now the new
BootCD *is* basically what we used to call "hybridcd".
- The "livecd" build target is kept so far (to minimize the code changes),
but internally I start to refer to it as "LiveImage", and is reduced
to a minimum.
A minimal non-bootable "liveimg.iso" is built (but currently not
included within the BootCD). Its purpose will be to implement the
"ReactOS Live" functionality as a RAMDISK.
(We currently don't support other file formats apart from ISO and
flat disk for a RAMDISK).
The "ReactOS Live" (non-RAMDISK) is implemented by adding to the
BootCD file tree the files from the LiveImage.
These files add two root directories, "Profiles" and "reactos"
(which is the SystemRoot for the non-ramdisk LiveImage).
- The minimal text-mode ReactOS installation used for the 1st-stage
installer, including USETUP itself, and the executable for the
1st-stage GUI installer and the reactos.cab (installation source),
are moved to the root directory called "i386" (ideally, one directory
per architecture).
- The "bootcdregtest" target, i.e. the ISOs we feed our testbots with,
are left untouched, i.e. they are only constituted of the 1st-stage
text-mode installation, in the root directory named "reactos".
This commit is based upon an older SVN one:
svn path=/branches/setup_improvements/; revision=75273
For SOME reason comctl32 has been synched manually multiple times to different versions and different pots
This PR aims to fix that
With the exception of button.c which all in all is a massive fork over wines code entirely.
and datetime.c which is at wine 6.0
Comctl32 is now at wine-5.0
Fixes a bug where if you close Notepad while it is maximized, the next time Notepad is started it will start with its window placed as if maximized but it is still in the SW_RESTORE state and the "real normal placement" is lost.
SetWindowPlacement also takes care of making sure the window is placed correctly on the monitor workarea.
Optimize BroadcastSystemMessage with Environment parameter.
Minimize processing when UserModeMsg->lParam is NULL and KernelModeMsg->message != WM_WININICHANGE
Make sure that we have a UNICODE_NULL within lParamMsg based on comment from @whindsaks
@I_Kill_Bugs fix
CORE-11787, CORE-17721 and CORE-19721
For function IntExtTextOutW with space character, the x-dimension should be taken into account.
Fixes HexEdit 1.2.1 right side of display window not being cleared.
Account for x-dimension if TA_UPDATECP flag set and 'String' is not NULL.
Clarify 'etx' is ASCII End of Text
As part of fixing some bugs like CORE-13149, extend the tests to include more detailed examination of rendering functions. Extend the RedrawWindow test to include tests of all flags. As part of it, I am also testing the 2-point states of the render areas.
I moved the original test without changes into a separate function GetMessageRedrawWindowTest. For the flag tests I added FlagsRedrawWindowTest function. It sequentially tests the RedrawWindow with different flag combinations and compares the results with those discovered in Windows XP and Windows 11 (the values in both versions confirmed to be identical).
The API test turned out well in ReactOS, the only deviation was that in many cases (whenever the RDW_INVALIDATE flag is present) a WM_ERASEBKGND message is received after the window is rendered without the RDW_ERASE flag.
(this is what I'm focusing on now in https://github.com/turican0/reactos/tree/fix-RDW_ERASE-in-co_UserRedrawWindow, but before I merge it, I want to create more API tests)
- [SDK][INCLUDE] Redirect CLSID_ConnectionFolder to CLSID_NetworkConnections
CLSID_NetworkConnections is the official known name for the class behind it,
thus to avoid breaking current code I 'softlink' CLSID_ConnectionFolder
to the currently used CLSID_NetworkConnections in shlguid_undoc.h.
- [SHELL32] Refer to CLSID_NetworkConnections from PSDK
- Add bugcodes dependency, fixes a rare build failure
- Fix for the sync part of commit 823fdb19d7, somehow it didn't pick up the change from the upstream commit b22efbb8b8
__ftol2 is exported from msvcrt on NT6+, not from ntdll for some reason. So native apps still need to statically link _ftol2 and _ftoul2_legacy, but apps linking to msvcrt only need to statically link _ftoul2_legacy (via msvcrtex), when on NT6+.
CORE-13525
- Newly-created partitions and unpartitioned space ar reinserted
or updated in correct order in the tree-list. Volume-creation
information data associated with the tree items is persisted
across operations.
- Reliably delete data associated to tree-list items via the
TVN_DELETEITEM notification.
This allows simplifying the cleanup function; keeping simple
the code that deletes items when deleting partitions, etc.
- Make the PrintPartitionData() function call itself recursively on
extended partitions to display the sub-list of logical partitions.
- Handle the new partition size in MB the same way as in USETUP.
- Allow existing partitions/volumes to be re-formatted, using
common code with the partition creation dialog.
- Allow selecting unpartitioned space or non-formatted partitions
for installing ReactOS: unused space will automatically be
partitioned and non-formatted partitions formatted (the user
is prompted for choosing the file system).
- Correctly zero the progress-bar position when starting file copy.
- Add missing file copy error handler in FileCopyCallback:
just copying what USETUP does.
This is used by CL v19.41+. It replicates the behavior of the inline assembly code that previous CL versions generated. According to tests it works the same as with previous VS versions.
These tests come with a VS solution, because that is the only way to test against a known good system, as the required runtime functions (like _ftol) are statically linked from the VS runtime library.
Checks CORE-19669, making sure that CS_HREDRAW and CS_VREDRAW
are respected when the client area changes due to the scrollbar
disappearing or re-appearing.
ROSTESTS-397
Co-authored-by: Stanislav Motylkov <x86corez@gmail.com>
* fix CORE-9141 - adding a change to IDEvent after each pass
If the first index is 0 the first returned ID will be 0x8000, which is fine.
Co-authored-by: Joachim Henze <joachim.henze@reactos.org>
Test 1 - test of creating/canceling 20 timers and comparing the raw number of returned messages - without parent window
Test 2 - test of creating/cancelling 20 timers and comparing the raw number of returned messages - with parent window
Test 3 - test creation/cancellation of 40000 timers - without parent window
Test 4 - test of creation/cancellation of 40000 timers - with parent window
Test 5 - test creation/cancellation of 2 timers and compare their index to see if they differ - without parent window
Covers the case in CORE-9141 (see #7087).
CORE-13525
This greatly helps in reducing code complexity in some areas: code that
previously iterated over all partitions of a given disk, just to find
which ones were partitioned and contained a valid file system, now just
have to iterate over mounted volumes.
See in particular, `lib/utils/osdetect.c` and `lib/fsutil.c` .
- Remove FORMATSTATE "Preformatted" enum value;
- Cleanup osdetect code after introducing Volume support;
- Some simplifications for FormatState.
- Differentiate between 'new' partition and 'new' volume:
* "New" partition: it has been created and added in the cached list,
but not yet actually written into the disk.
* "New" volume: newly-created volume (may be backed by a partition or
not), not yet formatted. May exist on either new, or not new partition,
or elsewhere.
- Cache partition and volume NT device names.
These do not change across repartitioning operations, as long as the
partition or the filesystem volume hasn't been deleted/recreated.
This avoids doing \Device\Harddisk%u\Partition%u sprintf's everytime
we need to retrieve the given partition or volume device name.
When a partition/fileysystem volume is "virtually" created (i.e. in
the partition list, but not yet committed to disk and exposed to the
OS), no device partition number and device name are available yet.
In particular, validate that no manipulation of \Device\HarddiskM\Partition0
(i.e. the whole disk) is being made.
According to our declaration/definition, IoChangeFileObjectFilerContext returns NTSTATUS, not BOOLEAN. Zero return (which was actually checked before) for BOOLEAN means failure, but for NTSTATUS it's success. So it should (and now actually does) free and fail appropriately only in failure case, but not in success, when it shouldn't.
This fixes most of problems with fltmgr.sys driver from Windows XP/Server 2003 and a lot of 3rd party filter drivers which use it from many apps (Avast Free Antivirus all versions, Avira AntiVir Personal 8.2, Dr. Web Security Space 8.0, Kaspersky Antivirus 2012 etc. etc.).
CORE-14157, CORE-14635, CORE-19318
