Page 3 of 3
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 5:08 pm
by cr2
pitticks is located at 0003:00000830.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 5:34 pm
by neon
pitticks is located at 0003:00000830.
If you got that directly from the linker script, then no its not. 830 is its offset address from the image base. In your linker map, you want the number that is listed under the
Rva+Base. This will be the linear address that your variable is at. For an example:
Code: Select all
Address Publics by Value Rva+Base Lib:Object
0001:00000000 _mainCRTStartup 00100400 f mainCRTstartup.obj
0001:0000002f ?_initterm@@YAXPAP6AXXZ0@Z 0010042f f cstd.obj
0001:00000049 ?_atexit_init@@YAXXZ 00100449 f cstd.obj
In this example, mainCRTStartup is located at linear address 0x100400. This is where it should be at in memory.
In either case, that information will not be helpful to us without either a copy of your project or your kernel image. If you like, post or email a copy of either the kernel program file or your source+program file so that we may troubleshoot further.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 5:45 pm
by ru2aqare
cr2 wrote:neon wrote:You should be able to do both without any problems. What is the "other error"?
MSVC++ didn't allow me to set a class member as a handler in the IDT.
I don't think any reasonable C++ compiler will allow you to plug in a class method where a static method (or a C function) is expected. The interrupt handler executes in a "static" context, it has no "this" pointer associated with it. A "this" pointer is required to invoke a class method, however.
Besides, why not write the interrupt handler in assembly, why use the __declspec(naked) construct?
One reason is that by writing it in assembly, you have complete control over the code. The other is that inline assembly is only accepted by MSVC when it generates 32-bit code; when targeting x64, the compiler will refuse all inline assembly.
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 5:49 pm
by cr2
KRNL.DLL (rename from KRNL.TXT to KRNL.DLL):
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 7:00 pm
by neon
Alright then...
I see a difference when executing your kernel with the old boot loader. You should grab a copy of the new one from
here. Also, this will allow you to remove the @Order.txt from your project settings, which I recommend.
Besides, why not write the interrupt handler in assembly, why use the __declspec(naked) construct?
One reason is that by writing it in assembly, you have complete control over the code. The other is that inline assembly is only accepted by MSVC when it generates 32-bit code; when targeting x64, the compiler will refuse all inline assembly.
I am going to need to agree with the removing of __declspec(naked)--its not needed (just add esp, 12 like in my other post)
Also, just a slight correction here... MSVC does allow 64bit inline assembly. I worked with someone who developed a MSVC kernel that is compatible with both 32bit and 64bit processors. It turned out pretty good
Re: pitticks, the forbidden variable
Posted: Sat Aug 16, 2008 7:07 pm
by cr2
Re: pitticks, the forbidden variable [solved]
Posted: Sat Aug 16, 2008 7:13 pm
by neon
I kind of thought so considering that your kernel kept dying for me on its very first (completely invalid) instruction
This error could have been easily spotted by using the debugger.
Glad it worked
The new boot loader seems also more compatible with pc's, laptops, and emulators. Still being cleaned up though which is why I did not upload it yet though for the series.
