pitticks, the forbidden variable [solved]
Re: pitticks, the forbidden variable
pitticks is located at 0003:00000830.
OS-LUX V0.0
Working on...
Memory management: the Pool
Working on...
Memory management: the Pool
Re: pitticks, the forbidden variable
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:pitticks is located at 0003:00000830.
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 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.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: pitticks, the forbidden variable
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.cr2 wrote:MSVC++ didn't allow me to set a class member as a handler in the IDT.neon wrote:You should be able to do both without any problems. What is the "other error"?
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
KRNL.DLL (rename from KRNL.TXT to KRNL.DLL):
OS-LUX V0.0
Working on...
Memory management: the Pool
Working on...
Memory management: the Pool
Re: pitticks, the forbidden variable
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.
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
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.
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)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.
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
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Re: pitticks, the forbidden variable
Thanks neon. It works!!
OS-LUX V0.0
Working on...
Memory management: the Pool
Working on...
Memory management: the Pool
Re: pitticks, the forbidden variable [solved]
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.
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.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}