And load system fonts outside of the global font mutex. We now only use
the mutex to protect the registry fonts initialization.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes an issue when, if an external font path was modified in the
Windows key, it was then not considered as external anymore, but still
present in the external key, and then dropped from both on update.
This now forcefully updates the font path in both keys if needed.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and EndOfStream(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and EndOfStream(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and EndOfStream(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We don't grab stream_cs to change any variables checked here, except to reset
flush_event, and that cannot result in a deadlock.
The only possible deadlocks here are:
(1) between this function and Receive(), which is correct, as the two
should presumably be serialized;
(2) between this function and EndFlush(); however, in that case we expect
BeginFlush() first, which will unblock the streaming thread.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Have the winebuild -spec.o include an undefined .globl referencing
symbols we know the winecrt0 entry point will eventually reference,
so ld knows about that need while scanning library archives.
Signed-off-by: Kevin Puetz <PuetzKevinA@JohnDeere.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Override --entry in winegcc only when it applies to any compiler
(e.g. kernel drivers or msvcrt) but leave spec details to winebuild.
Forward -municode so winebuild will know which to use.
Signed-off-by: Kevin Puetz <PuetzKevinA@JohnDeere.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Checking for the _rtld_version_laddr_offset symbol only works when
header and library versions match. Checking for the offset of l_addr
instead lets us use the older header with the new library too.
Signed-off-by: Damjan Jovanovic <damjan.jov@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It could sometimes be NULL, such as win32k.sys on Win <= 7.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Service display names are often translated.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>