My OS need to cout and cin !

[Markost]

hello everyone ..


I want to make my own OS.
I am using assembly & c++.
I make my boot loader to load and executed the kernel

I make my kernel by c++ ( I am using MSVC++ 2010)

so ..

I want to make new header file to define cout & cin function (.h) to show my msg and value in variable in my main.cpp!
without iostream or another header file. only new

can any one help me please ... It is something that is very important for me


thank you ..

[rdos]

I make my kernel by c++ ( I am using MSVC++ 2010)

MSVC only produces binaries for Windows, and demand a large set of Windows DLL-files even when your application is of the "hello world"-type, so that is not a suitable environment for an OS.

[bluemoon]

I want to make new header file to define cout & cin function (.h) to show my msg and value in variable in my main.cpp!
without iostream or another header file. only new

If you ask such question I doubt you got new too
Anyway, check the wiki on print char to screen, and write your cout-alike (it would be overkill to start with a full feature cout)
cin is a bit more complicated for different types of controllers and input devices, but there is also a tutorial for PS/2 keyboard.

[Antti]

I am using MSVC++ 2010

I once read that there might be problems with the license if using Microsoft tools for OS developing (if it is not based on Windows). I do not know the details. That may not be a problem but...

[OSwhatever]

Microsoft use Dinkumware's (http://www.dinkumware.com/) STL implementation which seems to be a 100% commercial product. I haven's seen any sources at least. Then you have other options to use other libraries but how well they work with MSVC I cannot say.

I have actually done both. I have a native cin and cout for both user space and kernel implemented as well as support for stdlibc++ cin and cout. For libstdc++ you basically get cin, cerr and cout working once you support read and write to character devices, the file handle for these are usually 0 - 2.

Also I recommend you to look at ustl (http://ustl.sourceforge.net/) which might give you some idea how to implement it or you can try to port ustl to your system.

[iansjack]

I make my kernel by c++ ( I am using MSVC++ 2010)

MSVC only produces binaries for Windows, and demand a large set of Windows DLL-files even when your application is of the "hello world"-type, so that is not a suitable environment for an OS.

I'm not sure that is correct. MSVC++ can be used to produce object files which you would link with whatever libraries you choose to. But you probably have to jump through a few hoops to do this, and I wouldn't use MSVC++ for OS development. (But, then, I wouldn't use C++, and I wouldn't use Windows as a development platform. It may be possible but that doesn't mean it's a good idea; the tools available on OS X, Linux or one of the BSDs are easier to use for this purpose IMO.)

[neon]

Hello,

It is indeed possible to configure MSVC++ for OS development without any tricks but should consider the consequences of doing so based on design needs. For example, relying only on MSVC++ as a front build environment makes the project dependent on a closed source 3rd party software that can later break the build process. It is also important to consider that MSVC++ implementation of C is not up to standard and may pose compatibility problems with more up to date compilers. That is actually the only problems that I have found; it can, by definition, work as a limited cross compiler to target non-Windows machines.

Regarding the original question, I don't recommend using CIN and COUT in a kernel or executive. The C and C++ runtime's are typically implemented as user mode libraries not kernel mode (disregarding embedded systems here). Implementing the actual standard libraries are a lot more harder then just implementing its interfaces. I think its more recommended to port an existing library package (IIRC someone on these forums were writing one such package.) Rather, implement kernel-specific alternatives as not to cause confusion. This also allows you to implement what you want your own way.

[JAAman]

I am using MSVC++ 2010

I once read that there might be problems with the license if using Microsoft tools for OS developing (if it is not based on Windows). I do not know the details. That may not be a problem but...

that is simply not true at all

the most probable source for this is the common confusion between MASM (the MS assembler, essentially no license issues -- but lacks support for certain portions of the instruction set making it difficult to use for boot-code) and MASM32 (a non-MS set of libraries for developing windows applications -- license specifically forbids using it for OSdev)

the truth is, at one time we actually had several people here who were using VS for OSdev, and a whole section on the wiki about how to do it (including details on all the OSdev-relevent configuration/commandline options) -- it is free, and easy to use, and more people are familiar and comfortable with it than GCC

only real problem is it cannot be ported to your own OS later


however, it is the official position of this community that everyone should always use the Cross-Compiler

[rdos]

I'm not using a cross-compiler. I'm using OpenWatcom, and since it comes with source, the required libraries can be ported to the target OS, and so can the compiler and the build environment.

However, I've used closed-source compilers before (both MASM and Borland C++), and this is problematic for a number of reasons. First, you either need to support the default libraries for some target the compiler supports, or implement your own without much documentation for how this is done. Then you have a binary for the debugger, which is really tricky to port to your target OS (not impossibe, but tricky). In the case of Borland C++ you basically need to run the Windows debugger in your OS, which requires a large set of Windows emulation DLLs.

I don't know the current state of MSVC as I've not used it for many years, but I doubt it comes with source for debugger (or a well-documented remote-debug API). I also doubt they have documented how to write the OS specific libraries, but if I'm wrong about that, then it might be suitable.

[Love4Boobies]

I don't know the current state of MSVC as I've not used it for many years, but I doubt it comes with source for debugger (or a well-documented remote-debug API). I also doubt they have documented how to write the OS specific libraries, but if I'm wrong about that, then it might be suitable.

I don't use Visual Studio either but I think it might be documented. Even though the open source Singularity is implemented in (an extension of) C#, which probably uses a separate protocol, debugging is performed remotely. If not, we at least know it's possible to do remote debugging for C# without having to do reverse engineering work.

[iansjack]

http://www.brokenthorn.com/Resources/OSDev1.html

As for debugging, I would use an environment such as AMD's SimNow with built in debugger. Alternatively, qemu and gdb are available for Windows. Just because you use MSVC for the development doesn't mean that you can't use other tools also. Once you have a binary to run it doesn't much matter which complier created it.

For OS development you obviously don't link with the libraries supplied with the compiler; why should MSVC be any different in this respect?

But I still wouldn't use Windows for OS development; I tried it and it was too much like hard work. There are better platforms and toolsets available.

(PS. The Windows remote debugging API is fully documented on MSDN.)

[Owen]

As for debugging, I would use an environment such as AMD's SimNow with built in debugger. Alternatively, qemu and gdb are available for Windows. Just because you use MSVC for the development doesn't mean that you can't use other tools also. Once you have a binary to run it doesn't much matter which complier created it.

Except GDB can't read MSVC generated debugging info, if memory serves.

[iansjack]

True. You'll have to use winDbg with qemu. No sweat.