FS segment and C compiler that will do it..?

[jamie]

I have a DLL I built using Builder C++, it uses the FS segment to share memory between processes.

Its a 32 bit one and it works, does such a thing work in 64 bit DLL land and if so what compiler is out there that can create it ?

[PascalDragon]

I wonder what exactly C++ Builder might be doing with the FS segment, cause on Windows that holds the current thread's environment block (TEB). It could be that a 64-bit variant of the C++ Builder would use the GS segment as that is what Windows uses for the TEB there.
How do you access the memory that is shared? That might give some insight into what exactly C++ Builder might be doing there with the segment...

[jamie]

its actually a MS VC++ switch that builder happens to support.

 Let me ding up the source code of a test DLL I did.

Code: C  [Select][+][-]

1. #pragama datas_seg ("Shared")
2. int test;
3. #pragama data_seg();
4.  

I have a reader and writer exported functions, the actual DLL in use has a lot more than that obviously but that is what I do and in ASM land it uses the FS segment to store data in.

[440bx]

its actually a MS VC++ switch

What switch is that ?

[440bx]

I have a DLL I built using Builder C++, it uses the FS segment to share memory between processes.

First, I fully share PascalDragon's feeling about the compiler using FS to access data.  That is a completely unnecessary invitation to complicate the code and open the door to some subtle and very nasty problems, not to mention that is very inefficient.

Code: C  [Select][+][-]

1. #pragama datas_seg ("Shared")
2. int test;
3. #pragama data_seg();
4.  

I have a reader and writer exported functions, the actual DLL in use has a lot more than that obviously but that is what I do and in ASM land it uses the FS segment to store data in.  I find it quite surprising that C++ Builder uses a segment register that is essentially, though not formally, reserved for Windows.

I don't think of pragmas as compiler switches but leaving that aside, creating shared data sections in a dll invites problems because a user dll has no way to ensure it is always loaded at the same address and the successful sharing of a data segment created that way depends on that (speculation: maybe that's the reason it's using FS instead of DS.)  That mechanism is definitely safer when used in an exe because, even if the exe is not loaded at its preferred address, all subsequent instances of the exe will be loaded at the same address.

I strongly recommend that instead of using a shared data section, simply use a memory mapping.  That way it doesn't matter at what address the dll is loaded, everything will work because each process will have its own correct address for the mapping.  That applies to the C code and, once that's done, the port to FPC should be fairly straightforward.  Also, if you do it that way, you may not even need a dll.

TTBOMK, there is no facility in FPC to define new sections and control which section the data definitions go into.

HTH.

[jamie]

You can't argue with success...

Its been in use for some time now with in an automation environment connecting multiple stances
of apps all talking between each other using that method.

 Of course the PC's that are running those are old XP's, one being a W2k but it seems to work.
 
 Have not tried it on anything newer but if you look around it still seems to be a standard, although it seems different compilers use slightly different verbiage for it.

  I have two ways to interactive with it..

  1. block transfer into process space (current process)/

  2. Functions that write/read and test for new data from the block.

When I move a block out of the shared segment I set a bit in a 32 bit field indicating I received it.
of course the bit position is specific to the current instance that is accessing it. This operation imforms
the sender that it was complete.
 
 When all clients have process their data, all bits are cleared and the sender is free to send another block..
  All devices can talk to each other, its a wonderful thing and I have not had any crashes that were rated to that operation..

[440bx]

You can't argue with success...

I don't argue with "success" but, if you want to replicate that "success" using FPC, you'll likely have to use a memory mapping because, AFAIK, there is no way in FPC to declare new sections and tell the compiler which data goes into which section.

[marcov]

The functionality might be related to Fortran's common block. IOW accessing it from C(++).

[PascalDragon]

its actually a MS VC++ switch that builder happens to support.

 Let me ding up the source code of a test DLL I did.

Code: C  [Select][+][-]

1. #pragama datas_seg ("Shared")
2. int test;
3. #pragama data_seg();
4.  

I have a reader and writer exported functions, the actual DLL in use has a lot more than that obviously but that is what I do and in ASM land it uses the FS segment to store data in.

I still wonder what you mean with the FS segment. After all that's just a plain section from the view of the C++ compiler/linker and thus nothing special should be required, cause the OS simply maps it into all processes with that DLL. Do you have an example how the assembly code that uses the FS segment looks like?

Please note however that shared data sections are considered a security hole. It is suggested to use memory mapped files instead.