CORE-17819 This allows Microsoft VirtualPC 2004/2007 to boot LiveCD SAFEMODE to desktop,
the regular mode booted also without that addition already.
Fix picked from 0.4.15-dev-1537-g b1c460d34e
This commit was part of a much bigger PR3396, which I don't pick entirely today.
For CORE-17819 only this part is actually needed.
This is *no* functional change: I verified with a #pragma message "test"
locally within that block that the compilers output does not change
before and after those changes.
The binary also do not change in size.
After this commit no such issue remains in releases/0.4.9
[BTRFS] It is _WIN32_WINNT, not WIN32_WINNT CORE-12589
This is a partial port of:
0.4.10-dev-36-g c7806a6b29 CORE-12589 'drivers/filesystems/btrfs/fsctl.c: 1 _WIN32_WINNT is misspelled as WIN32_WINNT'
Ports back a real fix:
0.4.15-dev-1173-g ba09834c5e [PARPORT] Fix I/O port length check
Ports back logging and formatting:
0.4.15-dev-6794-g 4eace8d762 [IPHLPAPI] Silence obsolete FIXME in GetAdaptersAddresses (#5834) CORE-14388
0.4.15-dev-6438-g b12ab486d8 [MUP] Mute DPRINT1's that slow down shared folder accesses (#5545) CORE-19105
And mutes some other loggings as well for stuff, that I either never want to port back, e.g. the IMM-implementations,
or which is not really helpful in the older branches:
fixme:(win32ss/user/user32/misc/imm.c:446) WINNLSEnableIME is UNIMPLEMENTED!
fixme:(../dll/win32/iphlpapi/address.c:290) GetAdaptersAddresses - Semi Stub: Family 2, Flags 0x0000002e, Reserved 00000000, pAdapterAddress 00000000, pOutBufLen 0143EBD4.
when browsing the startmenu:
fixme:(dll/win32/comctl32/toolbar.c:394) [00080086] TBSTYLE_REGISTERDROP not implemented
fixme:(dll/win32/comctl32/toolbar.c:5636) [00080086] response 2045774661 not handled to NM_CUSTOMDRAW (CDDS_PREERASE)
fixme:(dll/win32/comctl32/toolbar.c:5673) [00080086] response 3225142 not handled to NM_CUSTOMDRAW (CDDS_POSTERASE)
fixme:(dll/win32/comctl32/toolbar.c:5636) [000200BA] response 9 not handled to NM_CUSTOMDRAW (CDDS_PREERASE)
fixme:(dll/win32/comctl32/toolbar.c:5636) [00080086] response 2288892 not handled to NM_CUSTOMDRAW (CDDS_PREERASE)
fixme:(dll/win32/comctl32/toolbar.c:5673) [00080086] response 3291448 not handled to NM_CUSTOMDRAW (CDDS_POSTERASE)
and a bigger block regarding the parallel port during booting:
(drivers/parallel/parport/parport.c:127) Parport DriverEntry
(drivers/parallel/parport/fdo.c:391) AddDevice(B0B50548 B0FED980)
(drivers/parallel/parport/fdo.c:25) AddDeviceInternal()
(drivers/parallel/parport/fdo.c:513) FdoPnp()
(drivers/parallel/parport/fdo.c:582) IRP_MJ_PNP / IRP_MN_FILTER_RESOURCE_REQUIREMENTS
(drivers/parallel/parport/fdo.c:513) FdoPnp()
(drivers/parallel/parport/fdo.c:546) IRP_MJ_PNP / IRP_MN_START_DEVICE
(drivers/parallel/parport/misc.c:42) Calling lower device B0FED980
(drivers/parallel/parport/fdo.c:116) FdoStartDevice ()
(drivers/parallel/parport/fdo.c:160) Port: BaseAddress 0x378 Length 8
(drivers/parallel/parport/fdo.c:160) Port: BaseAddress 0x778 Length 8
(drivers/parallel/parport/fdo.c:174) Interrupt: Level 20 Vector 55
(drivers/parallel/parport/fdo.c:195) New LPT port: Base 0x378
(drivers/parallel/parport/fdo.c:513) FdoPnp()
(drivers/parallel/parport/fdo.c:586) Unknown minor function 0x9
(drivers/parallel/parport/fdo.c:513) FdoPnp()
(drivers/parallel/parport/fdo.c:586) Unknown minor function 0x14
(drivers/parallel/parport/fdo.c:513) FdoPnp()
(drivers/parallel/parport/fdo.c:564) IRP_MJ_PNP / IRP_MN_QUERY_DEVICE_RELATIONS / BusRelations
(drivers/parallel/parport/fdo.c:351) FdoQueryBusRelations()
(drivers/parallel/parport/fdo.c:233) FdoCreateRawParallelPdo()
(drivers/parallel/parport/fdo.c:378) Done
(drivers/parallel/parport/pdo.c:165) PdoPnp()
ports back the following commits:
0.4.15-dev-3822-g 78a7d7dc32 [CMIDRIVER] Remove useless Visual Studio resource editor aps-file
0.4.12-dev-399-g 32faa24733 [BUTTERFLIES] Fix GCC build, addendum to 0.4.12-dev-397-g 2890a22179
a tiny fraction of 0.4.12-dev-397-g 2890a22179 just the [BUTTERFLIES] Avoid DLGPROC cast
Ftr, there are still a few DLGPROC casts left after this commit in ros source tree,
but I don't want to port back the commits yet, which addressed them.
Too fresh still, no need to rush that.
This fixes:
CORE-15363 'netstat TCP foreign address port is wrong'
CORE-5401 'Netstat returns ERROR_NO_DATA Pipe being closed'
CORE-5126 'UNIMPLEMENTED: iphlpapi: GetExtendedUdpTable'
even without touching the netstat binary yet.
And is mostly based on work done by Pierre Schweitzer during 0.4.11-dev'ing.
by porting back:
0.4.15-dev-6231-g a5360f542f [IPHLPAPI] Formatting only, no functional change
partially 0.4.14-dev-1425-g f540b2b20c [IPHLPAPI] GetAdaptersAddresses(): Add 1 free() in ERROR_NO_DATA case (#2526) (but leave out adding the comments in .h)
0.4.12-dev-686-g 22f60faf43 [IPHLPAPI] Remove dead code to fix CID 513306, 1442673, 1442697
0.4.11-dev-880-g bf052e120b [IPHLPAPI] Reduce code duplication and use a single function for TCP and UDP enumerations + fix corruption
0.4.11-dev-867-g 159f5b676a [IPHLPAPI] Fix broken size computation leading to buffer overrun
0.4.11-dev-861-g 05657bfcfd [SDK] Add a non documenter TOIID used to query modules information
0.4.11-dev-827-g ce7f9211a0 [TCPIP] In InfoTdiQueryGetConnectionTcpTable(), only return if there's a connection
0.4.11-dev-823-g 0ec92100bc [TCPIP] Properly display local information for established connections
0.4.11-dev-819-g fbdfe7bd40 [SDK] Add GetExtendedUdpTable()
0.4.11-dev-818-g 370b03b523 [IPHLPAPI] Reimplement GetUdpTable() using GetExtendedUdpTable()
0.4.11-dev-817-g 58cef01422 [IPHLPAPI] Implement GetExtendedUdpTable() CORE-5126
0.4.11-dev-816-g 6fb6c7b50b [IPHLPAPI] Implement getOwnerUdoTable(), to get UDP connections with owner PID
0.4.11-dev-815-g 13de7f08af [TCPIP] Implement enumerating UDP connections with owner PID
0.4.11-dev-813-g 73c87d5c14 [IPHLPAPI] Reimplement GetTcpTable() using GetExtendedTcpTable()
0.4.11-dev-812-g d76ac645e8 [IPHLPAPI] Don't leak memory
0.4.11-dev-811-g c949a12506 [IPHLPAPI] Implement the IPv4 TCP_TABLE_OWNER_PID_* cases in GetExtendedTcpTable()
0.4.11-dev-810-g dca7e5689f [IPHLPAPI] Implement getOwnerTcpTable(), to get TCP connections with owner PID
0.4.11-dev-809-g 411504b5f4 [TCPIP] Implement enumerating TCP connections with owner PID
0.4.11-dev-808-g 935978ee57 [TCPIP] Store creator PID in ADDRESS_FILE
0.4.11-dev-807-g 702d44c683 [IPHLPAPI] Implement the IPv4 TCP_TABLE_BASIC_* cases in GetExtendedTcpTable()
0.4.11-dev-804-g 91b013d387 [TCPIP] When enumerating sockets, retrieve their state and return it
0.4.11-dev-803-g 738f327668 [IP] Add a TCPGetSocketStatus() wrapper around LibTCPGetSocketStatus()
0.4.11-dev-802-g 29c1510423 [LWIP] Implement a LibTCPGetSocketStatus() function in our LwIP glue
0.4.11-dev-792-g 8a98c85c1f [IPHLPAPI] Fix checking entity when enumerating TCP/UDP connections
0.4.11-dev-784-g f29016dabe [TCPIP] Properly handle listening sockets
0.4.11-dev-782-g 007f43dd56 [TCPIP] Implement returning UDP connections CORE-5401
0.4.11-dev-781-g 77d5f04f22 [TCPIP] Implement returning TCP connections CORE-5401
0.4.11-dev-799-g 500a5151ea [TCPIP] Fix returned IP address when querying TCP connections CORE-15363
0.4.11-dev-783-g d18b1fe24b [IPHLPAPI] Properly count UDP entries CORE-5401
0.4.11-dev-780-g e3cb9697a4 [IPHLPAPI] Implement getNumUdpEntries() and getUdpTable() CORE-5401
0.4.11-dev-779-g 678204790c [IPHLPAPI] Implement getNumTcpEntries() and getTcpTable() CORE-5401
----------------
Strip some DPRINTs entirely in IPHLPAPI/TCPIP in releases/0.4.7 - 0.4.10 (instead of fixing them like we did on master). Many of them had x64 issues:
This was partially *inspired* by watching the following commits:
0.4.13-dev-14-g f9a967b2ae [IPHLPAPI] Fix misc 64 bit issues (only the parts in iphlpapi_main.c with the format strings)
0.4.10-dev-409-g 0f8439aa71 [IPHLPAPI] Fix 64 bit issue, just the one within [IPHLPAPI] ifenum_reactos.c
0.4.9-dev-856-g 6c9359221c [IPHLPAPI] ipstats_reactos: Review all TRACE/WARN calls
This does not only fix the x64 incompatibilities by superseding those 3 commits but also will keep the file-sizes under control for the backports.
fix CORE-18328 'FileZilla 3.8 unable to list content of a remote directory due to undue ECONNRESET'
I tested to list the contents of ftp.heise.de and downloaded some files from its pub.
by porting back:
0.4.15-dev-5870-g 9f9b81e396 [AFD] ReceiveActivity: Don't return STATUS_FILE_CLOSED in case of FCB overread CORE-18328 (#4972)
Optimize IOCTL_CONSOLE_FILL_OUTPUT_ATTRIBUTE and IOCTL_CONSOLE_FILL_OUTPUT_CHARACTER for speed by using cache.
a part of CORE-18838
It is faster because it minimizes the amount of pointer dereferences within the for-loops.
fix picked from 0.4.15-dev-5881-g 3526ffc094
---------
also partially pick unrelated cleanup from:
0.4.14-dev-439-g 75f188c200 (only the change in blue.c)
---------
and take back with me some whitespace-tweaks to bring the file closer to todays releases/0.4.14
port back:
0.4.10-dev-615-g 45fd48bd0f [CDFS_NEW] -> [CDFS] No old driver, thus no new driver
0.4.10-dev-614-g 5795254933 [CDFS] Delete the old CDFS driver.
The new MS PL licensed one worked for several years fine for us now
even in the older releases.
So no need to keep our old unfinished one any longer within
the release-branches. They are no mausoleum.
This does *not* change, which driver is actually in use.
We do continue to use 1:1 the state of current releases/0.4.10
First part with the typo in the assert was introduced by 5579428b4f
which was merged into ros by a merge-task during 0.4.8-dev'ing.
releases/0.4.7 didn't have that code yet.
fix picked from 0.4.15-dev-5035-g f308c6a2bc
----------
[NTFS] Do not print debug message for every function call by default
That 2nd part was picked from 0.4.13-dev-450-g 1552434940
----------
And for all the files that I had to touch for the 2nd part in the older branches,
I ported back also some EOL-whitespace-fixes within like they were done during 0.4.15-dev'ing.
can be observed with MSVC 2010SP1 (16.0.40219.1) x86 target in dbg configuation:
C:\047rls\reactos\drivers\bus\acpi\cmbatt\cmbatt.c(983) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
partial pick of 0.4.13-dev-713-g 08c6d21e1f
I am not sure why this line in id_queue.cpp was added.
I don't know how I could improve that case.
Then, disable it, for the time being.
It regressed by 4b9cf2e339 (r71252). CORE-12441 CORE-17371
fix picked from 0.4.15-dev-2740-g ba77a09c04
While touching uniata do also PARTIALLY port back some bm_devs.h changes:
0.4.15-dev-1522-g 88d36c93a2 (Properly mark ReactOS diff from upstream)
Changes to specific files and their effects are as follows:
create.cpp - Allows booting past second stage with UDFS media inserted without BSOD
close.cpp - Allows shutdown without hang
dircntrl.cpp - Allows New Hardware Wizard not to hang on initial third phase install
It began to crash with the introduction of the UDFS driver in SVN r74901 == git 3a104c8f20
Fix picked from 0.4.15-dev-3326-g a91f5e8e4d
Historically we did hit assertions and exceptions in MS CDFS driver
when special characters 'äöüßÄÖÜ' were used in a valid filesystem.
We did already apply varying workarounds for those issues
into CDFS_NEW for 0.4.8, 0.4.9, 0.4.10
while we were in the learning curve still.
Later we found the root cause to be our faulty XDK
FsRtlIsAnsiCharacter* macros.
By fixing the macros we can replace the varying historic workarounds
and sync to the final 0.4.11-dev master state.
We did not ever observe new issues with any other filesystems that do
also use those macros during the last years. So we can sync now.
This fixes a regression introduced by 0.4.8-dev-164-g
ec6b3ecbe4
when the new driver was activated for compiling.
Many thanks to Thomas Faber, Pierre Schweitzer, Serge Gautherie
The fix is squashed backport of commit 0.4.12-dev-431-g
bccad87f3c
and commit 0.4.12-dev-432-g
3463b2db9f
This avoids improper returns when multiple entries are requested
and, in rare circumstances, entries not being seen by umode.
CORE-14699
(cherry picked from commit 01e2877161)
This avoids race conditions under high IOs and thus corruption on
the FS, or assertions failures in the kernel.
Easily triggered by building ReactOS on ReactOS ;-).
(cherry picked from commit 30b836bf3f)
Fixes BSODs when starting Deluge Torrent 1.3.12.1 & QBitTorrent 3.2.0
due to running "Out of NP Expansion Pool"
This patch is still WIP of ThFabba.
like in 0.4.8 before
(cherry picked from commit 6b8b704e6f)
Until now, our support for dirty volumes was totally broken
to a point where, on FAT32 volume, the dirty couldn't even
be written nor read from the disk.
This commit totally rewrites its handling, for both FAT16 and FAT32
so that it's now fully functionnal. Furthermore, it also gets
totally compatible with our vfatlib, and thus, autochk.
Now, on mount, FastFAT will check if the volume is dirty or not, and
autochk will be able to ask for a repair if dirty. vfatlib will
repair the volume and remove the dirty bit. So that, on next
reboot, the volume will be mounted clean.
As a reminder, the dirty bit is set immediately after mounting
the volume, so that, if you crash or have a powercut, autochk
will always attempt to repair your volume (with more or less,
that's FAT!).
If you want to experience without breaking your FAT volume,
just boot, open a cmd prompt and type: fsutil dirty set c:
and reboot!
CORE-13758
CORE-13760
CORE-13759
This is a hack, and totally not the default behavior.
But it will allow autochk locking the boot volume in
order to verify it on boot, in case it would have
been improperly dismounted.
CORE-13759
This avoids initializing cache directly on directory
open/create.
The advantage is we reduce the load on cache manager
and on memory manager by avoiding creating everytime
a stream file object, and initializing cache for it.
This will avoid initializing cache for started
applications 'current directory' which is just opened
for having a valid handle but no read/write is performed
in it, by default.
This is a step forward for autochk.
CORE-14629
Before performing a read operation, FastFAT driver will
attempt to compute whether it would run out of stack
during the operation. If so, instead of attempting the
operation in the current thread, it will post the read
request to the overflow thread.
This should help with the regressions brought in by
94ead99e0c.
CORE-14601
Before any write operation that would involve caching, ask
the cache controler whether writing would make it exceed its memory
consumption. If so, queue the write operation for later execution.
In case the write operation can wait, then, the FSD operation will be
halted until the write is allowed.
I could test it successfully by copying huge files from a FAT volume to
another. The write is halted until some portions of the file is written
to the disk.
I could also properly install Qt (SDK) on ReactOS with this and less than 1GB RAM:
- https://www.heisspiter.net/~Pierre/rostests/Qt_OS.png
- https://www.heisspiter.net/~Pierre/rostests/Qt_OS2.png
CORE-12081
CORE-14582
CORE-14313