VB Program Big Secret 1.visual Basic Program Overview I use W32DASM (Ver 8.93) to unconfigure a more complex VB program, where many API functions such as GetPrivateProfileString, OSFcReateshellLink, ShbrowseForFolder, etc. from a lot of DLLs. After unlocking, it was found that the program only used a DLL: MSVBVM50.DLL (I used or VB5)! Programs such as VC, Delphi and other programming programs are directly referenced by DLL. After the research discovery program uses the following major API: Rtcrandomize: Randomize: The corresponding API of the RTCMIDCharVar: MID function is corresponding API; RTCLTCHARVAR, RTCRIGHTCHARVAR: See it, these are Left, Right functions corresponding to the API; rtcUpperCaseVar: corresponding to API the UCase functions; rtcKillFiles: corresponding to API Kill statement; rtcFileCopy: corresponding to API the FileCopy statement; rtcFileLength: EOF, FileLen corresponding to API function; rtcGetTimer: Randomize Timer acquired Timer corresponding API; rtcShell: The corresponding API of the shell function; the corresponding API of the RTCMAKEDIR: MKDIR statement; RTCRemoveDir: RMDIR statement corresponds to the corresponding API; RTCDIR: DIR function corresponds to the corresponding API; RTCSpaceVar: Space function corresponds to the corresponding API; no problem should be seen: VB All functions, statements, methods are implemented by the API in MSVBVM50.DLL, generally by "RTC" to connect the full name of the function or statement, and the API involving the string is generally added to "VAR". In addition, there are some functions written by: __vbaubound: Ubound corresponding API; __vbaFileOpen: Open statement corresponds to the corresponding API; __vbastrcmp: Compare two strings: if string1 = string2 Then ... __vbavaror: OR operator Corresponding API; __vbaredim: redim statement corresponds to the corresponding API; __vbaget, vbaput: Get, PUT statement corresponds to the corresponding API ... When running, the VB program calls them to complete the work. 2. The first part of the call of other DLLs is solved. We know that the VB program is actually not a real executable, it is only mechanically calling the API executor in MSVBVM50.DLL. So since the VB program only calls MSVBVM50.dll, how does it call the API in other DLLs? Pay attention to this API. It can cause our attention: DLLFunctionCall: Have you seen it? It is our protagonist. You can understand from the literal: it is used to call other DLLs.
This makes the function used by the program in MSVBVM50.DLL (how to be a bit like feudal system, central focus ...). 3. Heavy weight: The launch of the VB program We already know how the VB program is running. So how do it start? Take a look at the API called. Among them, an API thunder does not move, and each VB program has: Thunrtmain First, the VB program is called ThunRtmain. Thunrtmain is the program initialization process and obtain the process ID. Then it loads VB5chs.dll to prepare for the new window. Then it starts to get window properties such as fonts, titles, colors, and so on with LOADSTRING. Then call IMM32.DLL and start using it to open a new window. Then get the VB program name using GetModuleFileName, then add the signal to the CreateSemaphore. The function of the signal is: When the monitor value is greater than 0, the signal machine works. Then use OLE32.DLL to open a hidden window called "DDE Server" using CreateWindowEx to make it strokes from it. Exit OLE32.DLL, MSVBVM50 starts calling the program manager. The previous work registers a class name for our VB program: VBFOCUSRT5, you can use this class name to create a VB form. First, use a large number of loop read half-angle / full-angle characters, then read the properties of each control, use local_function to "fight" into a complete control, and finally integrate all the work you have made, start VB program. From the process, the most time is naturally the load control, followed by loading the character set. The VB program is slow, and the start speed is slow. This is difficult to avoid, I hope VB7 can improve this. I don't know if you haven't seen it, the compiled VB program is just the same as the release of the source program, the connecting control attribute, method, and the event name are both. The slow version of the VB program is here, which is only mechanically, endlessly calls the API in the msvbvm50.dll to run the program. To completely get rid of this, you can only reform the method of compilation of the VB program to make it a standard resource WIN32 program. Attachment: The VB program is started with the VC program. It is only a "start" speed mentioned here. In fact, the EXE speed compiled with the VB program is almost almost (even faster) compiled with other program languages, but it is only too slow. We know that the calculator included with Windows is compiled with VC . I have compiled a sample calculator program, and the process is simple. When you click Command1, add TEXT1 to Text2, and then assign the value to Text3. The code only one line: private submmand1_click () text3 = cstr (Val (text1) val (text2)) End Sub compiles it to EXE. In order to show the difference in speed, I chose a slower computer: Pentium 166 mmx 80m EDO 3.2G hard drive. Start speed comparison: For the result of fairness, total test five times, take the average. Unit: Seconds Run VB Calculator VC Calculator 1 2.43 0.87 2 0.92 4 1.02 0.78 5 0.87 0.84 Average speed 1.22 0.83 You will find that the VB calculator is relatively slow, there is still a few times. .
