Hard to call the stack.

Show your code. We can't help without it. Post a minimal source that shows the problem.

I am currently away from my computer.
However, what I can tell you, is that it calls the exact address of MessageBoxA.
I don't see how it should not work.
I allocate memory with PAGE_READWRITEEXECUTABLE and MEM_COMMIT | MEM_RESERVE using VirtualAlloc.

I don't get why it doesn't work. The relocation is successful, same goes for resolving the imports.

Clearly the relocation was not successful.

If you don't want to, or can't, post the code then use a debugger and see what is happening.

If the relocation was not successful, why do other APIs work. I tried to use the GetProcAddress and LoadLibrary functions within the DLL, and it produced the broken MessageBox as well. And those APIs did indeed work as they resolved the right address of the module as well as proc address when they were called.

I have the executable available, so I can grab a debugger and explain what is happening in the relocation part, but I still do not understand why other WinAPIs like LoadLibrary, FreeConsole, and GetProcAddress still work.

Perhaps your text pointers are incorrect? The API calls appear to be good, but there are other things that need relocating also.

I remember I was getting weirdly shaped message boxes when I didn't keep the stack aligned to 16 bytes on a 64-bit machine.

The thing is I use NULL for all the variables when calling the MessageBox (just for simplicity), however if I provide text pointers instead, nothing changes.
Besides, the text pointers are working as I successfully use LoadLibrary and GetProcAddress with said arguments.

In addition, there is no text in the diøog button either, which has nothing to fo with text pointers.

The DLL as well as the loader is 32 bit. How do I align the stack to said bytes?
The C++ version of the pe loader has no isssues.

Still struggling with this. Any suggestions?

Many suggestions have already been given but you didn't say if you tried them. We don't know what you have done. With no code to look at we are blind. With no example to test we have no information. Did you try the debugger? What did you see?

On Windows XP it would probably work OK, but with each version of Windows, more and more libraries are loaded in process address space. So if you load only User32.dll, it's not enough.