I consider it a bad trend to make separate mobile web pages. The same link will be used by desktop and mobile users, but no matter what page you link to, it will be the wrong page for someone. Instead the page should display correctly for both desktop and mobile; if this is not possible with a common HTML file, just serve different files depending on whether it was accessed from a desktop or mobile browser.
The function main is special, as it is called from code which wasn't written by you. From this alone it follows that it has to be restricted in some way.
And the only thing special to main alone is that you cannot choose its name. Otherwise, there are tons of functions whose argument list and return value are fixed. For example, the functions you pass to qsort, or the functions you pass to signal. Again, those are functions to be called by code not written by you.
It's also defined as the only function that if you reach the end without a return statement, it is implicitly "return 0;"
Did they carry that over to C as well? In C89, it definitely wasn't the case. But then, it wouldn't be the only thing from C++ which made its way into C.
However the program will, if output is successful, return the value 23 which, on most operating systems, will be interrpreted as failure. That's because on success, printf will return the number of characters printed (note that \n is a single character, and the '\0' ending the string is not output, and thus not included in that count). Now the majority of operating systems interprets any return value other than 0 as failure. However, on VMS the program will report success (because VMS interprets any odd exit value as success).
Of course dimeglio's version isn't any good either. It not only completely omits the final \n in the output, it also completely ignores the return value of printf, thus reporting success even if the output failed. And of course if you just want to print a string directly, you'd not use printf anyway, but puts. So the improved code would look like this:
The BIOS initializes all that is needed for a text-mode stopwatch. It would really not be hard to write in asm.
Thus you have to count the BIOS as part of the total code needed.
While USB keyboards work in compatibility mode
In compatibility mode? You mean, the USB port is rewired to an old PS2 mouse port? Or else, how would that not need code? BIOS code is code, too. It was about considering all code needed, remember?
The key installation process could remain completely in the BIOS. First, the OS verifies the boot image with the installed keys. If that fails, it looks for the key in a standardized location. If no key has yet been installed (which means this is the initial installation boot) it just installs that key. Otherwise, it asks the user for a fingerprint of the key, which for bought OS versions can be entered from the installation instructions (very much like the product key today), and for self-signed bootloaders you'd just generate that from the key. Note that at this point no operating system is yet running so unless the BIOS itself is compromised (in which case all protection it might have provided is gone anyway) there's no way any malware could interfere with that process (of course it also must be secured that the initial installation state cannot be reached again except from within the BIOS).
For pre-installed computers, the initial installation would be done by the vendor; if the user wants to install an operating system with another key than the pre-installed one (e.g. wants to switch from Windows to Linux), all he has to do is to enter a key fingerprint found in the documentation when booting up the install disk. For computers bought without OS, even that step is not needed.
I don't know much about servers, but I guess they are generally sold either without OS, or preinstalled with the OS intended to be used. In both cases, there would be no need for user interaction.
This scheme of course leaves a small hole in that you might install your initial OS from compromised installation media (for subsequent installations, that would be caught by the need to enter the fingerprint, unless you are switching vendors and also the documentation was compromised). However I don't think that risk is much higher than the risk of having a compromised BIOS, especially given that end user computers are generally sold pre-installed.
Since the address counter addresses bytes, the corresponding human-level structure would be letters. Or at best words, although even this isn't completely right because words are delimited by non-word characters or white space, while machine level commands don't have any separators (you can jump right in the middle of a command, and the processor will happily interpret the bytes starting there as commands with completely different borders, as long as the bytes starting from there happen to form some valid command pattern.
How a debugger displays the machine code is irrelevant because it translates it into something human readable for display. The processor doesn't look at the debugger output, it looks at the actual bytes in memory. And those are not arranged in lines.
The command line stopwatch app could be coded as a CP/M app.
Which would still use the CP/M code.
Or, in Assembly Language.
Which would probably still make use of the OS or at least the BIOS.
Yes, you could write a stopwatch app which runs on the bare metal, without relying on anything but the hardware (OK, and the part of the BIOS which starts the bootloader, unless you want to re-flash the BIOS). However that would be more complicated than you think. You'd have to initialize all the hardware yourself and handle everything on the lowest level.
The only way the GUI stopwatch to then compete would be to also be written in Assembly Language. Have at it, champ!
Doing a GUI stopwatch on the bare metal would be no more complicated than doing a text stopwatch on the bare metal ("CLI" wouldn't exactly apply then, because without some operating system, there would not be a command line to begin with, unless you'd take the unnecessary complication of additionally writing a CLI to run your stopwatch from). Just the data structures to be copied into video RAM would be a bit bigger. But then, the mouse handling code would probably be much simpler than the keyboard handling code you'd need for the text version.
There's nothing wrong with secureboot as long as you, as the owner of the computer, can install the keys for your OS. Indeed, you should even have the option to only install your own keys (i.e. to remove the installed keys, ideally with the ability to backup), in case you want to make sure nobody installs another operating system than the one you have chosen.
How would entering a bootloader key into an UEFI input box be more complicated than typing a product key into an installer input box, which apparently users managed to do for quite some time?
The redesigned bootloader has already been submitted to Microsoft for singing and once the signed version is received, The Linux Foundation is planning to provide it for free.
Why in hell did the world give Microsoft control over computer bootup hardware?
That's just insane.
Who's going to sing that bootloader at Microsoft? And how will they sing it? In hex? I hope they publish a video of that performance.;-)
So where do I get this STDIN, argv[], STDOUT and STDERR hardware? I somehow cannot find it at the local retailer... or maybe it's code which is called?
It's great that you have finally figured out how to make a comment on Slashdot. Now it's time to advance to the next level: Learn how to make meaningful comments on Slashdot.
And where do you think that code for command line I/O comes from? After all, it isn't as if your console program directly polled the keyboard for scan codes.
Slashdot Mirror
I consider it a bad trend to make separate mobile web pages. The same link will be used by desktop and mobile users, but no matter what page you link to, it will be the wrong page for someone. Instead the page should display correctly for both desktop and mobile; if this is not possible with a common HTML file, just serve different files depending on whether it was accessed from a desktop or mobile browser.
That's the first time I've encountered someone citing true object orientation as a significant shortcoming.
The function main is special, as it is called from code which wasn't written by you. From this alone it follows that it has to be restricted in some way.
And the only thing special to main alone is that you cannot choose its name. Otherwise, there are tons of functions whose argument list and return value are fixed. For example, the functions you pass to qsort, or the functions you pass to signal. Again, those are functions to be called by code not written by you.
Did they carry that over to C as well? In C89, it definitely wasn't the case. But then, it wouldn't be the only thing from C++ which made its way into C.
However the program will, if output is successful, return the value 23 which, on most operating systems, will be interrpreted as failure. That's because on success, printf will return the number of characters printed (note that \n is a single character, and the '\0' ending the string is not output, and thus not included in that count). Now the majority of operating systems interprets any return value other than 0 as failure. However, on VMS the program will report success (because VMS interprets any odd exit value as success).
Of course dimeglio's version isn't any good either. It not only completely omits the final \n in the output, it also completely ignores the return value of printf, thus reporting success even if the output failed. And of course if you just want to print a string directly, you'd not use printf anyway, but puts. So the improved code would look like this:
Thus you have to count the BIOS as part of the total code needed.
In compatibility mode? You mean, the USB port is rewired to an old PS2 mouse port? Or else, how would that not need code?
BIOS code is code, too. It was about considering all code needed, remember?
Users who don't install an operating system also won't need to add a key to the firmware.
The key installation process could remain completely in the BIOS. First, the OS verifies the boot image with the installed keys. If that fails, it looks for the key in a standardized location. If no key has yet been installed (which means this is the initial installation boot) it just installs that key. Otherwise, it asks the user for a fingerprint of the key, which for bought OS versions can be entered from the installation instructions (very much like the product key today), and for self-signed bootloaders you'd just generate that from the key. Note that at this point no operating system is yet running so unless the BIOS itself is compromised (in which case all protection it might have provided is gone anyway) there's no way any malware could interfere with that process (of course it also must be secured that the initial installation state cannot be reached again except from within the BIOS).
For pre-installed computers, the initial installation would be done by the vendor; if the user wants to install an operating system with another key than the pre-installed one (e.g. wants to switch from Windows to Linux), all he has to do is to enter a key fingerprint found in the documentation when booting up the install disk. For computers bought without OS, even that step is not needed.
I don't know much about servers, but I guess they are generally sold either without OS, or preinstalled with the OS intended to be used. In both cases, there would be no need for user interaction.
This scheme of course leaves a small hole in that you might install your initial OS from compromised installation media (for subsequent installations, that would be caught by the need to enter the fingerprint, unless you are switching vendors and also the documentation was compromised). However I don't think that risk is much higher than the risk of having a compromised BIOS, especially given that end user computers are generally sold pre-installed.
Since the address counter addresses bytes, the corresponding human-level structure would be letters. Or at best words, although even this isn't completely right because words are delimited by non-word characters or white space, while machine level commands don't have any separators (you can jump right in the middle of a command, and the processor will happily interpret the bytes starting there as commands with completely different borders, as long as the bytes starting from there happen to form some valid command pattern.
How a debugger displays the machine code is irrelevant because it translates it into something human readable for display. The processor doesn't look at the debugger output, it looks at the actual bytes in memory. And those are not arranged in lines.
Which would still use the CP/M code.
Which would probably still make use of the OS or at least the BIOS.
Yes, you could write a stopwatch app which runs on the bare metal, without relying on anything but the hardware (OK, and the part of the BIOS which starts the bootloader, unless you want to re-flash the BIOS). However that would be more complicated than you think. You'd have to initialize all the hardware yourself and handle everything on the lowest level.
Doing a GUI stopwatch on the bare metal would be no more complicated than doing a text stopwatch on the bare metal ("CLI" wouldn't exactly apply then, because without some operating system, there would not be a command line to begin with, unless you'd take the unnecessary complication of additionally writing a CLI to run your stopwatch from). Just the data structures to be copied into video RAM would be a bit bigger. But then, the mouse handling code would probably be much simpler than the keyboard handling code you'd need for the text version.
On x86, you can -- for now. On ARM, you can't -- at least if it is Windows 8 certified.
There's nothing wrong with secureboot as long as you, as the owner of the computer, can install the keys for your OS. Indeed, you should even have the option to only install your own keys (i.e. to remove the installed keys, ideally with the ability to backup), in case you want to make sure nobody installs another operating system than the one you have chosen.
How would entering a bootloader key into an UEFI input box be more complicated than typing a product key into an installer input box, which apparently users managed to do for quite some time?
The redesigned bootloader has already been submitted to Microsoft for singing and once the signed version is received, The Linux Foundation is planning to provide it for free.
Why in hell did the world give Microsoft control over computer bootup hardware?
That's just insane.
Who's going to sing that bootloader at Microsoft? And how will they sing it? In hex? ;-)
I hope they publish a video of that performance.
So where do I get this STDIN, argv[], STDOUT and STDERR hardware? I somehow cannot find it at the local retailer ... or maybe it's code which is called?
Not only commercial software packages.
But anyway, neither curiosity not the iPhone has brain power. They have processing power, which is something completely different.
1st comment on slashdot
It's great that you have finally figured out how to make a comment on Slashdot. Now it's time to advance to the next level: Learn how to make meaningful comments on Slashdot.
I guess when that hits, it writes a big "bang" into space near its target? :-)
I handed that in long ago when i started sleeping with women and being gainfully employed :D
You're lying. Otherwise, what would you still do here on Slashdot? :-)
Why do I so often feel like I'm in a Douglas Adams novel?
Maybe you're listening to too much bad poetry? :-)
I've never seen a processor whose machine code had lines.
And where do you think that code for command line I/O comes from? After all, it isn't as if your console program directly polled the keyboard for scan codes.
Anonymous Coward doesn't know the difference between one question and three questions ...
What's wrong with just running it through an automatic indentation program?
Right speed.
So why not program in assembler?
Portability.