Introduction to Delphi Chapter 3 Win32's Time and Space View

Chapter 3 Time and Space View of Win32

My old father looked at the little grandson playing with toys on the ground and said to me, "This child is just like you in the hour. You just like to take things apart and read it before you stop ". When I was a child, I often used toy cars, small alarm clocks, music boxes, and so on. I was often scolded by my mother.

The first time I understood the basic principle of a computer, it was related to the music box I split. It was a comic book in high school. An old white-bearded man was explaining the theory of a smart machine. An uncle with eight characters was talking about computers and music boxes. They said that the computer's central processor is the row of music reeds used for pronunciation in the music box, and the computer program is the convex dot on the small cylinder in the music box, the rotation of the small cylinder is equivalent to the natural movement of the instruction pointer of the central processor, while the Convex Point of the music on the small cylinder controls the vibration of the music Reed. The pronunciation is equivalent to the instruction of the central processor execution program. The music box has a wonderful melody. It is played by the music spectrum that the craftsman has carved on the small cylinder. The computer completes complicated processing and is implemented according to the program prepared by the programmer. After I went to college, I realized that the white-bearded old man was Turing, a science master. His finite automatic machine theory promoted the development of the information revolution, and Feng, the uncle with eight characters left, was the father of the computer. noiman, Feng's computer architecture is still the main computer system. The music box is not split in white, so the mother can be patient.

With a deep understanding, you can create a profound and concise one. In this chapter, we will discuss the basic concepts related to programming in Windows 32-bit operating systems and establish a correct time-space view in Win32. I hope that after reading this chapter, we can have a deeper understanding of programs, processes, and threads, and understand the principles of execution files, dynamic connection libraries, and runtime packages, see the truth about global data, local data, and parameters in the memory.

Section 1 process understanding

For historical reasons, Windows originated from Dos. In the DOS era, we have always had the concept of a program, but not a process. At that time, only the operating system's regular army, such as UNIX and VMS, had the concept of a process, and multi-process would mean minicomputers, terminals, and multiple users, as well as money. Most of my time I can only use relatively low-cost computers and DOS systems. I started to access processes and minicomputers only when I was learning the operating system course.

After Windows 3. X, Microsoft was stuck on the operating system of the graphic interface. At this moment, I began to formally face the concept of multi-task and process. In the past, in DOS, only one program can be executed at a time, while in windows, multiple programs can be executed at the same time, which is multi-task. When running a program in DOS, the same program cannot be executed. In Windows, more than two copies of the same program can be running at the same time, A copy of each running program is a process. More specifically, a task is generated when any program runs at a time, and each task is a process.

When we put the program and process together, we can think that the word "program" is a static thing, A typical program is static code and data composed of an EXE file or an EXE file plus several DLL files. A process is a program running. It is the code that runs dynamically in the memory and the data that changes dynamically. When a static program is required to run, the operating system will provide a certain amount of memory space for this operation, and the static program code and data will be transferred to the memory space, after the code and data of the program are relocated and mapped, the program is executed in the space, which produces a dynamic process.

Two copies of the same program running at the same time mean that there are two process spaces in the system memory, but their program functions are the same, but they are in different dynamic changing states.

In terms of the time when a process runs, each process is executed simultaneously. The terminology is parallel execution or concurrent execution. However, this is what the operating system gives us. In fact, each process is executed in a time-based manner, that is, each process takes the CPU time to execute the program commands of the Process in turn. For a CPU, only one process instruction is executed at a time. The operating system is the behind-the-scenes operator of the scheduling process. It constantly saves and switches the current status of each process running in the CPU, this makes every scheduled process think that it is running completely and continuously. Because the time-based scheduling of processes is very fast, we feel that the processes are running at the same time. In fact, in a real sense, running at the same time is only available in a multi-CPU hardware environment. Later on thread 1, we will find that it is the thread that actually drives the process, and the process is more important to provide the process space.

In terms of the space occupied by a process, the process space is relatively independent, and each process runs in its own independent space. A program includes both the code space and the data space. Both the code and data occupy the process space. Windows allocates the actual memory for the data space required by each process, and generally shares the code space to map a piece of code of a program to multiple processes of the program. This means that if a program has KB of code and requires KB of data space, that is, a total of KB of process space, the operating system will allocate KB of process space when the program is run for the first time, when the second process of the program is running, the operating system only allocates KB of data space, while the code space shares the space of the previous process.

The above is the basic concept of time and space for processes in the Windows operating system. In fact, the 16-bit and 32-bit Windows operating systems are very different in terms of process time and space.

In terms of time, process management for a 16-bit Windows operating system, such as Windows 3. X, is very simple. It is actually a multi-task management operating system. Moreover, the operating system schedules tasks passively. If a task does not discard message processing, the operating system must wait. Because of the defects in process management in the 16-bit Windows system, a process fully occupies CPU resources during running. In those days, Microsoft praised the developers who developed Windows applications as wide-minded programmers for being able to schedule other tasks for 16-bit windows, so that they are willing to write a few more lines of code to the operating system. On the contrary, Win32 operating systems, such as Windows 95 and NT, are capable of real multi-process and multi-task operating systems. The process in Win32 is fully scheduled by the operating system. Once the time slice of the process stops, the operating system will switch to the next process regardless of whether the process is still processing data. Strictly speaking, a 16-bit Windows operating system cannot be a complete operating system, while a 32-bit Win32 operating system is a true operating system. Of course, Microsoft does not say that Win32 makes up for 16-bit windows defects, but claims that Win32 has implemented an advanced technology called "preemptive multitasking", which is a commercial means.

In terms of space, although the process space in a 16-bit Windows operating system is relatively independent, it is easy for processes to access each other's data space. Because these processes actually have different data segments in the same physical space, and improper address operations can easily cause incorrect Space read/write and crash the operating system. However, in the Win32 operating system, the process space is completely independent. Win32 provides a virtual address space that can reach 4G and is a continuous address space for each process. The so-called continuous address space means that each process has an address space from $00000000 to $ ffffffff, rather than a 16-bit windows segmented space. In Win32, you do not have to worry that your read/write operations will inadvertently affect the data in other process spaces, or worry that other processes will harass your work. At the same time, Win32 provides a continuous 4G virtual space for your process. It is the physical memory mapped to you by the operating system with hardware support. Although you have such a broad virtual space, however, the system will never waste one byte of physical memory.

Section 2 process space

When we use Delphi to write Win32 applications, we seldom care about the internal world of processes during runtime. Win32 provides 4G continuous virtual process space for our processes. At present, the largest application in the world may only use part of the space. It seems that the process space is infinite, but the 4G process space is virtual, and the actual memory of your machine may be far from this. Although the process has such a broad space, some complex algorithm programs will still be unable to run due to stack overflow, especially programs that contain a large number of recursive algorithms.

Therefore, an in-depth understanding of the structure of the 4G process space and the relationship between the 4G process space and the physical memory will help us better understand the spatial and temporal worlds of Win32, in this way, we can use the correct world outlook and methodology to solve various problems in actual development work.

Next, we will learn about the internal world of Win32 process space through a simple experiment. This may require some knowledge about the cup register and assembly language, but I try to explain it in a simple language.

When you start Delphi, a project of project1 is automatically generated, so we can start it. Set a breakpoint at any location of the original project 1.dpr. For example, set a breakpoint at the beginning. Then run the program. The program stops automatically when it reaches the breakpoint. Then, we can open the CPU window in the debugging tool to observe the internal structure of the process space. The current Instruction Pointer register EIP is stopped at $0043e4b8. The maximum two hexadecimal numbers of the address where the instruction is located are all zero, it can be seen that the current program is at the very bottom of the 4G process space, which occupies a considerable amount of address space from $00000000 to $ ffffffff.

In the command box in the CPU window, you can view the content in the process space up. When you view the content of a space less than $00400000, you will find that the content less than $00400000 contains a string of question marks "???", This is because the address space has not been mapped to the actual physical space. If you check the hexadecimal value of the global variable hinstance, you will find that it is also $00400000. Although hinstance reflects the handle of the Process instance, it is the starting address value when the program is loaded into the memory, as is the case in 16-bit windows. Therefore, we can consider that the process program is loaded starting from $00400000, that is, the space loaded by the program starting from the space after 4 m in the 4G virtual space.

From $00400000 to $0044d000, it mainly refers to the address space of program code and global data. In the stack box in the CPU window, you can view the address of the current stack. Similarly, you will find that the address space of the current stack is from $0067b000 to $00680000, And the length is $5000. In fact, the minimum stack size of a process is $5000, which is obtained based on the min stack size value set on the linker page of the project during compilation of the Delphi Program, plus $1000. The stack increases from the high-end address to the bottom. When the running stack is insufficient, the system automatically increases the size of the stack space to the local address, this process maps more actual memory to the process space. When compiling a Delphi program, you can set the value of Max stack size on the linker page in the project to control the maximum stack space that can be increased. In particular, the value of Max stack size must be reasonably set in programs that contain deep subroutine call relationships or use recursive algorithms. Because calling subprograms consumes stack space, and when the stack is exhausted, the system will throw the "stack overflow" error.

It seems that the process space after the stack space should be free space. In fact, the 2 GB space after $80000000 is the space used by the system. It seems that a process can only have 2 GB of space. In fact, the space that a process can really own is not enough, because the 4 m space from $00000000 to $00400000 is also restricted.

But in any case, our process can still use a very broad address. Especially after the stack space to $80000000, it is the main battlefield of the process space. The memory space allocated by the process from the system will be mapped to this space, the dynamic connection library loaded by the process will be mapped to this space, and the thread stack space of the new thread will also be mapped to this space, almost all operations involving memory allocation will be mapped to this space. Note that the ing mentioned here means that the actual memory corresponds to this virtual space, and the process space not mapped to the actual memory cannot be used, it is like the string "??? ".

Section 3 EXE and DLL

We have a certain understanding of the process and process space. Next we will discuss the differences between the execution file EXE and the dynamic Connection Library DLL, their relationship with the process space.

A typical Windows application is generally composed of an EXE file and several DLL files. The Windows operating system itself is such a structure, which is well-known. But do you really understand EXE and DLL? If you are sure you are familiar with the meaning of EXE and DLL, skip this section. If you are confused about EXE and DLL, please listen to me carefully.

A correct EXE file is a program that can be run directly. In Windows, a process space is created for the program. The program runs in the process space. A process space is the basic environment for applications to run. Without a process space, you cannot run the program.

In the EXE file, the Data Reference relationship and call relationship of the program are expressed by the relative address. When the program is loaded to the absolute address in the process space, the operating system needs to adjust the reference and call relationship of the relative address to the reference and call relationship of the absolute address. This process is called "relocation ". The relocation item is stored in the header information of the EXE file.

The running of a program requires a stack, because the stack is the basic facility required for Process calling and the survival of local data and process parameters in the process. The operating system will determine the address location and size of the stack space based on the stack size value recorded in the EXE file header, and first map the part of the memory of the minimum stack space.

If an EXE program has a fixed reference relationship with some DLL programs, the operating system will transfer the relevant DLL program to the current process space. The reference or call relationship between EXE, DLL, and DLL is described by the import table and the import table. They are also stored in the header information of the EXE or DLL file. The operating system connects the reference and call between program modules based on the Introduction table and the Introduction table information. This process is called "dynamic connection ".

A dll file is only a part of the program. It is not a complete executable program. Therefore, the DLL cannot be run independently, and Windows does not create a process space for the DLL module. A dll module must be loaded into the process space of an EXE program before it can function.

A dll file also contains relocation information. When the operating system loads the DLL into the process space, it also needs to relocate the DLL module. If the loaded dll has a fixed reference relationship with other DLL files, the referenced DLL module will be loaded at the same time when the DLL module is loaded, and the dynamic connection process will be completed.

The stack size recorded in a DLL file is always zero, because the DLL only serves the process. When calling the DLL module, the process stack is used. For a single-threaded application, a process has only one stack, that is, the stack used by the main thread of the process. For multi-threaded applications, each running thread has its own stack. In the case of multiple threads, if the DLL module is called in that thread, the DLL uses the stack of the thread. However, all of this is done in the same process space.

If you use the loadlibrary function of Windows API to dynamically load a DLL file, the returned module handle value is the address value that points to the DLL loaded into the process space. If you call loadlibrary repeatedly to load the same DLL, you will find that the module handle values returned by them are the same. Windows only increases the reference count of this DLL. In fact, DLL is shared between different Windows processes, but different mappings are available in different process spaces.

The file extension of a DLL module is not always *. dll. The BPL package file like Delphi, The ocx file of ActiveX object, and the DRV and VxD files of the device driver are all DLL files. Of course, the file extension of an EXE module is not necessarily *. EXE, only, not *. the executable file of EXE cannot be executed by double-clicking the mouse. You Need To Write Program Statements to call and run it.

Dll can only be run in the process space. This is a basic principle, please remember.

But sometimes, a DLL in Windows is already a complete program, and there is no running process space. In this case, Windows uses the rundll32 command to run the DLL program. Rundll32 is a simple EXE file, which is located in the Windows directory. It only provides runnable process space for the DLL program.

In addition, in the development of multi-layer architecture applications, commercial objects in the DLL module are also the process spaces to be run. If your client application and DLL Application Server are on the same machine, the commercial objects in the DLL Application Server run directly in the process space of your client program, this is the in-process mode. For the out-of-process object calling mode, the application server is generally required to be an executable EXE file.

Of course, if the application server and the client program are on different machines, the application server must have a process space to work. For example, you cannot directly connect to the DLL application server on the remote machine through DCOM, because the DLL has no executable process space. However, you can connect to the DLL application server on the remote machine through the socket, because the DLL is actually in scktsrvr. and scktsrvr. EXE is a service program that listens to socket connections.

In the distributed multi-tier Application Development of the MTS mode, all commercial objects must exist in the application server of the DLL file. These DLL commercial objects exist in the MTS process space. Therefore, MTs can schedule and manage these commercial objects in its own process space, to complete the powerful functions of objects, such as transaction control, object buffering, and connection sharing.

Section 4 Where are data and code?

Where are data and code?

As the saying goes, when people are thirty years old, they will not think about "Why do people want to live ?" These problems. But after more than a decade of programming, I still like to think, "Why do I want to program ?" "Why is the program running ?" "Is the program running or my thoughts running ?"...... Although I was in my first thirty years. This kind of thinking is always fruitless, but it's just the best effort to waste your life in your career. This kind of hard work also has some insights, and often makes my soul more integrated into the world of programs. The program has my soul, and the running personality also seems to carry my style. I have benefited, and I have programs.

Today, I want to share with you the program data and code issues. This topic is inseparable from the concept of process space, because all the code and data of the program exist in the process space. So where are the data and code in the process space?

First, let's see what areas are in the process space.

A process space has four programming-related areas: static data zone, dynamic data zone, stack zone, and code zone. There are several memory areas in the process space, which dynamically change as the program runs. A new area will be generated in a moment, and some areas will disappear in a moment. If you think of the process space as a sea, these memory areas are the islands in the sea. As the tide changes, the islands become invisible. Each island relies on the actual memory mapped by the operating system. Blank areas that are not mapped to the actual memory are the vast oceans, and programs will drown when accessing these blank areas.

The four memory regions have their respective functions. The static data area is the place where global variables, constants, and thread variables you define survive. The Dynamic Data zone is where you dynamically allocate data space and dynamically create objects to survive. The stack provides a space for storing the return address for a subroutine call and temporary space for local variables, parameter variables, and return values. The Code area is the area where the program instruction is stored, and the CPU extracts the instruction here to execute the program.

The generation and disappearance of these memory areas are related to the loading and unloading of program modules and the creation and extinction of threads.

Here, the module refers to the physical file module of a Windows application, that is, the module concept represented by the hmodule handle in windows. Typically, an EXE file is a module file, and various DLL files are also a module File. An application generally consists of an EXE file and several types of DLL files. This type of file is called a PE file (portable Executable File) in windows ). It contains a PE information header, which contains important information required to load the program module.

When a physical file module is loaded into a process space, the Windows operating system will arrange the location and size of the module data and code in the process space according to the PE Header information of the module. Such loading includes executing and loading the EXE program, loading the DLL in time when the EXE program is started, and dynamically loading the DLL program later.

When the module is loaded into the process space, it will generate several static data regions required by the module, and several command code regions of the module will also be generated. If the module dynamically allocates and releases memory or creates and eliminates objects during running, the corresponding real estate and dynamic data areas are released.

You can think that the Code area of the module is fixed, because the general code does not change during the execution process (unless you write a code with the variant function ......), This does not affect the understanding of the program execution process. However, the module code area may also change frequently, which is behind windows.

Imagine loading a program module with several megabytes or dozens of megabytes of code into the process space. Will the startup speed of the program be slow? Will this generate a huge code area in the process space? It is possible, but windows will try not to let this happen. When the CPU uses commands in a code area, it transfers the code area from the disk file to the process space and executes the command. At the same time, if some code blocks are not executed for a long time, it will release the memory space occupied by these code blocks. When the released code is used by the CPU again, the code will be loaded again (of course, the loading location may be different ). Therefore, even if a large module File is loaded and run, the speed will not be significantly reduced, and the space will not increase significantly.

Imagine if a module File is loaded and the file is taken away, Can Windows correctly load the code used by the CPU from the disappearing file. Of course not! Therefore, when a module File is loaded in windows, the file is forcibly locked. You cannot modify or delete the file. Unless the module on the floppy disk is loaded, you must forcibly remove the floppy disk.

Similarly, the creation and release of threads will also cause changes in the memory area. When a thread is created, Windows opens two memory areas for the thread in the process space. One is the Global static data area relative to the thread, and the other is the stack area required for thread running. Among them, the stack area is the basic facility required for thread operation, and is closely related to the thread. A thread must have a stack, and a stack must correspond to a thread. After a thread is released, the related static data zone and stack disappear.

The static data zone of the module is generally where the global variables and constants you define are located. The access addresses of these data elements are relative to those of the module. That is to say, the data element identification method and structure relationship are relative to the program of this module. Other module programs outside the module cannot directly identify and interpret the data elements defined in this module, unless the addresses of these data elements are transferred from the module to the programs of other modules. For example, let's look at the two module programs below:

Program exemodule;

Function thevariable: pointer; External 'dllmodule. dll ';

Begin

// Avariable: = 56789; // the data element in another module cannot be directly identified or accessed.

INTEGER (thevariable ^): = 56789; // you can only indirectly access its data elements by obtaining an address from another module.

End.

This program will generate the exemodule. EXE module file after compilation. Of course, it requires dllmodule. DLL to start.

Library dllmodule;

VaR

Avariable: integer;

Function thevariable: pointer;

Begin

Result: = @ avariable;

End;

Exports thevariable;

Begin

Avariable: = 12345;

End.

Because the second program indicates that it is a library program, the dllmodule. dll module file will be generated after compilation. Although a global variable avariable is defined in the dllmodule, the program of the exemodule cannot identify and find the variable directly. The avariable variable can be indirectly accessed only after the address pointer of avariable is obtained by calling the thevariable function of the dllmodule.

Some friends said that if avariable is put into an independent Pascal unit file and uses is included in the main program of the two modules, can they access each other? Let's take a look at the following program files.

This is the varunit. Pas unit file:

Unit varunit;

Interface

VaR

Avariable: integer;

Implementation

End.

This is the exemodule. DPR file, which will generate the exemodule. EXE file:

Program exemodule;

Uses

Varunit;

Begin

Avariable: = 56789;

End.

This is the dllmodule. DPR file, which will generate the dllmodule. dll file:

Library dllmodule;

Uses

Varunit;

Begin

Avariable: = 12345;

End.

Both modules reference varunit units. If both modules are in the same process space, are the avariable variables accessed in the exemodule and the avariable variables accessed in the dllmodule the same?

The answer is no!

Originally, the avariable variable accessed in the exemodule is in the static data area of its own module, and the avariable variable accessed in the dllmodule is also owned by itself. Although the module references variables in the same unit, these variables have an independent copy in different modules. In the subsequent discussion on the compiling mode of the running package, we will also discuss the issue of sharing unit variables.

Therefore, we should remember that in non-running package compiling mode, all kinds of global variables and objects in Delphi, such as application, screen, session, printer, etc, each EXE and DLL module has its own copy, instead of the same thing.

What about global variables relative to threads?

Thread global variables are global variables defined by the extended reserved word threadvar. Threadvar can only be used to define global variables, not local variables. The global variables defined by it have a copy in each thread and exist in the Global static data zone of each thread. The thread variables defined by threadvar are unique to each thread and can be safely used within the thread. The global variables defined by using VAR reserved words are shared by the thread, so you must pay attention to the sharing and mutex issues when accessing them.

Next we will discuss the issues of local variables, parameter variables, and return values.

These three types of data elements are partial sub-processes or functions. The scope is only within this subprogram and is temporary. They are self-defeating in the thread's stack zone. It is generated in the stack with the occurrence of a subroutine call, and perish with the return of the subroutine call. The stack area of a thread is increasing and decreasing with the deepening and returning of subprograms. Local variables, parameter variables, and returned values are like small creatures on the Reef. When the tide rises, a batch of life is born, and the tide falls back and they die again. When the tide came back, it was another new world of life, with no memory at all. Life may be so short.

In programs that contain recursive algorithms, the stack area of the thread is very interesting. There will be many striking similarities in the history of stack growth. For each recursive call, a batch of similar local variables, parameter variables, and return values occur once, And the stack increases rapidly. Therefore, you must pay attention to the issue of stack space when writing a program containing recursive algorithms.

Let's take a look at the dynamic data zone.

Almost all objects in Delphi exist in the dynamic data zone. Although their object pointers may be a global variable, a thread global variable, a local variable, a parameter variable, or a return value, however, the instance of the object is allocated in the dynamic data zone (unless you overload the tobject class method newinstance and allocate the object instance space somewhere else ).

This situation in Delphi is different from that in Standard C ++. When a global object is defined in standard C ++, its instance exists in the Global static area of the program. While Delphi is to be dynamically created when the program is running, for example, in the code in the initialization part of the unit file.

In early programming concepts, the dynamically allocated data area is also called a "heap ". At that time, because the machine's addressable space was small, "heap" often shared a space with "stack. The top part of the space that begins to grow down is the "Heap", and the part that starts to grow up from the bottom is called the "stack ". Therefore, this space is collectively referred to as a "stack ". The current programming space is very broad, and the concept of "heap" seems outdated, and "stack" is closely linked with the concept of multithreading. Therefore, the current "stack" refers to the stack used by the thread.

Finally, let's take a look at the code.

In Delphi, an EXE or DLL module File is generally compiled by a project file (*. DPR) and several directly or indirectly referenced unit files (*. Pas. Without the optimized compilation option, all code and data written in the project file and unit file will be compiled into the physical module File. If the compilation optimization option is enabled, only the code and data used will be compiled into the physical module File.

Generally, your application is composed of multiple physical file modules, typically composed of an EXE module and several DLL modules. When writing module programs, some units are shared. A shared unit is referenced both in the compilation project of a module and during the compilation process of another module. Unfortunately, the code and data in a shared unit between modules will be compiled into each module that has referenced the unit. When these modules of the application are loaded into the process space, the Code commands and data of the Unit will have multiple copies.

Although, we can separate the shared unit files and compile them into a DLL module to share code and data. However, this will make the division of program modules very complex and difficult to manage, which is difficult to work in the actual development process.

Now, we have basically figured out where the data and code will be. As I said, such exploration and thinking are a hard journey. Because, in our hard work, we have explained some truth, but there will be new difficulties. This world is always not perfect!

The greatness of Delphi lies in her ability to make many complicated difficulties easy! Then we will see how the build with runtime packages provided by Delphi perfectly solves this problem.

Section 5 Delphi running package

... Sorry, I haven't finished writing... Skip ....

Section 6 object dream

One time, I dreamed that I had become an object in the world of computer time and space. With the continuous development of the computer world, our objects are no longer as busy as they are in the primitive age, just to get the resources to survive. Our thinking is unprecedented. We not only think about why we want to survive and run in the computer world, but also boldly study and explore the unknown mysteries of the computer world. We already know that the whole computer world is made up of the basic particle byte, And the byte is made up of eight smaller bit particles. We also know the law that the material will not go out, that is to say, the destruction of any object only means the disintegration of the object structure and will not reduce any byte or bit particles in the computer world, and these substances may become part of other objects; or even, we also know that the world we are in is a sphere, because, beyond the longitude $ ffffffff, we return to the origin position of $00000000. The famous physicist object Newton has long found a common connection between various objects. In addition, he proposed a famous theory about the relationship between object motion velocity and object size-Newton mechanics. However, the object Newton has been wondering what force is driving the movements of various objects. Therefore, he believes that God, who created the entire computer world, is promoting the movement of various objects. Later, he became the most devout believer of God. Shortly after the death of the Newton object, our computer world gave birth to another even greater object. Based on the basic causal theory that only code execution can result in execution, he proposed that the time and space of process movement is relative to this great theory. In his opinion, looking at the process space in another movement in the process space in one movement, the time and space are not absolute, and the space will bend. Moreover, the speed of any object cannot exceed the speed of the CPU, and the CPU speed is the speed of light in our computer world. The name of this great scientific object is Einstein. his theory of relativity was not understood by the object at the beginning, but later scientific exploration proved the correctness of this theory. His theory that code energy and data material can be converted to each other was also verified in the large-scale destruction Virus Nuclear Weapon.

In the dream world, I am very happy. I changed my attributes in a moment, and then moved my methods to feel external events. Yes, I am a real object! After a while, I suddenly realized that I was an object, but this object turned into a real world in my dream ......