OSDev.org

iskra wrote:

M-Saunders wrote: Hi, glad you like MikeOS. I determine those exact locations by disassembling the kernel (MIKEKERN.BIN) and looking at the list of calls and rets after the 32K blank space.

You can see that a pattern emerges in the list in mikedev.inc, and when you add a new system call, it's pretty easy to guess as to which number it'll use

Mike

Hey, what disassembler you're using? I need one.

try objdump or ndisasm. Objdump ships with GNU binutils, ndisasm ships with NASM.

JamesM wrote: try objdump or ndisasm. Objdump ships with GNU binutils, ndisasm ships with NASM.

I tried ndisasm but, without file output file i couldn't see much information. How can i make ndisasm to write output to a file?

Can i use Objdump in WinXp?

iskra wrote:I tried ndisasm but, without file output file i couldn't see much information. How can i make ndisasm to write output to a file?

Just redirect it to a file:

ndisasm mikekern.bin > output.asm

Remember that the first 32K of the MikeOS kernel is zeroed-out blank space, so ignore the instructions there (search for the first 'call' and 'ret' combo).

M

Colonel Kernel wrote: If there's no stack switch, there's no multithreading/multitasking/whatever you feel like calling it this week. With interrupts, execution is strictly nested. It's re-entrant, but not really concurrent.

There may very well be stack switching, Dos certainly changes stack on its interrupt's.
Go to anyone who know what they are talking about, and they will tell you the old Xbox is single-tasking, but multi-threading.

actually, the idea that DOS was single-tasking only, is simply untrue...

anyone who worked with computers professionally (including graphics artists, programmers, accountants, etc...) made extensive use of DOS's multi-tasking abilities -- it did have them, they were just very primitive

and there is no difference between a 'task' and a 'thread' they are simply different words to refer to exactly the same thing... (you could consider my computer to be single-tasking: one thread is handling my websurfing, while another is handling my im, and yet another is handling my e-mail notification, and another is handling my spreadsheet, etc...)

JAAman wrote:actually, the idea that DOS was single-tasking only, is simply untrue...

anyone who worked with computers professionally (including graphics artists, programmers, accountants, etc...) made extensive use of DOS's multi-tasking abilities -- it did have them, they were just very primitive

Are you talking about TSRs, or something else?

and there is no difference between a 'task' and a 'thread' they are simply different words to refer to exactly the same thing...

Agreed. I think Dex was trying to say that 'task' and 'process' refer to the same thing however.

(you could consider my computer to be single-tasking: one thread is handling my websurfing, while another is handling my im, and yet another is handling my e-mail notification, and another is handling my spreadsheet, etc...)

Now you've lost me. You said task == thread. From this I conclude that multitasking == multithreading and singletasking == singlethreading. Then you said your computer has many threads running. Is that not multitasking then?

Dex wrote:There may very well be stack switching, Dos certainly changes stack on its interrupt's.

Why? I've never heard of stack switching on interrupts in real mode before. Seems a bit pointless to me...

Go to anyone who know what they are talking about, and they will tell you the old Xbox is single-tasking, but multi-threading.

They might also say that the sky is green and the grass is blue... It all depends on how you define "task" and "thread". The old Xbox runs a single process with multiple threads. It is based on the NT kernel, and that is NT kernel terminology. If we remove the ambiguous term "task" from the discussion, maybe we can agree a little less violently.

Hi,

Colonel Kernel wrote:

Dex wrote:There may very well be stack switching, Dos certainly changes stack on its interrupt's.

Why? I've never heard of stack switching on interrupts in real mode before. Seems a bit pointless to me...

For DOS, the operating system can't be sure how much free stack space the application has left. For example if the application has 2 KB of space reserved for stack but only 512 bytes is free and if an IRQ handler uses 1 KB of stack space, then switching to another stack makes some sense...


Cheers,

Brendan

Brendan wrote:For DOS, the operating system can't be sure how much free stack space the application has left. For example if the application has 2 KB of space reserved for stack but only 512 bytes is free and if an IRQ handler uses 1 KB of stack space, then switching to another stack makes some sense...

That would make sense... I don't remember that from when I last did DOS programming 12 years ago, but the brain cells are dying whether I like it or not...

Now you've lost me. You said task == thread. From this I conclude that multitasking == multithreading and singletasking == singlethreading. Then you said your computer has many threads running. Is that not multitasking then?

exactly the point i was trying to make -- there is no difference at all between them

task==process==thread -- they are all different words with exactly the same meaning (well... some people try to make a difference between them, but the difference is artificial -- ie there isnt a defined meaning for them, simply a difference in how they are handled reletive to each other within a single OS -- and that distinction will be different for different OSs

Are you talking about TSRs, or something else?

that is what i had in mind... (although not the only way...) -- it isnt as elegant, but it works, and it is multi-tasking, and it was just as common as multi-tasking today

Multi-tasking and multi-threading are different and the differenc is important in this case. This is a good simple example of the differanc :
http://www-304.ibm.com/jct09002c/isv/te ... id=1:13922

Now my point is that you can very easy have multi-threading in a single-tasking OS, as its the program that controls the multi-threading, just like in the xbox theres no memory management, its the programs (games) job to do that.

Now my point is that you can very easy have multi-threading in a single-tasking OS, as its the program that controls the multi-threading, just like in the xbox theres no memory management, its the programs (games) job to do that.

this is just another way of saying multi-tasking without memory managment

you cannot have multi-threading without multi-tasking, but you can have multi-tasking without multi-threading -- basically, the word 'multi-threading' means multi-tasking in a different way... which means you cannot have it unless you have a baseline for what 'different' means...

if you have one method of multi-tasking, its called multi-tasking, if you have 2 ways of multi-tasking, its called multi-threading



btw: that link is quite irrelevant, since it assumes a definition for what a 'program' is -- and it is completely absurd that there could even be a definition of what a program is -- a program is about how the end-user views the system -- not how the os interacts with it (for example: is office 1 program? or a collection of programs...)

JAAman wrote:

Now my point is that you can very easy have multi-threading in a single-tasking OS, as its the program that controls the multi-threading, just like in the xbox theres no memory management, its the programs (games) job to do that.

this is just another way of saying multi-tasking without memory managment

you cannot have multi-threading without multi-tasking, but you can have multi-tasking without multi-threading -- basically, the word 'multi-threading' means multi-tasking in a different way... which means you cannot have it unless you have a baseline for what 'different' means...

if you have one method of multi-tasking, its called multi-tasking, if you have 2 ways of multi-tasking, its called multi-threading



btw: that link is quite irrelevant, since it assumes a definition for what a 'program' is -- and it is completely absurd that there could even be a definition of what a program is -- a program is about how the end-user views the system -- not how the os interacts with it (for example: is office 1 program? or a collection of programs...)

This is nonsense, i can make a multi-threading program to run in Dos very easy, but i can not make Dos multi-task, without a full rewrite.

I have taken you to the water, if you do not want to drink it, that up to you.

Dex you do not seem to understand that it is the nomenclature Colonel Kernel is arguing against.

He (and I) think that the concept 'task' can include both thread and process. You disagree, but seem to be arguing a completely different point!

This is nonsense, i can make a multi-threading program to run in Dos very easy, but i can not make Dos multi-task, without a full rewrite.

did you miss my previous post? DOS does multi-task -- apparently your too young to remember (as are most of the people here...), but anyone who actually used DOS for anything serious did multi-task -- quite extensively

however without a complete rewrite you cannot get DOS to multi-thread... (mulit-threading requires the OS -- not the aplication -- to provide 2 separate methods of task-switching)

what one OS calls multi-tasking is exactly like what another calls multi-threading -- the only difference is whether the OS provides a distinct method of doing one different from the other...

my point is there is no way to define the term multi-threading without a comparison to multi-tasking... therefore one must exist before the other to be defined

I have taken you to the water, if you do not want to drink it, that up to you.

you havent taken anyone anywhere -- all you have done is linked to an article miss-abusing a technical term to create a non-technical definition that can be accepted by the ignorant who wouldnt understand the real technical definition

for a brain teaser:
is office 1 program or a collection of programs (for your definition to be valid, you must define what a 'program' is, which is very much undefinable from a technical perspective...)