Author: Puetz Kevin A <PuetzKevinA@JohnDeere.com>
atlbase.h: Fix some declarations on win64.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
- Rename parameters according to [MS_PNPR] (no longer available for download).
- Remove unsupported PNP_DEVINST_MOVE and PNP_DEVINST_DISABLE actions.
- Implement most of the PNP_DEVINST_SETUP action.
Reject invalid input filename characters by using shell32!SHLimitInputEdit function and IItemNameLimits interface. Improve SHLimitInputEdit to sanitize paste.
CORE-11701
Surprisingly this also happens to "fix" random "Invalid Opcode" exceptions in XQEMU.
(But I think it's more like a coincidence... --hbelusca)
CORE-16627 CORE-16216
- Add "Product Options" wizard page into ReactOS Setup.
- Implement CSIDL_Type_InMyDocuments CSIDL type.
- If the product type is workstation, then some special folders will be in My Documents.
CORE-13795
The code is mostly unchanged. This includes the following changes:
* Move all wine code to crt/wine to keep it separated from our own code
* Add a minimal winternl.h
* Remove the asm macros from wine/config.h
* Include wine/asm.h where required
* Fix the names of the exported functions (GCC uses thiscall now and no wrappers are used anymore)
The "TypeOffset" thing was just an informative comment to tell that the
data that follows after the IMAGE_BASE_RELOCATION header is an arbitrary
array of WORDs describing packed (Type + Offset)s.
Having the header structure containing that spurious "TypeOffset" was
breaking all the code that was basing on expected size of the
IMAGE_BASE_RELOCATION structure in order to apply relocations (typically
this would mean that the first 2 relocations described by it would not
be applied).
Hopefully this bug only hit the host-tools, and not the OS itself :)
The first part of PC-98 Port - https://reactos.org/wiki/PC-98
- Add FAT12 file system boot sector for NEC PC-98 series.
- Add a new build target for a PC-98 bootable floppy disk.
- Add a new sub-architecture into config.cmake.
- Make the format actually MS-compatible: "ATL" followed by colon,
followed by hexadecimal digits of pointer.
- The MS counterpart of this DLL was delivered with Visual C++ 6.0 and
Windows 98+, so obviously it always was 32-bit and they never had a
64-bit version for it. But we do. So make the size of the m_szAutoName
buffer cross-compatible.
- See previous commit dbddd878 and the discussion in PR #2010.
The autogenerated name has the format:
"ATL:<hexadecimal_digits_of_pointer><NULL-terminator>"
and the number of hex digits in 0xABCD1234 (for 32-bit == 4-byte)
pointers (without the '0x') is 8 == 4*2, and for 64-bit == 8-byte
pointers (e.g. 0xABCDEF0123456789) is 16 == 8*2.
Also convert all sizes and positions of CONSOLE_DRAW to USHORT since
this is the standard type for all console buffer positions & sizes
(minimum value 0, maximum value 0xFFFF == 65535).
The reason is that dlltool orders the exports differently than MSVC builds (MSVC orders the exports by symbol name, rather than by export name), so we rely on sorting in the spec file, which was only respected, when ordinals were put into the def file.
On MSVC builds it is left to the linker to determine the correct order, which helps to get the differences between architectures right (different symbol decoration, difference between order for functions like NtLoadKey vs NtLoadKey2, which results from the stdcall decoration on x86, which is missing on other architectures.
TODO: To correctly handle non-x86 architectures with GCC builds, spec2def would need to reorder the export list based on symbol names, which would work for C functions, by taking the calling convention into account, but would require an extra c++-stdcall calling convention to be added to know the corresponding symbol starts with "?".
