This particular bug involved a DST offset of -25 hours, which broke
Mono.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51758
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Microsoft data is contiguous, and there applications (e.g., Mono) that
depend on that.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51758
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The name from CLDR is made available both in the Display and MUI_Display
fields, reproducing the Windows behavior.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The sources used to regenerate data are:
* The Olson database, tracing all world time zone changes since 1970,
widely used under Unix systems and dedicated to the public domain.
* Unicode CLDR's windowsZones.xml, used by Windows itself as source
for naming timezones and providing the correspondance with the
Olson zones. It is licensed under a MIT-styled license.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently only acting as a pass-through driver, matching any device with
a WINEBUS\WINE_COMP_XINPUT compatible id.
This creates new WINEXINPUT\ bus and the gamepad PDO on it, adding the
&IG_ device id suffix to the original device id (replacing an eventual
&MI_ suffix), and removes the need to set it on winebus.sys side.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since 28fe84da45, the main exe image
must be mappable at its desired base address, which essentially
requires the preloader.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51539
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Sometimes the program path is quoted, sometimes it isn't, same for the
file argument. This can cause issues when there's spaces in the path.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This will be needed as ndis.sys depends on iphlpapi which will
in turn depend on nsi.
Note that this isn't quite how the tags are supposed to work. The
tags should be ordered according to the load group's order list.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Classic Blue is a visual style that uses blue as the main color and doesn't have bitmaps for UI
controls.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Unlike Unix, on Windows the file name is not plural.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
On Apple Silicon, Rosetta allocates memory starting at 0x100000000
(the 4GB line) before the preloader runs.
The .NET 3.5 installer and DirectX Jun2010 redistributable both contain
non-relocatable EXEs with that base address, which fail to run.
The workaround is to create an empty linker section at that address,
which is mapped by the kernel before Rosetta runs and forces Rosetta's
allocations higher in memory.
The linker section runs from 0x100000000-0x114000000.
Rosetta's allocations are ~132MB, and should end below 0x120000000.
This is not an exact science: a non-relocatable EXE with base address
between 0x114000000-0x120000000 will fail to run. If one is discovered,
the section size will need to be changed.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
On Apple Silicon, Rosetta's shared cache starts at 0x7ffe00000000 and
the runtime is mapped below that.
Put the top-down allocation area below the runtime with plenty of room
to spare.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
I.e., the "Nth <weekday> of <month>" form. This form is much less convenient
for timezones where the DST change happens on specific dates, but some
applications distribute old versions of Mono that don't bother checking the
"wYear" fields of the SYSTEMTIME fields in the TIME_ZONE_INFORMATION structure
returned by GetTimeZoneInformation(), and instead always convert the presumed
"relative" dates to "absolute" dates. Unsurprisingly, the resulting dates are
invalid, and these applications then end up throwing
"System.NotSupportedException: Can't get timezone name." when run in such a
timezone, typically early during startup.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Giovanni Mascellani