3 ms·

Global variables in Win32 dynamic-link libraries (DLLs) are visible across processes, so it is important that developers are careful that these globals do not c

Global variables in Win32 dynamic-link libraries (DLLs) are visible across processes, so it is important that developers are careful that these globals do not conflict with any variables within the Unix shared libraries. Does anyone have any more information on this? This is presented/worded as the nature of DLL globals being shared across processes is why they they have to ensure they don't conflict, but this seems somewhat obvious if the globals are not namespaced within the library in some sense. The more interesting question is how the DLLs' data was visible across processes such that this mattered at all, since this kind of sharing isn't available in the UNIX process or shared object model at all by default. How does WINE account for this?

ctstover 11y ago
Shared libraries are mmap()ed share private. Imagine that one added library initialization code (load time) that mmap()ed a section as shared public for some values. That's the 'doz model. The win16 model is much more fascinating though.
kazinator 11y ago
Global variables in DLL's are definitely not visible across processes. Each process which attaches a DLL has its own instance, in its own protected address space. If the claim were true at face value, it would mean that if two programs use, say, MSVCRT.DLL (Microsoft's Visual C run-time), if one program reads from stdin or writes to stdout, it interferes with the other.
- ctstover 11y ago
  Correct, normal globals no. There is a way to make some special values have this behavior though. It's been a long time, but I think the reason was to have some analog to the win16 behavior. In that shared-everything universe, there were these IPC through dll patterns.
  - kazinator 11y ago
    Win32 has an API for shared memory that is straightforward to use. You use CreateFileMapping with an INVALID_HANDLE for the file to create a mapping which is like MAP_ANONYMOUS in mmap (not backed by a file). It is not literally anonymous because you can give the mapping a name (similar to, say, a POSIX semaphore name in sem_open). Other processes can attach to the mapping using the name. To actually instantiate the mapping in the address space, you use the MapViewOfFile function. MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... Been years since I used this stuff.
- to3m 11y ago
  You can set the shared flag on the section. See, e.g., http://www.codeproject.com/Articles/240/How-to-share-a-data-segment-in-a-DLL http://www.codeproject.com/Articles/240/How-to-share-a-data-..., https://msdn.microsoft.com/en-us/library/sf9b18xk.aspx https://msdn.microsoft.com/en-us/library/sf9b18xk.aspx
pjc50 11y ago
I think this is a garbled version of symbol name visibility; you don't want to have a variable with the same name as one in the UNIX libraries.
- thwarted 11y ago
  Ah, yes. Replacing Global variables in Win32 dynamic-link libraries (DLLs) are visible across processes with Global variables in Win32 dynamic-link libraries (DLLs) are visible across loaded libraries (or however it might be labeled) makes more sense than the word "processes".

ctstover 11y ago

Shared libraries are mmap()ed share private. Imagine that one added library initialization code (load time) that mmap()ed a section as shared public for some values. That's the 'doz model. The win16 model is much more fascinating though.

kazinator 11y ago

Global variables in DLL's are definitely not visible across processes. Each process which attaches a DLL has its own instance, in its own protected address space. If the claim were true at face value, it would mean that if two programs use, say, MSVCRT.DLL (Microsoft's Visual C run-time), if one program reads from stdin or writes to stdout, it interferes with the other.

ctstover 11y ago
Correct, normal globals no. There is a way to make some special values have this behavior though. It's been a long time, but I think the reason was to have some analog to the win16 behavior. In that shared-everything universe, there were these IPC through dll patterns.
- kazinator 11y ago
  Win32 has an API for shared memory that is straightforward to use. You use CreateFileMapping with an INVALID_HANDLE for the file to create a mapping which is like MAP_ANONYMOUS in mmap (not backed by a file). It is not literally anonymous because you can give the mapping a name (similar to, say, a POSIX semaphore name in sem_open). Other processes can attach to the mapping using the name. To actually instantiate the mapping in the address space, you use the MapViewOfFile function. MSDN: https://msdn.microsoft.com/en-us/library/windows/desktop/aa366551%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... Been years since I used this stuff.
to3m 11y ago
You can set the shared flag on the section. See, e.g., http://www.codeproject.com/Articles/240/How-to-share-a-data-segment-in-a-DLL http://www.codeproject.com/Articles/240/How-to-share-a-data-..., https://msdn.microsoft.com/en-us/library/sf9b18xk.aspx https://msdn.microsoft.com/en-us/library/sf9b18xk.aspx

pjc50 11y ago

I think this is a garbled version of symbol name visibility; you don't want to have a variable with the same name as one in the UNIX libraries.

thwarted 11y ago
Ah, yes. Replacing Global variables in Win32 dynamic-link libraries (DLLs) are visible across processes with Global variables in Win32 dynamic-link libraries (DLLs) are visible across loaded libraries (or however it might be labeled) makes more sense than the word "processes".