Answer the question
In order to leave comments, you need to log in
Can anyone explain what happens when you click on a program shortcut on the physical level?
Can't figure out how the OS works with the physical layer.
PS If it's not difficult, leave your contact details, I want to interrogate something
Answer the question
In order to leave comments, you need to log in
1. The mouse sends "I'm pressed" and "I'm released" commands. We consider that the mouse is USB - then the bus manager gives the mouse a timeslot 125 times per second, and during this time it sends an 8-byte packet, and it contains the fields “shift in X, shift in Y, pressed buttons”. The OS itself keeps track of the coordinates of the mouse cursor. The display of the mouse cursor is a separate feature of the graphics driver (due to speed requirements).
2. From these commands, the OS generates the “Double click on coordinates (X, Y)” event and sends it to the current program (in this case, the Windows shell, explorer.exe, aka Explorer).
3. The desktop is a heavily modified ListView from comctl32.dll (if I named this library correctly). However, the "double click" event is handled by the Explorer itself, and if some element is selected, it says: run the file, the shell32.dll library, the ShellExecute function with the "open" verb.
4. The shell32.dll shell library has a special code branch for launching shortcuts. It parses the shortcut file and calls the lower-level CreateProcess function.
5. The Windows kernel does whatever it takes to create a process, give it a separate "user" address space, a separate call stack, I/O threads, and so on. The EXE file itself and its libraries become part of the Windows paging system, and if any page of the code segment is thrown out, it is loaded directly from the EXE / DLL. Allows dynamic addresses that become known only when the program is loaded (so-called relocations). The process of downloading a program is a complicated matter, I am unfamiliar with it.
6. We consider that the program is GUI. Then, when loading, oddly enough, nothing outwardly happens (only the screw cracks, pumping data into RAM). The program itself says to WinAPI: I need to create such and such a window, with such and such buttons in the title, with display on the taskbar.
7. The system itself sends events to the window: “I am resizing”, “I am showing”, “I am redrawing”. The program can intercept these events and do something on them. If the window has a non-client part (title, frame), Windows itself shows them.
8. One of several Windows subsystems is responsible for redrawing the client part of the window (that is, what is inside the frame). The most common is GDI (graphics device interface), although hardware acceleration libraries are increasingly used - DirectX / OpenGL / Vulkan.
9. As soon as the redraw events have fired - internal Windows and user - we see a window on the screen!
The shortcut is read - this is a separate file. It contains the path to the actual file being executed - it is then executed.
Or clarify the question, what is the physical level for you.
The onclick event (ondblclick) fires in the explorer.exe program, a specific element is selected from the Listview, which is a shortcut, a process is started with parameters that are read from the shortcut file.
Shortcut data loaded into explorer.exe internal data array
That is, at the physical level, the main interruption from the mouse is to catch.
It's not very clear what the "physical level" is for you (mouse or screen?), but joking aside, there are WinAPI functions and they are called during the actions of the operating system itself. Here is an example of an article on how you can see what is happening on various occasions (Spy ++ is needed, if Visual Studio is installed, then see the Tools menu):
zennolab.com/discussion/threads/pm-winapi-ili-upra...
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question