By delegating to the ucrtbase implementation.
This allows me to get a Firefox build cross-compiled as described in [1], but with newer MSVC versions.
[1]: https://glandium.org/blog/?p=4020
Signed-off-by: Emilio Cobos Álvarez emilio@crisal.io --- .../api-ms-win-crt-private-l1-1-0.spec | 10 +++++----- dlls/ucrtbase/ucrtbase.spec | 10 +++++----- 2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec index 01f295f25f..e185c7900d 100644 --- a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec +++ b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec @@ -270,7 +270,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) ucrtbase._o__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -673,7 +673,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) ucrtbase._o__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -832,7 +832,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) ucrtbase._o__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s @@ -943,10 +943,10 @@ @ stub _o_exp2l @ stub _o_expf @ stub _o_fabs -@ stub _o_fclose +@ cdecl _o_fclose(ptr) ucrtbase._o_fclose @ stub _o_feof @ stub _o_ferror -@ stub _o_fflush +@ cdecl _o_fflush(ptr) ucrtbase._o_fflush @ stub _o_fgetc @ stub _o_fgetpos @ stub _o_fgets diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec index 1c039d0715..aac19b3ac6 100644 --- a/dlls/ucrtbase/ucrtbase.spec +++ b/dlls/ucrtbase/ucrtbase.spec @@ -934,7 +934,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) MSVCRT__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -1337,7 +1337,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) MSVCRT__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -1496,7 +1496,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) MSVCRT__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s @@ -1607,10 +1607,10 @@ @ stub _o_exp2l @ stub _o_expf @ stub _o_fabs -@ stub _o_fclose +@ cdecl _o_fclose(ptr) MSVCRT_fclose @ stub _o_feof @ stub _o_ferror -@ stub _o_fflush +@ cdecl _o_fflush(ptr) MSVCRT_fflush @ stub _o_fgetc @ stub _o_fgetpos @ stub _o_fgets
Now without conflicts with Gijs' earlier patch.
By delegating to the ucrtbase implementation.
This allows me to get a Firefox build cross-compiled as described in [1], but with newer MSVC versions.
[1]: https://glandium.org/blog/?p=4020
Signed-off-by: Emilio Cobos Álvarez emilio@crisal.io --- .../api-ms-win-crt-private-l1-1-0.spec | 6 +++--- dlls/ucrtbase/ucrtbase.spec | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec index 8d6ff5e89f..8e00661c8c 100644 --- a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec +++ b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec @@ -270,7 +270,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) ucrtbase._o__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -673,7 +673,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) ucrtbase._o__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -832,7 +832,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) ucrtbase._o__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec index d7c0700696..2d77c74274 100644 --- a/dlls/ucrtbase/ucrtbase.spec +++ b/dlls/ucrtbase/ucrtbase.spec @@ -934,7 +934,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) MSVCRT__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -1337,7 +1337,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) MSVCRT__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -1496,7 +1496,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) MSVCRT__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s
Hi Emilio,
Thanks for the work, I love your blog post. It's interesting that you wrote: """ the above two wouldn’t actually be that much of a problem if … Wine wasn’t slow. When running full fledged applications or games, it really isn’t, but there is a very noticeable overhead when running a lot of short-lived processes. That accumulates to several minutes over a full Firefox compilation. """
I was working on using Wine as a cross-compile platform a few years ago, and I encountered exactly the same problem. Sabastian wrote a patch to improve Wine performance for short-lived processes, I recommend you to give it a try, it brought significant improvement for me: https://github.com/wine-staging/wine-staging/tree/master/patches/gdi32-Lazy_...
Hopefully, someone would review the Wine-Staging patch and bring it to Wine master branch someday :) (Our Wine-Staging maintainers are doing an amazing job on upstreaming patches, thank you!)
On Sat, 16 May 2020 at 03:50, Emilio Cobos Álvarez emilio@crisal.io wrote:
By delegating to the ucrtbase implementation.
This allows me to get a Firefox build cross-compiled as described in [1], but with newer MSVC versions.
Signed-off-by: Emilio Cobos Álvarez emilio@crisal.io
.../api-ms-win-crt-private-l1-1-0.spec | 6 +++--- dlls/ucrtbase/ucrtbase.spec | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec index 8d6ff5e89f..8e00661c8c 100644 --- a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec +++ b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec @@ -270,7 +270,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) ucrtbase._o__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -673,7 +673,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) ucrtbase._o__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -832,7 +832,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) ucrtbase._o__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec index d7c0700696..2d77c74274 100644 --- a/dlls/ucrtbase/ucrtbase.spec +++ b/dlls/ucrtbase/ucrtbase.spec @@ -934,7 +934,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) MSVCRT__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -1337,7 +1337,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) MSVCRT__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -1496,7 +1496,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) MSVCRT__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s -- 2.26.2
On Sat, 16 May 2020, Qian Hong wrote:
I was working on using Wine as a cross-compile platform a few years ago, and I encountered exactly the same problem. Sabastian wrote a patch to improve Wine performance for short-lived processes, I recommend you to give it a try, it brought significant improvement for me: https://github.com/wine-staging/wine-staging/tree/master/patches/gdi32-Lazy_...
Hopefully, someone would review the Wine-Staging patch and bring it to Wine master branch someday :) (Our Wine-Staging maintainers are doing an amazing job on upstreaming patches, thank you!)
For me, for running lots of short-lived wine processes, the single biggest speedup comes from running a persistent wine server. Without any wine processes running, run "wineserver -p". That wineserver instance will then stay around (until terminated with "wineserver -k"), greatly reducing the startup time for each command.
// Martin
For me, for running lots of short-lived wine processes, the single biggest speedup comes from running a persistent wine server. Without any wine processes running, run "wineserver -p". That wineserver instance will then stay around (until terminated with "wineserver -k"), greatly reducing the startup time for each command.
That's a very good point.
(In my case, wineserver was already persistent, because all my other processes were descendants of a wineconsole.exe process)
On 5/15/20 8:14 PM, Qian Hong wrote:
Hi Emilio,
Thanks for the work, I love your blog post.
FWIW, it's not my post, it's the post of a colleague. I just tried to get my cross-compilation set up, and hit some more errors, because I was using a newer toolchain, so fixed them :)
It's interesting that you wrote: """ the above two wouldn’t actually be that much of a problem if … Wine wasn’t slow. When running full fledged applications or games, it really isn’t, but there is a very noticeable overhead when running a lot of short-lived processes. That accumulates to several minutes over a full Firefox compilation. """
I was working on using Wine as a cross-compile platform a few years ago, and I encountered exactly the same problem. Sabastian wrote a patch to improve Wine performance for short-lived processes, I recommend you to give it a try, it brought significant improvement for me: https://github.com/wine-staging/wine-staging/tree/master/patches/gdi32-Lazy_...
Hopefully, someone would review the Wine-Staging patch and bring it to Wine master branch someday :) (Our Wine-Staging maintainers are doing an amazing job on upstreaming patches, thank you!)
Ah, interesting, that's really great to know! I ended up compiling wine without freetype and X myself (mostly because I didn't need it for my purposes), so I probably didn't hit such slowness. But if that landed that would eventually save me the hassle of having my own build :)
Thanks!
-- Emilio
On Sat, 16 May 2020 at 03:50, Emilio Cobos Álvarez emilio@crisal.io wrote:
By delegating to the ucrtbase implementation.
This allows me to get a Firefox build cross-compiled as described in [1], but with newer MSVC versions.
Signed-off-by: Emilio Cobos Álvarez emilio@crisal.io
.../api-ms-win-crt-private-l1-1-0.spec | 6 +++--- dlls/ucrtbase/ucrtbase.spec | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec index 8d6ff5e89f..8e00661c8c 100644 --- a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec +++ b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec @@ -270,7 +270,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) ucrtbase._o__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -673,7 +673,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) ucrtbase._o__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -832,7 +832,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) ucrtbase._o__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec index d7c0700696..2d77c74274 100644 --- a/dlls/ucrtbase/ucrtbase.spec +++ b/dlls/ucrtbase/ucrtbase.spec @@ -934,7 +934,7 @@ @ stub _o__fgetwchar @ stub _o__filelength @ stub _o__filelengthi64 -@ stub _o__fileno +@ cdecl _o__fileno(ptr) MSVCRT__fileno @ stub _o__findclose @ stub _o__findfirst32 @ stub _o__findfirst32i64 @@ -1337,7 +1337,7 @@ @ stub _o__set_thread_local_invalid_parameter_handler @ stub _o__seterrormode @ stub _o__setmbcp -@ stub _o__setmode +@ cdecl _o__setmode(long long) MSVCRT__setmode @ stub _o__setsystime @ stub _o__sleep @ stub _o__sopen @@ -1496,7 +1496,7 @@ @ stub _o__wfindnext32i64 @ stub _o__wfindnext64 @ stub _o__wfindnext64i32 -@ stub _o__wfopen +@ cdecl _o__wfopen(wstr wstr) MSVCRT__wfopen @ stub _o__wfopen_s @ stub _o__wfreopen @ stub _o__wfreopen_s -- 2.26.2
Signed-off-by: Piotr Caban piotr@codeweavers.com