Why does my program hang?

[madmaxsantana]

#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{
    int *p = 0x0000;
    while(*p <= 0xffff)
    {
         cout << *p;
         *p++;
    }
    return 0;
}

Here is my program. I want to print the memory contents for all location starting 0x0000 and anding at 0xffff... The program compiles fine but as soon as I execute it, it hangs there and after a second or two, windows says it has stopped responding and Windows is checking for a solution...

What is the reason? What would be the correct method to do that?
All help will be appreciated.

[madmaxsantana]

Wait a minute! Am I even allowed to do that inside an operating system?

[3pj6b7Xj]

Lol, just answered your own question!

[Null]

You are not allowed to read memory which doesn't belong to your program. If you try to do this, you will get a segmentation fault.

[madmaxsantana]

And what do I have to do to FORCE it? I mean it's MY computer, Microsoft doesn't OWN it... :O

[madmaxsantana]

And I would also like to look at the option of being able to choose what memory segment my program operates in (or to know which memory segment it is operating in)...

[Null]

And what do I have to do to FORCE it?

Write a kernel mode driver.

And I would also like to look at the option of being able to choose what memory segment my program operates in

I think it's possible to read process' memory with ReadProcessMemory function.

[madmaxsantana]

:O What the hell is that... LoL!

But seriously, if it is simple enough I might!
Is there a way I can run my programs directly through the processor without having to go through an operating system? I once thought about writing my program to the boot sector of a floppy drive and booting my system with it. But my computer didn't have a floppy drive. I couldn't waste a CD just for a small program and I didn't know how to write a program to the boot sector of a USB...

But in case that is possible, I would certainly like to try that. It should be fun... Running an "a=b+c" with 99.999999% of the processor power going waste. :p

[madmaxsantana]

I think it's possible to read process' memory with ReadProcessMemory function.

In C++ STL?

[chrisname]

No, it's a Windows API function.

Writing a driver for the Windows kernel is not easy, but it isn't overly difficult and it's something that you should do at some point (it's fun and educational). I'd also recommend learning to write Linux kernel modules.

[Null]

Is there a way I can run my programs directly through the processor without having to go through an operating system?

It seems that you are about writing an OS, which is really hard thing, but if you only want to do "a=b+c", then visit http://www.osdev.org/
Btw, simply writing your program to boot sector won't work.

In C++ STL?

It's WinAPI

[chrisname]

In detail,

madmaxsantana wrote:

:O What the hell is that... LoL!

By "kernel mode driver", Null was referring to a program that runs side-by-side with the operating system in "kernel mode" (aka "supervisor mode", "kernel space" or "ring 0"). A program running in ring 0 has unlimited access to hardware. Video card, hard drive and network drivers (to name a few) run in ring 0 (on a monolithic system; on other types of kernels (like microkernels) they run in userspace/usermode/userland/ring 3).

madmaxsantana wrote:

But seriously, if it is simple enough I might!

It isn't simple at all, but it is certainly doable, and it's a fun and educational experience.
If you're thinking about doing it, you can use one of the following tutorials:
Linux: http://tldp.org/HOWTO/Module-HOWTO/x73.html
Windows: http://msdn.microsoft.com/en-us/library/ms809956.aspx

madmaxsantana wrote:

Is there a way I can run my programs directly through the processor without having to go through an operating system?

Yes, but this is only achievable by writing a driver, operating system or bootsector program. All of those are quite complicated. The bootsector program is probably the simplest in theory, but it gets quickly complicated because you have to write everything in assembly language, and it all needs to fit into 512 bytes. If you want to use C/C++ and/or you need more than 512 bytes (there really isn't alot you can do with that much, and if you want to use C or C++, 512 bytes won't be enough) then you have to
1. Read a file from the hard disk (easy part, since the BIOS does this much for you)
2. Load and arrange an executable file into memory (difficult to do in just assembly)
3. Switch to protected mode or unreal mode (so that the C code can use 32-bit instructions) or long mode (for 64 bits)
4. Jump to the program.
And you get 512 bytes of code and less than 1 MiB of memory to work with. I think the best way is to do it in three stages (the first stage is located in the boot sector, it loads the second stage (which can be larger than 512 bytes; 4 kiB is a good size) which contains a loader for a simple executable file (such as a.out) that can load the third stage, which is your program) but that is way too complicated just for a normal program, and is the kind of thing you would do when writing an operating system (or you could do the smart thing and just use GRUB).

madmaxsantana wrote:

I once thought about writing my program to the boot sector of a floppy drive and booting my system with it.

You'd have to compile it as a flat binary file, it would have to be exactly 512 bytes long, and the last two bytes would have to be the value "0xaa55". Once you've done that, you have to make your code perform a "segment jump" to 0x7c00 (which is where the BIOS loads the program), set up a stack pointer (usually, the stack starts at 0x9c00, which is right after your program in memory) and then you're good. Except it has to fit into 512 bytes, hence the suggestion of using stages like GRUB and other boot managers do.

madmaxsantana wrote:

But my computer didn't have a floppy drive. I couldn't waste a CD just for a small program and I didn't know how to write a program to the boot sector of a USB...

This can be solved by using an emulator like Qemu or Bochs.

madmaxsantana wrote:

But in case that is possible, I would certainly like to try that. It should be fun... Running an "a=b+c" with 99.999999% of the processor power going waste. :p

It doesn't matter. When your program is running it has 100% of the CPU's processing power at it's disposal (unless you're using SMP, in which case it gets between (l_p / 100)% and 100% of the CPU's power, where l_p is the number of logical processors present). There are no other programs running (again, unless you're using multiprocessing). The OS switches between your program and all the other programs running by setting a timer to periodically "wake" the OS so that it can switch programs.

[madmaxsantana]

Hey chrisname!

WOW!!!
One personal question please! Are you a professor of computer sciences or something?
LoLzzz. Seriously, I am amazed. Thanks a lot for the whole long story.

Actually, I wrote a little research paper titled "Monolithic GNU/Linux Kernel, Minix Microkernel and the Comparison"... It was small, 12 pages, and I had to explore all the details of both types of kernels as well as the particular examples in both cases. Therefore, I know a little about kernel space and usermodes and privileges, so I perfectly understand what you mean by the first part of your speech. Actually, I was under the impression that GNU compilers (or mingW for that matter) being directly involved with operating system are automatically granted control over the hardware resources (although not directly, but completely)... But, now that I come to think of it, in Windows, it is the Microsoft C++ components which are directly linked with kernel operations and since the WinNT kernel is microkernal, it treats the kernel level compiler/interpreter as a service and doesn't even grant it full control. In any case, since it is not the compiler that executes the program after compilation, rather it is the program CodeBlocks which does this, I can forget privileged mode without gaining access to kernel space myself. That is how I understand it. I might be wrong, but the idea does overlap with your suggestions.

I am dual booting Linux and Windows at my system and I thought about rebooting into Linux and trying compiling and running the program in recovery mode. But then again, the tty virtual console drivers would already be started and anything I do will be in user space and strictly limited space. But in my opinion, it would be pretty easy to override the kernel abstractions in Linux (I don't know how to do that, but that can be done)...

I admit that I knew nothing about kernel mode drivers. I guess they are the same as "services"... I may be wrong. But I perfectly understand that it is one of the easiest ways to gain kernel space access...

And I didn't understand the thing you told me about booting from floppy. I thought it just had to be a fixed amount (you say it is 512 bytes but I thought previously that it was more in newer systems) and the BIOS will automatically read it from the boot sector... I have had the Computer Architecture course but it was joined with Embedded Systems course, which meant less concentration on i386 and more on PIC and ARM... That is why I know little about stacks and booting... Although there are stacks in uC but we rarely use them. Same is the case with boot loaders. We simply call the first few config lines of the main loop single thread kernel as boot loader...

And yes! Thanks for reminding me. I hadn't thought about involving virtualization but that is the best option.

About the last part, I was clearly wrong. Thanks a lot for correcting me.

Once again, thanks for everything. Nice going.

[Null]

WinNT kernel is microkernal

AFAIK WinNT kernel is hybrid kernel.

[madmaxsantana]

Yeah. I am not sure about that either. Maybe you are right. But the point is, it doesn't allow kernel space to most of the services.

[chrisname]

madmaxsantana wrote:

One personal question please! Are you a professor of computer sciences or something?

LOL, no, but thank you for the compliment! I've been reading alot about operating systems for the last few months, from http://wiki.osdev.org and Andrew Tanenbaum's book, Operating Systems: Design and Implementation

madmaxsantana wrote:

GNU compilers (or mingW for that matter) being directly involved with operating system are automatically granted control over the hardware resources (although not directly, but completely)

I'm not sure what you mean here... I don't see how a compiler could get control of the hardware, or why it would need to.

madmaxsantana wrote:

the WinNT kernel is microkernal, it treats the kernel level compiler/interpreter as a service and doesn't even grant it full control

As Null said, Windows NT uses a hybrid (modular) kernel. There aren't really many microkernels out there, the main ones are Minix, Mach and the (unfinished) HURD. I'm not sure if there's a BSD that uses a microkernel, I think DragonflyBSD does.

madmaxsantana wrote:

In any case, since it is not the compiler that executes the program after compilation, rather it is the program CodeBlocks which does this, I can forget privileged mode without gaining access to kernel space myself

That's not quite how it works. CodeBlocks is not executing the program after compilation, the operating system is. I'm not sure how Windows handles process forking, but on UNIX based OSes, a program calls fork() and the operating system creates a new entry in the process table, allocates memory for a new process, and then copies the process image into the new memory location (actually, in some systems (such as Linux) this is only done if the new process tries to write to the memory, it's called copy-on-write). Then, in the new (child) process, the program replaces itself with another program (by calling exec*() on UNIX-like operating systems) and the kernel starts to execute the new program. This is how every program starts on UNIX systems -- the init process originates within the kernel (look at the code in linux-x.x.xx.x/init/), switches to usermode and then mounts the root filesystem and runs /sbin/init. Then it starst fork()ing to run other processes (such as "getty"). Every program running on a *nix system is a child process of init.

madmaxsantana wrote:

I am dual booting Linux and Windows at my system and I thought about rebooting into Linux and trying compiling and running the program in recovery mode. But then again, the tty virtual console drivers would already be started and anything I do will be in user space and strictly limited space. But in my opinion, it would be pretty easy to override the kernel abstractions in Linux (I don't know how to do that, but that can be done)...

It would be almost impossible to do; the x86 hardware does not let you. The only way to do something like that would be to find a bug in the scheduler or something that convinces the kernel that your program should be running in kernel space. Good luck finding such a bug... you have several million lines of code to audit to find it.