[Autogenerated] in order to demonstrate data sharing, let's write some code.
I've created a new project just like we did in previous cases just a
simple console application called that day to share and added the
classic includes from windows dot H and S t d i O.
So what I want to do here is to grab some global variable and manipulated
using simple code and see what that looks like in tools such as VMs in order
to see copy and right and that kind of behavior,
we actually have to put that X that global variable
in its own data section in the P.
And the reason is that if we don't do that,
it's going to join the other global variables that are provided by the C.
Runtime and by the time our main function is going to execute those
variables are going to be changed and modified by the C.
Runtime so any copy and write flag is going to be long gone.
So in order to do that in order to create a different data section in the P I'm
going to use a pragmatic called data set that is supported by Visual Studio I
have to give the section and name and traditional intersection names start with
the dot although it's not mandatory, I'm going to call that dot pavel,
I mean why not?
And x is going to be the only thing inside that section,
I'm going to close off that section by using another dataset Prague MMA but this
time an empty one and then I have to provide the linker some details as to what
that section should have in terms of properties.
So I'm going to use another prag mccall comment which allows me to
add settings to the compiler or linker in this case the link is the
one that's dealing with building the actual executable so it has to
know about these things.
So I'm going to use this section switch and say the section called dot pavel.
Please make it a read write section.
Like normal data should be to have private data for
every process accessing that X.
Global variable in my main function.
The first thing I'm going to do is to display the process I.
D.
So we have some bearing when we try to look up this process in other
tools and also let's display the address of X.
See what that lands in terms of the address space in the process.
So we'll be able to figure out where it is by looking at tools such as VM app.
I'm going to go with calling gate current process I.
D.
To get the current processes and then the address of X,
whatever that happens to be.
And then what I'm going to do is have a loop here.
In fact an infinite loop that's going to display the
value of X in a very simple manner.
And then I'm going to increment X and do a sleep.
I'm going to do a sleep of two seconds here to update the value of X
every two seconds before we dive into the loop.
I'd like to also allow the user to examine the state of the process.
And I'm just going to add get s here to just grab some enter keystroke
before we actually start manipulating that X value.
Because once we start manipulating it,
we know that any kind of copying right should be going away.
So I want to see these changes happening.
So let's start by building that and running it.
So I'm going to press control F five to run one instance.
You can see that we have a process A B and this is where X happens to be.
So let's go ahead and open VM app and locate this process
that's going to be data share here goes.
And you can see the address space of data shares will be used right now.
And because the global variable is well,
a global variability is part of the image.
So it's part of the p if we examine the address, the address is seven.
Ff is a very long address but really only the last
pieces are actually interesting.
So you can see it starts with B here at some point.
So it is part of the executable and that makes sense.
We expect that to be part of the executable.
You can see the dot pavel section here, the section size is four kilobytes,
nothing can be smaller than that.
It's at least size of a page, even though we only have a single integer.
They're still the there's just no way around it in
order to have a separate protection, separate attributes for memory.
It has to be on a page granularity.
So we have four kilobytes here.
In fact, you can see the copy on right here right here working as we expect.
So once I press enter and now the X Viber is going to start to change.
If I refresh the view in VM app,
you'll notice that the copyright is gone and now it's a normal
read write that is used here for that memory because now we
have got ourselves a private copy.
We don't see here the physical addresses but we do have our own copy.
We'll see physical addresses in the next module going back to visual studio,
let's run another instance of the same thing and you can see that the
addresses for this one and the previous one are the same.
So they have the same addresses in mutual memory.
But it doesn't mean that they're looking at the same
memory from a physical perspective.
So if you go ahead and launch another VM app and look at the other data share.
Let me just make sure we're looking at the correct one that's
going to be 13 7 40 that's exactly this one.
And again, we hone in on the images here and find the same the same chunk.
We can see the segment here is also protected by copying, right?
Because we're looking at that shared data which currently is not really shared.
It's just being used by that single process but it's still just there and again,
if you make a change by pressing enter, starting to make changes to the data,
then it will change.
I'm going to refresh again and open that up and it's back to being read rights.
No longer protected by copy on write.
And you notice that every process has their own values of X.
It's a different kind of acts.
It's not the same Acts,
although it resides in the same futural address in both processes being
mapped to different locations in physical memory.
And so it's not the same exit is not shared.
And this is the normal way data behaves every process
has its own data and by the way,
the same idea works with DLS not just in executable So let's
close that up and see how we can share that data.
So, to do the actual opposite and share that data between processes.
The only thing we have to change really is to add that S here.
So that?
S means shared.
So this section should now be protected by normal read write without copying.
Right?
That's what we expect to happen.
So let's see if that works as as expected.
So here's our first process.
Let's go back to launch a VM map instance,
here's data share and again we expect that to be in
essentially the same location.
Different address perhaps, but same idea.
And you notice the shared here,
the shared section is is protected by read write only,
there's no copy and right.
In fact we can see the details that VMs is smart enough to say
that this is not just normal read write,
it is actually shared, what does that mean?
It means that if I continue now running and having those
values changed by this particular process,
if I launch an additional process or process that are looking at the same act,
they will see the exact same acts.
So it will actually not start with zero necessarily.
It might be starting with something different.
So if I go ahead and uh and run another instance And we start looking
at it notice the value starts with 14 and it jumps by two every time
because the other process is implementing it by one and this one is
implementing by one as well.
So we have each one implementing in its own time and luckily
we don't have synchronization issues here,
but technically we should be synchronizing and protecting
this data from concurrent access but we should be fairly
lucky not to fall onto that.
And we should be lucky because the sleep is fairly long one.
In any case we can see that the X is really the same one so
it's mapped to the same physical memory,
although we can't prove that just yet.
We see the results and we see the virtual addresses in the VM app instances.