WinCE has a very large subset of desktop Win32 APIs. Of course it's not binary compatible, we're mostly talking about ARM platforms on 'phones.
Linux has the whole apt-get/aptitude/whatever thing but that's not going to be the draw in the mobile space. Something based on it maybe, but it's gonna have to be a whole lot more user friendly to compete with the App Store etc. Even if it's more free(TM)... And of course few people are going to develop for it if there's no return on their investment.
Linux makes a large amount of sense on a nerd targeted netbook, in fact as a mostly Windows user I might switch to something like that, but the mass market is still not driven by the forces you would like.
Whatever you think about Microsoft (and if it's the usual cult mentality, I really don't care) Microsoft have screwed up pretty badly (more than normal, if you will) on WM7.
It's hella late and they have pissed off a lot of people. I would personally really like to see Microsoft's continual presence in the mobile space if only for the sake of diversity... I'm unashamedly a Microsoft user and mostly supporter. Downmods be damned. But WM7 is pretty much a disaster area.
I hope they have something really good on the way... And even then, I worry that they're gonna let Android rule the world. Which is careless, because Android used to suck. But it's getting better very quickly, and there's still no sign of WM7.
No, in C such operators can take any nonzero value as true, but always produce 1 for a true result. In C++ they produce bool false/true and those convert to int as 0/1.
Re:IDA is a dissassembler
on
The IDA Pro Book
·
· Score: 2, Informative
I read and re-read MarkusQ's comment and he isn't describing IDA Pro as a decompiler at all, in fact he's explicity saying "It can't of course give you back the actual source code". The decompiler is called Hex-Rays, it's built on top of IDA Pro and is available from the same guys at hex-rays.com. (Not advertising, just a long time happy IDA Pro customer).
Only Northern Ireland is in the UK. It's also not in Great Britain. The UK is short for "The United Kingdom of Great Britain and Northern Ireland (and dependent territories)"
Speculative execution can cause your RDTSC to give you odd results, for sure. It's normal to do a CPUID first to serialize everything. But I'm quite surprised that time would go backwards on a single core. The minimum sequence would be something like: rdtsc mov ebx, eax mov ecx, edx rdtsc (sub eax, ebx
sbb edx, ecx) I can't quite imagine the second rdtsc being executed before the first, even with out of order execution. But I'd love to know if anyone has ever seen it happen:)
I also said as much in post #21671495 - If played well, the Scout can certainly hold his own in combat. But in this article we're looking at the latest stats from Valve. The stats show that people are not getting so many kills with the Scout. You say "Lots of people go scout for killing", but the stats show that it's not as effective as you think. They also show that Scouts get by far the most captures. Which is cool, because the Scout's role is primarily as a capture monkey. I'm sure it would be interesting to the stats broken down by player skill. Perhaps at high levels the Scout is more useful in combat than as a capper (but I doubt it).
You are probably correct about the need to balance based level of play. I don't think it needs to be as simple as one set of rules based on the top level of play, or even a simple handicap system relative to that. It's perfectly possible to vary the rules according to a linear skill dimension, or even multiple dimensions. It will be an optimisation problem of some potential difficulty but nothing that has not been attempted before. Valve have enough data to determine player skill with reasonable accuracy, so that would be my main point of disagreement with you - Balance should and must be based on available data, and I re-iterate, not on the frenzied pulsating of forum based pond scum (even the elite kind). It's key to keep in mind the idea of "fun". "Fun" is the "fun"ction we want to maximise, for this is a game. If you play more then you have more fun, but it's not necessary for you to have more fun per second than anyone else. It's more fun to win than to lose, that's pretty much a given, and that leads to the stratification of players. But winning against players much worse than you is not so much fun, and losing well to your betters can be a complete riot. So fun is related to the relative skill levels of the players, not the absolute. And as it is fun we are trying to maximise, not balance, I can't align myself with your position.
So you see from the stats that Scouts are the most popular class, and you want to buff them? Let me guess, you work for Blizzard?;-) (Sorry, cheap shot.) No, the game is not just about combat, to win you have to achieve strategic objectives. Scouts are very good at that. They're also devastating in combat if played well - circle strafing and spamming you with their scatter gun or clonking you with the baseball bat. In general, the whole point of stats like this is that Valve can balance classes according to cold, hard data. Not the whining of forum posters, for that way lies madness.
You don't go Scout to kill people, but for point capping and intelligence runs - which ought to score more points. Also I'd say that the Spy is by far the hardest class to play, not the Scout.
Gold no, but most equipped items are soulbound. So they will only be sellable to NPC vendors. But there's nothing to stop Mr. Hacker from doing that. You can usually buy stuff back from the vendor but not after you've logged out. And Mr. Hacker will have helpfully logged you out. But he'll also have stolen your gold and the NPC's don't accept credit...
I suggest you read what I actually wrote - which was about CancelIo, not CancelIoEx. I have read the documentation for CancelIoEx, thank you very much. And your point is? How does that relate to what I actually wrote?
So the thread that calls CancelIo must have first pended the requests _itself_.
Yes, and that means that they must have been issued as overlapped operations, which directly contradicts your assertion "CancelIo can't cancel overlapped IO.".
The new functions significantly improve the utility of IO cancellation. But you seem to be very confused about why.
I suggest you read the documentation for CancelIo before you make a bigger fool of yourself. How would you call CancelIo for a synchronous operation? You wouldn't regain control until the operation had finished, so there would be no need to cancel it anyway.
Yes, really. But there are many variables, of course.
Increment/decrement of a register is one of those 1-byte instructions.
Yes, and push/pop. Note that I said 'mostly', and that my general point is that such instructions take up too much opcode space for their relative usefulness.
And don't underestimate those fancy instructions. It's very nice to be able to do things like a nondestructive multiply by 5 without using up the ALU.
It's nice, occasionally, but you don't need it so often in practice and you can do even more fancy stuff with ARM.
Well... it's not ideal for code compression, but I wouldn't call it "totally unsuited".
I think you're stretching my words a bit too far, we're talking about code compression so I didn't feel the need to qualify further.
I can see where you're going with this... But... Well, not so much.
RISC CPUs with 4-byte instructions that don't do very much require lots of memory bandwidth to execute.
Well, I'm currently working on ARM, and stuff almost always ends up smaller than x86 code. Those 4-byte instructions actually do quite a lot. Oh, and that's with straight ARM code, not Thumb or Thumb-2.
The x86 instruction set has lots of 1-byte instructions
Not so many actually, and the ones it does have are mostly totally useless these days!
and multi-byte instructions that do a lot.
Well, you get to do fancy addressing modes on the rare occasions that you need them... But not too fancy, no pre/post increment/decrement etc.
In other words, x86 is really just a compression scheme for instruction sets.
Sort of, except that it was never designed to be one, and it's not very good at it at all. Well, you could say that it was an OK (but not great) encoding for 8086, but it's totally unsuited to encoding the instructions that modern software actually uses.
Slashdot Mirror
WinCE has a very large subset of desktop Win32 APIs. Of course it's not binary compatible, we're mostly talking about ARM platforms on 'phones.
Linux has the whole apt-get/aptitude/whatever thing but that's not going to be the draw in the mobile space. Something based on it maybe, but it's gonna have to be a whole lot more user friendly to compete with the App Store etc. Even if it's more free(TM)... And of course few people are going to develop for it if there's no return on their investment.
Linux makes a large amount of sense on a nerd targeted netbook, in fact as a mostly Windows user I might switch to something like that, but the mass market is still not driven by the forces you would like.
Some of your points are well made.
No.
Whatever you think about Microsoft (and if it's the usual cult mentality, I really don't care) Microsoft have screwed up pretty badly (more than normal, if you will) on WM7.
It's hella late and they have pissed off a lot of people. I would personally really like to see Microsoft's continual presence in the mobile space if only for the sake of diversity... I'm unashamedly a Microsoft user and mostly supporter. Downmods be damned. But WM7 is pretty much a disaster area.
I hope they have something really good on the way... And even then, I worry that they're gonna let Android rule the world. Which is careless, because Android used to suck. But it's getting better very quickly, and there's still no sign of WM7.
No, in C such operators can take any nonzero value as true, but always produce 1 for a true result. In C++ they produce bool false/true and those convert to int as 0/1.
Weapons of Mass Instruction?
I read and re-read MarkusQ's comment and he isn't describing IDA Pro as a decompiler at all, in fact he's explicity saying "It can't of course give you back the actual source code".
The decompiler is called Hex-Rays, it's built on top of IDA Pro and is available from the same guys at hex-rays.com. (Not advertising, just a long time happy IDA Pro customer).
Yes, you omitted "Northern" in front of "Ireland" in the post I replied to.
Only Northern Ireland is in the UK. It's also not in Great Britain. The UK is short for "The United Kingdom of Great Britain and Northern Ireland (and dependent territories)"
Speculative execution can cause your RDTSC to give you odd results, for sure. It's normal to do a CPUID first to serialize everything. But I'm quite surprised that time would go backwards on a single core. The minimum sequence would be something like: :)
rdtsc
mov ebx, eax
mov ecx, edx
rdtsc
(sub eax, ebx
sbb edx, ecx)
I can't quite imagine the second rdtsc being executed before the first, even with out of order execution. But I'd love to know if anyone has ever seen it happen
It can't be both global and static. Error detected. Hungarian wins.
I also said as much in post #21671495 - If played well, the Scout can certainly hold his own in combat.
But in this article we're looking at the latest stats from Valve.
The stats show that people are not getting so many kills with the Scout. You say "Lots of people go scout for killing", but the stats show that it's not as effective as you think.
They also show that Scouts get by far the most captures. Which is cool, because the Scout's role is primarily as a capture monkey.
I'm sure it would be interesting to the stats broken down by player skill. Perhaps at high levels the Scout is more useful in combat than as a capper (but I doubt it).
You are probably correct about the need to balance based level of play. I don't think it needs to be as simple as one set of rules based on the top level of play, or even a simple handicap system relative to that.
It's perfectly possible to vary the rules according to a linear skill dimension, or even multiple dimensions. It will be an optimisation problem of some potential difficulty but nothing that has not been attempted before.
Valve have enough data to determine player skill with reasonable accuracy, so that would be my main point of disagreement with you - Balance should and must be based on available data, and I re-iterate, not on the frenzied pulsating of forum based pond scum (even the elite kind).
It's key to keep in mind the idea of "fun". "Fun" is the "fun"ction we want to maximise, for this is a game. If you play more then you have more fun, but it's not necessary for you to have more fun per second than anyone else.
It's more fun to win than to lose, that's pretty much a given, and that leads to the stratification of players. But winning against players much worse than you is not so much fun, and losing well to your betters can be a complete riot.
So fun is related to the relative skill levels of the players, not the absolute. And as it is fun we are trying to maximise, not balance, I can't align myself with your position.
So you see from the stats that Scouts are the most popular class, and you want to buff them? Let me guess, you work for Blizzard? ;-) (Sorry, cheap shot.)
No, the game is not just about combat, to win you have to achieve strategic objectives. Scouts are very good at that. They're also devastating in combat if played well - circle strafing and spamming you with their scatter gun or clonking you with the baseball bat.
In general, the whole point of stats like this is that Valve can balance classes according to cold, hard data. Not the whining of forum posters, for that way lies madness.
You don't go Scout to kill people, but for point capping and intelligence runs - which ought to score more points. Also I'd say that the Spy is by far the hardest class to play, not the Scout.
I'm in ur reformat command, virtualizing ur operations
Gold no, but most equipped items are soulbound. So they will only be sellable to NPC vendors. But there's nothing to stop Mr. Hacker from doing that. You can usually buy stuff back from the vendor but not after you've logged out. And Mr. Hacker will have helpfully logged you out. But he'll also have stolen your gold and the NPC's don't accept credit...
I suggest you read what I actually wrote - which was about CancelIo, not CancelIoEx. I have read the documentation for CancelIoEx, thank you very much. And your point is? How does that relate to what I actually wrote?
So the thread that calls CancelIo must have first pended the requests _itself_.
Yes, and that means that they must have been issued as overlapped operations, which directly contradicts your assertion "CancelIo can't cancel overlapped IO.".
The new functions significantly improve the utility of IO cancellation. But you seem to be very confused about why.
I suggest you read the documentation for CancelIo before you make a bigger fool of yourself. How would you call CancelIo for a synchronous operation? You wouldn't regain control until the operation had finished, so there would be no need to cancel it anyway.
Sorry, you're wrong. CancelIO has been available since NT 4.0. And Asynchronous IO works very well, perhaps you weren't using it correctly?
Really? That hasn't been my experience.
Yes, really. But there are many variables, of course.
Increment/decrement of a register is one of those 1-byte instructions.
Yes, and push/pop. Note that I said 'mostly', and that my general point is that such instructions take up too much opcode space for their relative usefulness.
And don't underestimate those fancy instructions. It's very nice to be able to do things like a nondestructive multiply by 5 without using up the ALU.
It's nice, occasionally, but you don't need it so often in practice and you can do even more fancy stuff with ARM.
Well... it's not ideal for code compression, but I wouldn't call it "totally unsuited".
I think you're stretching my words a bit too far, we're talking about code compression so I didn't feel the need to qualify further.
I can see where you're going with this... But... Well, not so much.
RISC CPUs with 4-byte instructions that don't do very much require lots of memory bandwidth to execute.
Well, I'm currently working on ARM, and stuff almost always ends up smaller than x86 code. Those 4-byte instructions actually do quite a lot. Oh, and that's with straight ARM code, not Thumb or Thumb-2.
The x86 instruction set has lots of 1-byte instructions
Not so many actually, and the ones it does have are mostly totally useless these days!
and multi-byte instructions that do a lot.
Well, you get to do fancy addressing modes on the rare occasions that you need them... But not too fancy, no pre/post increment/decrement etc.
In other words, x86 is really just a compression scheme for instruction sets.
Sort of, except that it was never designed to be one, and it's not very good at it at all.
Well, you could say that it was an OK (but not great) encoding for 8086, but it's totally unsuited to encoding the instructions that modern software actually uses.
Melbourne House are in Australia. As in, Melbourne, Australia.
So there's a bunch of Apaches in a shed and no-one wants to fly them? Errm... I'm up for it, where do I sign up? What are the hours?
Never have I heard such gratuitous use of the word 'but'.
Europe. Yes.
3D Monster Maze. Yes. Yes.