Then this whole thread is a waste of time, based on the Subject heading.john765 wrote:I do know C and Assembly.
As if that wasn't already obvious.
Then this whole thread is a waste of time, based on the Subject heading.john765 wrote:I do know C and Assembly.
Are you going to at some point put some effort into your messages? Like GCC shows what error? Try to think thru what possible information people would need so they can help you, but not spamming them with everything (like dumping your entire code on the forum)..john765 wrote: It shows a blank screen. What's wrong with -fwritable-strings? I add it to my GCC parameters but shows an error.
Not for creating a new account, no, as his old account was no longer valid (unlike AT555, he wsn't trying to circumvent a standing ban; he had deleted his old account login when he ragequit, so he couldn't use it any more when he decided to return). The mods did reprimand him for it, though, and IIRC he did get warned several times before then that he was likely to be banned if he didn't follow forum rules.john765 wrote:Did DixiumOS get banned?
It's a beginner who can't take advice, has no interest in learning, and gets angry when someone else won't do all their work for them. Plenty of beginners don't do that.john765 wrote: You wasted your time talking about these idiots who have no life? I would watch TV more if I wanted to hear this. Some people are evil enough to actually do things.
Andrew and Nuno's life stories are worth reading? Sure, I'll read them! By the way, why would there be so many people similar? Let me guess. It's probably a beginner.
I do know C and Assembly.
By the way, can you answer my question about the write_string() function please? It's in printing text in protected mode. I tried it out but it won't work. The -fwritable-strings doesn't work.
DoS and DDoS attacks are simple these days. Many people do them. The proper word for it is stress. People hack more things than others expect, no matter if a website just has info about fish.
Did DixiumOS get banned?
john765 wrote:It shows a blank screen.Schol-R-LEA wrote:Short answer, yes. [...] I am guessing that the real question is more along the lines of, "Why didn't this work for me?" If so, then we'd need more information on how you have things set up.john765 wrote:http://wiki.osdev.org/Printing_to_Screen seems hard. How do I do the parameter for write_string() function? In my main, do I do
or not?Code: Select all
write_string(0x07, "Hello World!");
Could you please post the error message? I am puzzled why you are using this switch, though, as, despite the similarities in the names, the switch is unrelated to the function.john765 wrote:What's wrong with -fwritable-strings? I add it to my GCC parameters but shows an error.
For the last time, I am not andrewthompson555. Why would anyone think I am Andrew? Do you even have proof? It's like you think someone is this person if they are the same as 90% of the people on Earth.glauxosdever wrote:Hi,
john765 is/was a andrewthompson555 puppet (according to Brendan). He has been banned I think.
Regards,
glauxosdever
http://wiki.osdev.org/Printing_to_ScreenOK, we can work with that. The wiki page in question has a section entitled Troubleshooting, and the first subsection there discusses one possible cause.
This leads to the question of how you have the console initialized. How are you running the test program? Assuming you are running it in your own OS, how does your OS boot, and how does it set up the console? How is the OS built? Have you been able to get a displayed message at any point during or after booting?
For now, I will work from the assumption that you are following the Bare Bones setup, and that you have the following set up and ready to go. I intend to cover things in pretty close and perhaps insultingly obvious detail, but this is not meant as a slight, I am merely being thorough.
- A computer of some sort running either Windows, Linux, or MacOS X (OK, that's a gimme, I'm just being facetious. OTOH, if you are using someone else's computer - say, in a university computer lab - and might have to move your setup to a different one from time to time, you may want to let us know, as some of the usual advice involves installing software and you would need to set it up on a flash drive or something similar.)
- An emulator or virtualizer such as Bochs, QEMU, HyperV, VirtualBox, etc. to test your OS in. While you can test on live hardware, the turnaround when working with a emu is much faster, and there is vastly less risk of overwriting the MBR of your development host.
- A version-control program (e.g., git, Subversion, darcs, mercurial, bazaar - doesn't matter which, so long as you are comfortable with it) and an account on an offsite VCS host such as Github where you can set up a repo for your code. No, I am not kidding, and yes, you need one and you need to commit to it as often as reasonably possible. Trust me, this is absolutely vital, no matter how pointless it might seem now. The first time you trash your codebase (you will trash your codebase - EVERYBODY trashes their codebase from time to time), you'll regret it if you don't have one.
- A working build toolchain - assembler, compiler, linker, etc. - targeting your development host. This should include a tool for raw-writing data to files and/or disks, such as the Unix dd(1) utility. Almost all Linux distros come with the Binutils toolchain, including GCC and gas, and can download tools like NASM pretty easily (presumably you'd know which distro you use and which package manager the distro uses). Under the GUI, MacOS X is also a Unixoid system, and should have binutils already too; if not, they are included in the XCode package. For Windows, if you are using the GNU toolchain, you will probably want to use the Cygwin package, which provides a Unix-like development environment and a port of the BASH shell. If you are using the Microsoft toolchain, there are pages on the wiki that give details for that as well.
- A GCC Cross-Compiler targeting your the platform you are building your OS for, or the source code for a compiler you can then build for x-building. The xcompiler needs to be different from the dev host compiler - it can be the same compiler from the same source code, and can target the same hardware platform, in the same executable format, but you need the compiler and assembler output set up to build for your OS, and more importantly, you need to have it link to your OS's libraries, not the dev host's. You will eventually need to build an OS Specific Toolchain as well, but that's not immediately necessary and has to wait on the x-compiler anyway.
- A Bootloader, either preexisting or one you wrote yourself. Since we're talking the Bare Bones suite, you want GRUB 2.
Look this over quickly and let me know if you have all of that ready. Otherwise, we can help you get it set up.
Could you please post the error message? I am puzzled why you are using this switch, though, as, despite the similarities in the names, the switch is unrelated to the function.john765 wrote:What's wrong with -fwritable-strings? I add it to my GCC parameters but shows an error.
As StudlyCaps mentioned, the switch enables writing to - that is to say, altering - strings initialized through string literals in the source code. String literals are normally kept in the program's .rodata section (read-only data preinitialized by the compiler or assembler, and set by the OS to set of a protection exception of the program writes to it after the data is loaded). The switch disables a number of optimizations and memory protection features which normally are better left on, but sometimes need to be disabled (mostly for debugging purposes, and almost never in production code).
Code: Select all
void write_string( int colour, const char *string )
{
volatile char *video = (volatile char*)0xB8000;
while( *string != 0 )
{
*video++ = *string++;
*video++ = colour;
}
}
If you think GitHub and SewageOverflow are better, why don't you go there instead? I don't go to either of those sites often (primarily because I got banned and an no longer welcome, but I digress), but I still doubt the telepathic ability of the users of any other website.john765 wrote:GitHub wouldn't be like this to me you know. Stackoverflow don't complain every single time.
john765 wrote:http://wiki.osdev.org/Printing_to_ScreenOK, we can work with that. The wiki page in question has a section entitled Troubleshooting, and the first subsection there discusses one possible cause.
This leads to the question of how you have the console initialized. How are you running the test program? Assuming you are running it in your own OS, how does your OS boot, and how does it set up the console? How is the OS built? Have you been able to get a displayed message at any point during or after booting?
For now, I will work from the assumption that you are following the Bare Bones setup, and that you have the following set up and ready to go. I intend to cover things in pretty close and perhaps insultingly obvious detail, but this is not meant as a slight, I am merely being thorough.
- A computer of some sort running either Windows, Linux, or MacOS X (OK, that's a gimme, I'm just being facetious. OTOH, if you are using someone else's computer - say, in a university computer lab - and might have to move your setup to a different one from time to time, you may want to let us know, as some of the usual advice involves installing software and you would need to set it up on a flash drive or something similar.)
- An emulator or virtualizer such as Bochs, QEMU, HyperV, VirtualBox, etc. to test your OS in. While you can test on live hardware, the turnaround when working with a emu is much faster, and there is vastly less risk of overwriting the MBR of your development host.
- A version-control program (e.g., git, Subversion, darcs, mercurial, bazaar - doesn't matter which, so long as you are comfortable with it) and an account on an offsite VCS host such as Github where you can set up a repo for your code. No, I am not kidding, and yes, you need one and you need to commit to it as often as reasonably possible. Trust me, this is absolutely vital, no matter how pointless it might seem now. The first time you trash your codebase (you will trash your codebase - EVERYBODY trashes their codebase from time to time), you'll regret it if you don't have one.
- A working build toolchain - assembler, compiler, linker, etc. - targeting your development host. This should include a tool for raw-writing data to files and/or disks, such as the Unix dd(1) utility. Almost all Linux distros come with the Binutils toolchain, including GCC and gas, and can download tools like NASM pretty easily (presumably you'd know which distro you use and which package manager the distro uses). Under the GUI, MacOS X is also a Unixoid system, and should have binutils already too; if not, they are included in the XCode package. For Windows, if you are using the GNU toolchain, you will probably want to use the Cygwin package, which provides a Unix-like development environment and a port of the BASH shell. If you are using the Microsoft toolchain, there are pages on the wiki that give details for that as well.
- A GCC Cross-Compiler targeting your the platform you are building your OS for, or the source code for a compiler you can then build for x-building. The xcompiler needs to be different from the dev host compiler - it can be the same compiler from the same source code, and can target the same hardware platform, in the same executable format, but you need the compiler and assembler output set up to build for your OS, and more importantly, you need to have it link to your OS's libraries, not the dev host's. You will eventually need to build an OS Specific Toolchain as well, but that's not immediately necessary and has to wait on the x-compiler anyway.
- A Bootloader, either preexisting or one you wrote yourself. Since we're talking the Bare Bones suite, you want GRUB 2.
Look this over quickly and let me know if you have all of that ready. Otherwise, we can help you get it set up.
Could you please post the error message? I am puzzled why you are using this switch, though, as, despite the similarities in the names, the switch is unrelated to the function.john765 wrote:What's wrong with -fwritable-strings? I add it to my GCC parameters but shows an error.
As StudlyCaps mentioned, the switch enables writing to - that is to say, altering - strings initialized through string literals in the source code. String literals are normally kept in the program's .rodata section (read-only data preinitialized by the compiler or assembler, and set by the OS to set of a protection exception of the program writes to it after the data is loaded). The switch disables a number of optimizations and memory protection features which normally are better left on, but sometimes need to be disabled (mostly for debugging purposes, and almost never in production code).
The printing strings section is where you get the code.
Then, I put in my kernel main (just this is in my kmain):Code: Select all
void write_string( int colour, const char *string ) { volatile char *video = (volatile char*)0xB8000; while( *string != 0 ) { *video++ = *string++; *video++ = colour; } }
write_string(0x07, "Hello World!");
I try it out on VirtualBox but Hello World! won't show. It says if you have missing strings, you use -fwritable-strings. However, I add that parameter and it comes up with an error. Is there something wrong? Do I need to setup anything for this to work?
Why is this? How can I fix that?
By the way, I am not andrewthompson555 or Nunolava1998.
GitHub wouldn't be like this to me you know. Stackoverflow don't complain every single time.
If he had followed Bare Bones properly, this wouldn't be the case. We'll see whether your solution resolves the question.Schol-R-LEA wrote:In this case, the solution - which is the solution that the wiki should have emphasized more in the first place - is to add an .rodata section to your linker script.