Worst ways to implement....
-
- Member
- Posts: 118
- Joined: Mon May 05, 2008 5:51 pm
Re: Worst ways to implement....
*snickers at AJ*
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: Worst ways to implement....
- Go into protected mode but use V86 for everything.
- Make the OS sentient. "I'm sorry Dave, I'm afraid I can't do that."
Re: Worst ways to implement....
@AJ: You forgot - virtual 8086 mode is very good at this.
System Calls: Set an undefined opcode (UD2) to be the 'call' instruction. When the opcode is executed and a trap occurs, translate the opcode to a call instruction and write it to the boot code (or even: put it in the MBR and execute in place from then hard drive) so it gets executed on startup. Then reset the machine (for added insanity, by triple fault)
System Calls: Set an undefined opcode (UD2) to be the 'call' instruction. When the opcode is executed and a trap occurs, translate the opcode to a call instruction and write it to the boot code (or even: put it in the MBR and execute in place from then hard drive) so it gets executed on startup. Then reset the machine (for added insanity, by triple fault)
Re: Worst ways to implement....
Sadly, Microsoft used that for a hack back in the Windows 2 days...
on the 286 (I believe) context switching into kernel mode was inordinately slow, so they would instead generate a fault and let the drop back into kernel mode to handle it be the actual target of the switch...I forget the exact details but that's the basic idea.
on the 286 (I believe) context switching into kernel mode was inordinately slow, so they would instead generate a fault and let the drop back into kernel mode to handle it be the actual target of the switch...I forget the exact details but that's the basic idea.
Re: Worst ways to implement....
According to the Wiki, L4 does that too. While hackish it probably works quite well until a some program (like a fuzz tester) tries to execute random instructions... I imagine if you ran crashme or similar on an L4 machine it would manage to execute a few system calls, while it probably wouldn't on any other OS (crashme, if you haven't heard of it, is a program that executes random bytes as data to test stability).Sadly, Microsoft used that for a hack back in the Windows 2 days...
on the 286 (I believe) context switching into kernel mode was inordinately slow, so they would instead generate a fault and let the drop back into kernel mode to handle it be the actual target of the switch...I forget the exact details but that's the basic idea.
Re: Worst ways to implement....
"hello world" is my crashme program. I just rename my text file to crashme.com and execute. I have no idea what opcodes it translates into but it works everytime.
Re: Worst ways to implement....
*gets out disassembler*kubeos wrote:"hello world" is my crashme program. I just rename my text file to crashme.com and execute. I have no idea what opcodes it translates into but it works everytime.
Code: Select all
a.out: file format elf32-i386
Disassembly of section .text:
00000000 <main>:
0: 48 dec %eax
1: 65 gs
2: 6c insb (%dx),%es:(%edi)
3: 6c insb (%dx),%es:(%edi)
4: 6f outsl %ds:(%esi),(%dx)
5: 20 57 6f and %dl,0x6f(%edi)
8: 72 6c jb 76 <main+0x76>
a: 64 fs
- salil_bhagurkar
- Member
- Posts: 261
- Joined: Mon Feb 19, 2007 10:40 am
- Location: India
Re: Worst ways to implement....
Heres one of my early ideas of writing an operating system:
Scheduling:
Switch between processes at every instruction. Make the timer run at clock speed. After every instruction the next process comes in and executes one instruction...
Scheduling:
Switch between processes at every instruction. Make the timer run at clock speed. After every instruction the next process comes in and executes one instruction...
Re: Worst ways to implement....
Everything: Use well-commented macros with inline binary and preprocessors to compile according to architecture.