![]() ![]() The good news is that a P-code procedure descriptor has the value which shows how many bytes it should pop from the stack when procedure ends. #VB6 FILE FUNCTIONS CODE#Because of it can't compile CDECL-procedures (it always does STDCALL ones) we can't debug the code in IDE. The last issue is related to P-code building. This isn't a big issue if we remember about Declared functions which are displayed correctly. #VB6 FILE FUNCTIONS PATCH#So the third patch should affect the displaying procedure. So we should modify this process to specify the CDECL calling convention inside a BSCR-node if such convention is specified in a PCR-node.Īt this point we already have user CDECL functions they are compiled to the proper native code (with ADD ESP, XX / RET instructions) but they isn't visible in the Code Pane. ![]() The problem related to user functions is the parser doesn't check the calling convention field for them and sets it to STDCALL inside the BSCR-node. The first issue is the PCR-node is translated to a BSCR-node which already directly describes the procedure in the VB6-project. Since we can specify the CDecl keyword for a Declared function and it falls to its PCR-node we also can modify the process to set the same info for a user function. The good thing is Declared procedures and user procedures fall to the same function that makes a PCR-node which describes them. Regarding to the user procedure declaration we can just hijack the process when it has parsed the procedure name to pass the CDecl keyword. If there is some wrong sequence / error it rejects the parsing process and mark the line in red. It extracts all the tokens (lexems) from the source line step-by-step and validates their type. The first point is when it process the source text file. There are 2 points where the VB6 parser process procedures. The native VB6 code-parser rejects the CDecl keyword after function name so to change this behavior the Add-in patches some internal code which parses the source. #VB6 FILE FUNCTIONS HOW TO#How to enable CDecl keyword for user functions? The second problem is related to the unimplemented p-code handlers which generate 0x33 error. The first problem is with the "Bug table" which will crash the IDE but we already know how to bypass it. In fact, if you patch the above JMP to the CompileSTDCALL label the runtime will successfully generate the code! Moreover the native code will be compiled successfully along with the add esp, xx instruction after each CDecl call: If you change this logic you can force the runtime to compile a CDECL function like a STDCALL one. There is the point where the runtime check the calling convention of a declared (declared with Declare keyword) function and it unconditionally generates the P-code which raises the 0x31 error: I guess it's because there is no P-code handlers in the runtime. Why CDecl keyword doesn't work for "Declare" functions? It contains the stubs which generates 0x33 error (internal error): Why? It's because VBA6 doesn't have the P-code handlers for CDECL functions. So if you replace 0x19 value to 0x09 the bug dissapeares, but the code won't work yet. If you try to compile a stdcall function you'll see it uses the second entry in the table and it contains 0x09 value at 0x1D offset. This table contains 0x19 value at 0x1D offset in the first entry which causes the jump to procedure which causes the crash. ![]() There is the table which manages the process of the codegeneration:Įach entry in the table contains 30 bytes. During P-code generation the runtime extracts this information to map the specified function with the corresponding p-codes. VBA6 then uses this information inside its own structures which describe the functions in the project. This method returns the FUNCDESC structure where the callconv member contains the calling convention of the external function. When VBA6 compiles the code it calls ITypeComp::Bind for each external function: Moreover this Add-in adds the ability to use the CDecl keyword for user functions. This Add-in fixes this behavior and you can debug your code in IDE and compile the code to an executable file. A similar problem occurs when using the CDecl keyword - VB6 always generates the code with the 0x31 error ( Bad Dll Calling Convention) so you can use such functions neither IDE nor compiled executable. The project just has crashed and doesn't even start although compilation to native code works without any issues. If you have ever tried to use CDECL-functions declared in a TLB then you know that debugging (in IDE) is impossible. The Add-in allows you to use Cdecl functions in VB6. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |