On 5/4/20 5:49 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
@@ -1533,6 +1541,7 @@ void server_init_process_done(void) signal_init_process();
/* Signal the parent process to continue */
- pthread_sigmask( SIG_BLOCK, &server_block_set, &old_set ); SERVER_START_REQ( init_process_done ) { req->module = wine_server_client_ptr( peb->ImageBaseAddress );
@@ -1541,10 +1550,22 @@ void server_init_process_done(void) #endif req->entry = wine_server_client_ptr( entry ); req->gui = (nt->OptionalHeader.Subsystem != IMAGE_SUBSYSTEM_WINDOWS_CUI);
status = wine_server_call( req );
wine_server_add_data( req, user_shared_data, sizeof(*user_shared_data) );status = server_call_unlocked( req ); suspend = reply->suspend; } SERVER_END_REQ;- if (!status) usd_fd = receive_fd( &usd_handle );
- pthread_sigmask( SIG_SETMASK, &old_set, NULL );
It should be possible to use standard file mapping functions (NtOpenSection, NtMapViewOfSection etc.) instead of adding custom handling to the init_process_done request.
Well, there was actually an issue with the service implementation because it used standard section function to map the USD. The handle was allocated early and under some circumstances could collide with a console handle copied from a parent process. The details are a bit convoluted but it's also the reason behind Paul's recent mapping patches.
With these patches, NtWriteFile should not be able to write to the section handle anymore, but the idea was also that maybe the USD should not use standard mapping functions to avoid such issues. Also, on Windows NtQueryVirtualMemory returns MEM_PRIVATE for the USD, where it would return MEM_MAPPED if a section is used (although unlikely that any application cares).