|
That most believed...So kept it pressed all time...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Sure. The most useless thing ever to be built into a PC because it was the exact opposite of what it claimed to be. It did not magically make the CPU run faster than it's specified clock frequency. Instead it let you switch between full and half clock frequency. Slowing the CPU only makes sense if you want to save power and get longer battery life, but this was not an issue with those old PCs. Heat also was not as a big issue back then, even at full clock frequency.
On top of that, next to the turbo button there often were seven segment LED displays showing the current clock frequency, like 8 or 16 MHz. Those displays did not display the actual clock frequency. They were hardwired with jumpers with two settings which simply depended on wether the turbo button was pressed or not. You could set the display to any number you liked and I always had a little fun to set them to the opposite values for users who always played with the magic turbo button. The display said that the computer was fast and everything got slower.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
There was some software that was dependent on the physical timing of the bus. Some games would run too fast on a new PC with a faster than expected bus. The turbo button slowed the bus, so the software could work correctly.
I don't recall it ever being about power or heat.
|
|
|
|
|
Many games did, in fact it is way easier to run DOS games now with DOSBox than with the physical machines back then
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
|
|
|
|
|
CDP1802 wrote: There often were seven segment LED displays showing the current clock frequency, like 8 or 16 MHz
Oh the memories!!!
|
|
|
|
|
They were great for annoying co-workers.
Because the speed display was seven-segment LED's, the "fast" and "slow" speeds were shown via jumpers.Which if you opened the case you could move around.
So for your PC you showed it running at 77MHz instead of the 33MHz you were lucky to get, and theirs showed 6Mhz @ 33, and 33Mhz at 12...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Magic. Sheer magic.
But, then, personal computers were magic too**.
** Especially for Mechanical engineers like me.
Once, I remember pressing the Reset button instead, and Reset almost meant Redo.
|
|
|
|
|
Go little V20 Go!
|
|
|
|
|
According to MSDN[^], "The main difference between printf_s and printf is that printf_s checks the format string for valid formatting characters, whereas printf only checks if the format string is a null pointer."
So, basically, if I understand correctly, it's not really a security feature as its name implies, it's a debug feature.
The whole "uncontrolled format string" problem it's supposed to solve could be avoided by basic knowledge of what printf actually does.
EDIT: I don't even know why I'm not just using cout
|
|
|
|
|
More importantly, why are you using C ?
Marc
|
|
|
|
|
Good point.
|
|
|
|
|
C is cool.
|
|
|
|
|
Depending on the target system, I would use C anytime. Especially for older systems or microcontrollers C is still a very good choice. For example, I have a C compiler that compiles for the old 6502 CPU. With a relatively simple hardware abstraction layer, you can easily write programs that run on 8 bit Atari computers, 8 bit Commodore computers or an Apple II. I still have several Ataris and also two C64 and can write and compile programs on the PC, test them in emulators and then transfer them to the real thing when finished.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
C is fine ... I use it and will probably keep using it for a few years more. But usually printf in my system ends up in stack overflow, on 8 core 1GHz 2/4/8GB memory.
|
|
|
|
|
printf is not sexist...
OK, I'll take my coat...
|
|
|
|
|
good one
|
|
|
|
|
by "security" what they mean is that additional check(s) are being done.
|
|
|
|
|
tomatopipps wrote: EDIT: I don't even know why I'm not just using cout
The compiletime overhead?
Espen Harlinn
Chief Architect - Powel AS
Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
|
|
|
|
|
Because Microsoft. That's why.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
It's a security feature because by ensuring a parameter is valid, it can prevent unchecked input, crashes and so forth.
https://en.wikipedia.org/wiki/Uncontrolled_format_string[^]
printf has a flexibility and control that cout doesn't provide. I've also found that ostream can be very slow. Not a big deal or console output, but can stack in other places.
|
|
|
|
|
printf (or its secure variants these days) has an economical expressiveness that cout can't provide.
It's interesting that the string.Format(...) model in .NET is more printf -like than anyone would like to admit. Granted, it 'cheats' and uses the CLR type mechanism to guarantee reasonable behavior, but I still like it better than the cout model.
Software Zen: delete this;
|
|
|
|
|
printf has a flexibility and control that cout doesn't provide.
Say what? What kind of flexibility does printf offer that cout lacks? (The entire purpose for cout's existence is to be more flexible than printf)
Truth,
James
|
|
|
|
|
James Curran wrote: What kind of flexibility does printf offer that cout lacks?
for one example, I find:
printf("%0.3f %.2f", x, p);
More clear and concise than:
cout << std::fixed << std::setprecision(3) << x << " " << std::defaultfloat << std::setprecision(3) << p;
Also, something like a logging function where the formatting happens after a series of checks, is easier to write using the printf family.
Finally, using snprintf family can be extremely useful, especially in combination with the logging issue.
PS. In several cases, I do prefer the ostream family. It all depends on what I'm trying to accomplish with the code. (There is a huge chunk of diagnostic code in the project I'm current working on which uses lots of CString::Format (snprintf_s internally), which would be a whole lot more readable using ostringstream, but I'd likely be shot if I changed it.)
EDIT: Visual Studio 2010 and especially 2013 have really optimized ostream functionality. I wrote a quick test using some code from the aforementioned project. Using ostringstream was 17% faster than CString::AppendFormat with VS 2010 and 30% faster with VS 2013. I wouldn't be surprised if VS 2015 offers more improvement.
|
|
|
|
|
aha... But you didn't say "concise" you said "flexible".
I totally agree, printf is way more concise that cout, but for flexibility :
Point p(2,3);
cout << p << endl;
beats
printf("(%d, %d)\n", p.x, p.y);
Truth,
James
|
|
|
|