Actually, the compiler won't accept (C++)++ because the result of (C++) is not an lvalue, it's a const temporary, and you can't ++ it. You could write (C++)+1, though.
How does BeOS send you messages, then? Does each window have a massive virtual function table, or is there some trickery involved? (Which is all MFC message maps are, of course...) Andrew.
Totally over my head? Clue: I *am* a game programmer, and I don't even particularly like Linux (although one day it might be better for games...) I know very well about PSX coding, thank you. But I don't know anyone who wrote an entire PSX game in asm. We came pretty close on the Atari Jaguar, though. Yes, it is great to have an advantage, but if everyone is doing it, then where's the advantage? Anyway, the real advantage comes from spending time making your game fun to play, not pissing about re-inventing the TCP/IP stack all the time. Who the **** was talking about a general purpose OS? Windows CE on the Dreamcast is cut down, it doesn't even include GDI... And BTW, "transparancy, something playstation isn't technically supposed to be able to do"... Well, OK, so you really don't know what the **** you're talking about.
OK, sorry, but: WRONG, BZZZT, you're going home with our special matching Slashdot tie and blazer badge set, that's yours, no-one can take that away from you, you've been a very special contestant, Good Night! The Dreamcast runs either with a set of Sega libraries, or a cut down version of Windows CE. Sega Rally used an early version of Windows CE, but it has been much improved since then. While it is true that the Playstation doesn't have much need for a full OS, it's not that much of a statement. The Playstation has no MMU. It has 2MB of main RAM. Its only networking capability is through a dodgy serial link. Modern consoles are a whole lot more complicated. While it is great fun playing with your MMU and writing TCP/IP stacks, we game programmers have better things to do, like writing games. I'm not an OS programmer, nor do I want to be one, but many people are and I defer to them. Another thing you're missing is that while the Playstation OS fits in 32K, the libraries you use to access the hardware are not included in that amount. You sacrifice your 0x1f8000 bytes according to your needs. The actual overhead of Windows CE is not as large as some have made it out to be, and compared to using the Sega libraries, you gain a lot of functionality. Of course, I don't expect everyone to flock to it, because many game developers are still too busy trying to prove how studly they are at poking hardware. It's such a pity, because everyone spends a couple of years falling into the same traps. Step 1: Plug in your shiny new dev kit Step 2: Read the docs saying, "Don't do X to the hardware! It will be slow!" Step 3: Watch the mailing list as punters from 15 different game companies flood the mailing lists with, "How can I do X to the hardware, in asm, by poking it directly?" Sigh...
If it is hard to pack things into boxes, it is only a mechanical problem. Finding an optimal solution is hard, but my Sinclair ZX-81 would beat you at that (if you disallow RAM-Pack wobbling:)
Who the hell moderated my post to "Troll"? We just had a really good discussion on this stuff. What part of "Troll" do you not understand? Maybe it was a slip of the mouse...
Heh, well maybe not so violent:) But, the devil is in the details:) And as I thought of my reply I remembered the old Emo Phillips gag, which I trawled the 'net for, and here it is... (Score: -1 for Off Topic, +10 for Funny) ----------------- I was walking across a bridge one day, and I saw a man standing on the edge, about to jump off. So, I ran over and said, "Stop! Don't do it!" "Why shouldn't I?" he said. I said, "Well, there's so much to live for!" He said, "Like what?" I said, "Well...are you Religious or Atheist?" He said, "Religious." I said, "Me too! Are you Christian or Buddhist?" He said, "Christian." I said, "Me too! Are you Catholic or Protestant?" He said, "Protestant." I said, "Me too! Are you Episcopalian or Baptist?" He said, "Baptist!" I said, "Wow! Me too! Are you Baptist Church of God, or Baptist Church of the Lord?" He said, "Baptist Church of God!" I said, "Me too! Are you Original Baptist Church of God, or are you Reformed Baptist Church of God?" He said, "Reformed Baptist Church of God!" I said, "Me too! Are you Reformed Baptist Church of God, Reformation of 1879, or Reformed Baptist Church of God, Reformation of 1915?" He said, "Reformed Baptist Church of God, Reformation of 1915!" I said, "Die, Heretic Scum...", and pushed him off.
OK, but how about this scenario: I want to hold a number from 0 to 1,000,000. It's too big for the lowest common denominator (16 bits) so I whack it in a long. On a machine with 64 bit ints, I just went sub-optimal. So the whole idea of 'int' as this optimal size is fairly useless in practice, IMHO. What I really want to do is tell the compiler "I want to store 0..1000000" and let it sort it all out. Then I can decide whether I want to compile for size or speed [at runtime, in the spirit of this article], or if I definitely want that value in a long because some other code needs it to be that size.
Well, my post wasn't moderated up, I'm not an AC so I get 1 by default. I do think the funny post should definately be modded up, but I have no moderation points and I have already posted to this article...
In some ways I agree with you, OK, I love writing assembler stuff. But I'm trying to separate fantasy from the reality here. The fantasy is that you're some super studly asm c0der who can not only produce properly scheduled code, but also has the time to *completely re-write* it: a) For each new processor b) For each sub-type of that processor with different internal resources c) Every time the specification changes - Maybe you have limited the range of a variable or something. Any of these changes will require a huge amount of work. Even a small change, coupled with the pipelined nature of modern processors, means a large modification to re-establish optimal resource usage. The reality is that no-one has the time to do this, and even if they do, they should be doing something else instead. High level optimizations almost always beat low level tweaking. In addition, I simply don't believe it's impossible to a) Tell the compiler in more detail how to optimise your code b) Have the compiler suggest ways in which it could produce better code (for example, "Is it OK to assume there is no aliasing of this item?" or "Hey, if I make this variable 8 bits in size I can do this huge optimization") c) Have the compiler work this stuff out for itself d) As (c) but at run time, guided by profiling information. Some of those are hard to do right now, but I don't see anything that would make them impossible. Does anyone?
This is a language issue, not a compiler issue. For example, C lets you declare a variable as a char, short, long etc. Many x86 compilers will do the optimization you described in this case. Yes, a certain class of optimizations comes from putting limits on the range of your variables. Unfortunately, this often leads to stupid and unacceptable limitations. It's much better to have a language where there isn't any inherent limit (or {32|64|...} bits is "enough"). If you can also tell the compiler what range of values are legal, it can optimize as necessary. Please note that using 8 bit registers is in many cases *slower* than using 32 bit registers on the Pentium Pro and above. Yes, you get more of them, but the performance penalty can be quite high.
Well for what it's worth (probably not much) here's my perspective on it...
Someone has spent time and money making a film (or whatever) and they are entitled to a reasonable return on that investment. So they sell the DVD to you. OK, so you can watch it, feed it to your dog, whatever, that's OK because you have bought it and the film dude has made his dough. You get curious about the encryption, it's an intellectual challenge and you crack it. Fine, no problem. You watch DVDs on your Linux box... No one cares! Mr. Director is happy, maybe he's a nerd himself... The only thing that causes a problem is when someone would have coughed up the wonga, but decides not to, and makes a copy instead. Making a copy and giving it to a friend is an example of this. I say: Yes, you can do anything you want to the stuff you buy, *except devalue other copies of the work*. Unless, of course, you just want to dis the vendor because his product sucks, in which case you can do that, but the vendor isn't going to like you because he will get something like 26 complaints for each bit of praise. Negative criticism sucks, unless you're the one doing the criticising... But I digress. [Of course it has already been established that in this case, the crack has little to do with copy protection as it is a playback issue... {But it has a lot to do with country protection (But that sucks very hard [But there is a reason for it {But it's not a very good one}])}]
Because let's face it, that's what all this is really about - The codes were cracked because codes just sit there saying 'Please crack me!' Sure, you can now watch/crack DVDs on your Linux box, but that's just a bonus...
Re:Score him a troll, but a troll with a point!
on
Hole in GNU GPL?
·
· Score: 1
This is indeed interesting. I'm a closed source developer (games). I haven't used any GPLed source so far (because it's all crap, haha [ducks]:)
Isn't there some sort of percentage of the original, under which it's OK to borrow from copyrighted work? In which case, the GPL cannot help.
A lot of people say "security through obscurity doesn't work." Well, in this case (open/closed source) it does work in a way. What's to stop me from looking at some GPLed source and rewriting it in my own style? Being able to look at the way someone else did something might make it a whole load easier [than disassembling binaries]. You can't do anything about it, because my source will be significantly different to the original, and the only protection you have is to patent the *method*. Which isn't really the Open Source Way, is it?
I think a lot of closed source programmers would happily distribute improvements to GPLed source. The problem comes with section 2b of the GPL, "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
Well, I guess that bit is pretty much the most important part of the GPL:( It's basically saying, "if you are a closed source developer, don't even look at this code!". Which is fair enough, I suppose, but the point is that closed source developers are going to be ripping off GPLed code left right and centre, and there's very little you can do about it.
I think this is interesting because you can look at the open and closed source communities as having two different strategies in an evolutionary sense. Is open source an evolutionary stable strategy (ESS)? Or is closed source, for that matter? If you publish your source code, you make it very easy for others to be parasitic. This might give the advantage to closed source developers, because they can let open source do all the drudge work while they implement the fun stuff on top of it (and who could not resist the temptation to say "Suckers" while at it). And of course we have heard the supposed advantages of open source many times...
In time we will find out how the strategies evolve, but for now it's just a fascinating subject...
The point is, it may look better to you, but not to anyone who a) knows what they are talking about and b) makes purchasing decisions in this area. RAM is always quoted in bits. What are the poor guys to do, quote it as if it only had 8 bits per byte, to level the playing field? I don't think so. Give them a break...
Oh please. They don't sell these things directly to Joe Public, and even if they did, if you bought one for your non-Intel, non-parity based system, it probably wouldn't even fit in the slot.
Well of course there are no *letters* at all in Japanese. There are syllables, which can be written with hiragana or katanana (or Kanji but that's more complicated...) The 'r' in the syllables 'ra','ri','ru','re','ro' sounds more like an 'l' with a hint of 'd'.
I haven't seen the katakana for the Pokemon character in question, but I would guess it would be romanized as 'ungeraa'.
A previous poster's comment about katakana 'ri' and 'n' being similar is an interesting one ('uri' -> 'un'), but actually the katakana for 'ri' is closer to 'so'.
That falls into the class of comments that are so offensive they simply shouldn't be made - even in jest. I tried to imagine being enough of a cretin to post such a remark, but failed. You, sir, are an idiot.
Slashdot Mirror
Actually, the compiler won't accept (C++)++ because the result of (C++) is not an lvalue, it's a const temporary, and you can't ++ it.
You could write (C++)+1, though.
How does BeOS send you messages, then? Does each window have a massive virtual function table, or is there some trickery involved? (Which is all MFC message maps are, of course...)
Andrew.
Totally over my head?
Clue: I *am* a game programmer, and I don't even particularly like Linux (although one day it might be better for games...)
I know very well about PSX coding, thank you.
But I don't know anyone who wrote an entire PSX game in asm. We came pretty close on the Atari Jaguar, though.
Yes, it is great to have an advantage, but if everyone is doing it, then where's the advantage? Anyway, the real advantage comes from spending time making your game fun to play, not pissing about re-inventing the TCP/IP stack all the time.
Who the **** was talking about a general purpose OS? Windows CE on the Dreamcast is cut down, it doesn't even include GDI...
And BTW, "transparancy, something playstation isn't technically supposed to be able to do"... Well, OK, so you really don't know what the **** you're talking about.
OK, sorry, but: WRONG, BZZZT, you're going home with our special matching Slashdot tie and blazer badge set, that's yours, no-one can take that away from you, you've been a very special contestant, Good Night!
The Dreamcast runs either with a set of Sega libraries, or a cut down version of Windows CE. Sega Rally used an early version of Windows CE, but it has been much improved since then.
While it is true that the Playstation doesn't have much need for a full OS, it's not that much of a statement. The Playstation has no MMU. It has 2MB of main RAM. Its only networking capability is through a dodgy serial link.
Modern consoles are a whole lot more complicated. While it is great fun playing with your MMU and writing TCP/IP stacks, we game programmers have better things to do, like writing games. I'm not an OS programmer, nor do I want to be one, but many people are and I defer to them.
Another thing you're missing is that while the Playstation OS fits in 32K, the libraries you use to access the hardware are not included in that amount. You sacrifice your 0x1f8000 bytes according to your needs. The actual overhead of Windows CE is not as large as some have made it out to be, and compared to using the Sega libraries, you gain a lot of functionality.
Of course, I don't expect everyone to flock to it, because many game developers are still too busy trying to prove how studly they are at poking hardware. It's such a pity, because everyone spends a couple of years falling into the same traps.
Step 1: Plug in your shiny new dev kit
Step 2: Read the docs saying, "Don't do X to the hardware! It will be slow!"
Step 3: Watch the mailing list as punters from 15 different game companies flood the mailing lists with, "How can I do X to the hardware, in asm, by poking it directly?"
Sigh...
If it is hard to pack things into boxes, it is only a mechanical problem. Finding an optimal solution is hard, but my Sinclair ZX-81 would beat you at that (if you disallow RAM-Pack wobbling :)
Who the hell moderated my post to "Troll"? We just had a really good discussion on this stuff. What part of "Troll" do you not understand? Maybe it was a slip of the mouse...
Heh, well maybe not so violent :) :) And as I thought of my reply I remembered the old Emo Phillips gag, which I trawled the 'net for, and here it is...
But, the devil is in the details
(Score: -1 for Off Topic, +10 for Funny)
-----------------
I was walking across a bridge one day, and I saw a man standing on the
edge, about to jump off. So, I ran over and said, "Stop! Don't do it!"
"Why shouldn't I?" he said.
I said, "Well, there's so much to live for!"
He said, "Like what?"
I said, "Well...are you Religious or Atheist?"
He said, "Religious."
I said, "Me too! Are you Christian or Buddhist?"
He said, "Christian."
I said, "Me too! Are you Catholic or Protestant?"
He said, "Protestant."
I said, "Me too! Are you Episcopalian or Baptist?"
He said, "Baptist!"
I said, "Wow! Me too! Are you Baptist Church of God, or Baptist Church
of the Lord?"
He said, "Baptist Church of God!"
I said, "Me too! Are you Original Baptist Church of God, or are you
Reformed Baptist Church of God?"
He said, "Reformed Baptist Church of God!"
I said, "Me too! Are you Reformed Baptist Church of God, Reformation of
1879, or Reformed Baptist Church of God, Reformation of 1915?"
He said, "Reformed Baptist Church of God, Reformation of 1915!"
I said, "Die, Heretic Scum...", and pushed him off.
OK, but how about this scenario: I want to hold a number from 0 to 1,000,000. It's too big for the lowest common denominator (16 bits) so I whack it in a long. On a machine with 64 bit ints, I just went sub-optimal.
So the whole idea of 'int' as this optimal size is fairly useless in practice, IMHO.
What I really want to do is tell the compiler "I want to store 0..1000000" and let it sort it all out. Then I can decide whether I want to compile for size or speed [at runtime, in the spirit of this article], or if I definitely want that value in a long because some other code needs it to be that size.
Well, my post wasn't moderated up, I'm not an AC so I get 1 by default. I do think the funny post should definately be modded up, but I have no moderation points and I have already posted to this article...
In some ways I agree with you, OK, I love writing assembler stuff.
But I'm trying to separate fantasy from the reality here.
The fantasy is that you're some super studly asm c0der who can not only produce properly scheduled code, but also has the time to *completely re-write* it:
a) For each new processor
b) For each sub-type of that processor with different internal resources
c) Every time the specification changes - Maybe you have limited the range of a variable or something.
Any of these changes will require a huge amount of work. Even a small change, coupled with the pipelined nature of modern processors, means a large modification to re-establish optimal resource usage.
The reality is that no-one has the time to do this, and even if they do, they should be doing something else instead. High level optimizations almost always beat low level tweaking.
In addition, I simply don't believe it's impossible to
a) Tell the compiler in more detail how to optimise your code
b) Have the compiler suggest ways in which it could produce better code (for example, "Is it OK to assume there is no aliasing of this item?" or "Hey, if I make this variable 8 bits in size I can do this huge optimization")
c) Have the compiler work this stuff out for itself
d) As (c) but at run time, guided by profiling information.
Some of those are hard to do right now, but I don't see anything that would make them impossible.
Does anyone?
One would hope that it doesn't loop waiting for input. One would hope that it goes to sleep until the operating system provides input.
LOL
That's cool as long as you never want to store a number larger than 32767 or 65535u...
This is a language issue, not a compiler issue.
For example, C lets you declare a variable as a char, short, long etc.
Many x86 compilers will do the optimization you described in this case.
Yes, a certain class of optimizations comes from putting limits on the range of your variables. Unfortunately, this often leads to stupid and unacceptable limitations. It's much better to have a language where there isn't any inherent limit (or {32|64|...} bits is "enough"). If you can also tell the compiler what range of values are legal, it can optimize as necessary.
Please note that using 8 bit registers is in many cases *slower* than using 32 bit registers on the Pentium Pro and above. Yes, you get more of them, but the performance penalty can be quite high.
Well for what it's worth (probably not much) here's my perspective on it...
Someone has spent time and money making a film (or whatever) and they are entitled to a reasonable return on that investment. So they sell the DVD to you.
OK, so you can watch it, feed it to your dog, whatever, that's OK because you have bought it and the film dude has made his dough.
You get curious about the encryption, it's an intellectual challenge and you crack it. Fine, no problem.
You watch DVDs on your Linux box... No one cares! Mr. Director is happy, maybe he's a nerd himself...
The only thing that causes a problem is when someone would have coughed up the wonga, but decides not to, and makes a copy instead.
Making a copy and giving it to a friend is an example of this. I say: Yes, you can do anything you want to the stuff you buy, *except devalue other copies of the work*.
Unless, of course, you just want to dis the vendor because his product sucks, in which case you can do that, but the vendor isn't going to like you because he will get something like 26 complaints for each bit of praise. Negative criticism sucks, unless you're the one doing the criticising... But I digress.
[Of course it has already been established that in this case, the crack has little to do with copy protection as it is a playback issue... {But it has a lot to do with country protection (But that sucks very hard [But there is a reason for it {But it's not a very good one}])}]
Heh, they should add:
D. No, that's why the codes are there.
Because let's face it, that's what all this is really about - The codes were cracked because codes just sit there saying 'Please crack me!'
Sure, you can now watch/crack DVDs on your Linux box, but that's just a bonus...
Isn't there some sort of percentage of the original, under which it's OK to borrow from copyrighted work? In which case, the GPL cannot help.
A lot of people say "security through obscurity doesn't work." Well, in this case (open/closed source) it does work in a way. What's to stop me from looking at some GPLed source and rewriting it in my own style? Being able to look at the way someone else did something might make it a whole load easier [than disassembling binaries]. You can't do anything about it, because my source will be significantly different to the original, and the only protection you have is to patent the *method*. Which isn't really the Open Source Way, is it?
I think a lot of closed source programmers would happily distribute improvements to GPLed source. The problem comes with section 2b of the GPL,
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
Well, I guess that bit is pretty much the most important part of the GPL :( It's basically saying, "if you are a closed source developer, don't even look at this code!". Which is fair enough, I suppose, but the point is that closed source developers are going to be ripping off GPLed code left right and centre, and there's very little you can do about it.
I think this is interesting because you can look at the open and closed source communities as having two different strategies in an evolutionary sense. Is open source an evolutionary stable strategy (ESS)? Or is closed source, for that matter? If you publish your source code, you make it very easy for others to be parasitic. This might give the advantage to closed source developers, because they can let open source do all the drudge work while they implement the fun stuff on top of it (and who could not resist the temptation to say "Suckers" while at it). And of course we have heard the supposed advantages of open source many times...
In time we will find out how the strategies evolve, but for now it's just a fascinating subject...
What if it was in the keyspace *after* the part that had to be redone?
So much for your logic...
Uhh, why?
The point is, it may look better to you, but not to anyone who a) knows what they are talking about and b) makes purchasing decisions in this area. RAM is always quoted in bits. What are the poor guys to do, quote it as if it only had 8 bits per byte, to level the playing field? I don't think so. Give them a break...
Oh please. They don't sell these things directly to Joe Public, and even if they did, if you bought one for your non-Intel, non-parity based system, it probably wouldn't even fit in the slot.
Godwin's law - You lose.
Sorry, I was not specific enough. I was referring to post #63.
I'm with you. At first like most people I slapped my forehead and moaned, "Oh no, please, not again!"
I mean, so many times we have all said "The Amiga is DEAD, [insert Amiga zealot bait here]"...
But then I thought, "Yeah but somehow I'm *still* saying it... So paradoxically it's not dead at all, in some sort of f##ked up kind of way!"
And to heck with it all, I'm sick to death of Linux hype. I really miss the Amiga guys... Come back, all is forgiven!
RA RA RASPUTIN!
THE AMIGA IS DEAD! LONG LIVE THE AMIGA!
Well of course there are no *letters* at all in Japanese. There are syllables, which can be written with hiragana or katanana (or Kanji but that's more complicated...)
The 'r' in the syllables 'ra','ri','ru','re','ro' sounds more like an 'l' with a hint of 'd'.
I haven't seen the katakana for the Pokemon character in question, but I would guess it would be romanized as 'ungeraa'.
A previous poster's comment about katakana 'ri' and 'n' being similar is an interesting one ('uri' -> 'un'), but actually the katakana for 'ri' is closer to 'so'.
Just my 2 yen. Disclaimer: I'm not Japanese.
Andrew.
That falls into the class of comments that are so offensive they simply shouldn't be made - even in jest.
I tried to imagine being enough of a cretin to post such a remark, but failed.
You, sir, are an idiot.