This is (or well, was) more useful than it sounds at first: back in the days, you pretty much had two choices for 32bit dos-extended C++ programming. Either Watcom C++ (the de-facto standard), or Borland C++ with the dos-extender add-on pack (which didn't come default). Using a 3rd-party PE-console supporting dos extender (the first one I came about was WDOSX, well before HX) let you use whatever Win32-supporting compiler for producing 32bit dos apps, including Borland C++ without the dos-extender pack, Visual C++, et cetera.
Different platforms have different instruction sets, and thus different mnemonics. As for operand order, Intel follows the C style of "dst, src", whereas AT&T tries to follow English rules ("mov src, dst" -> move source into destination) which looks plain wrong to us people used to Intel syntax:)
Furthermore, there's also a bit of mnemonic difference on the same platform, at least between GAS and "most everybody else" - GAS wants operand size as part of the instruction mnemonic instead of deducing it from arguments.
IMHO a GZIP or ImageMagick benchmark suite wouldn't be very relevant here, since you'll almost exclusively be testing usermode code unrelated to the OS. Yes, there's of course going to be some time spent in the I/O subsystem, and of course scheduler and kernel locking granularity has something to say as well... but you'll mostly be testing 3rd party code and the quality of your compiler's optimizations, not the OS kernel.
That said, it would be very interesting if such a benchmark turned up noticeable differences:)
The bit-width of the system makes no difference to the amount of RAM used for file caches;
With the exception, of course, that non-server 32bit editions of Windows won't let you use above 4GB of RAM, even though it's supported with PAE (and PAE is enabled for hardware DEP support). Heck, it isn't even a "4GB of RAM" limitation, but "you can only use lower 4GB PhysicalAddresses", which is different... BIOS remapping and all.
Capping to 4GB was a marketing decision, which kinda sucks but is sorta fair enough. Capping to 32bit PhysicalAddresses sucks because you can lose a lot of memory that way, but was done for compatibility reasons; really sucky driver developers thinking they only need to use addr.LowPart instead of addr.QuadPart when dealing with PhysicalAddresses, because they're on a 32bit system...
Even people who should know better... I kinda hope it's only the name that sticks, and they don't think they're actually running DOS programs.
Btw, while x64 Windows drops DOS support (no wonder since Long Mode doesn't support v86 tasks), it still has the ability to execute 16bit BIOS routines. That's right, MS included a (very limited, and with pretty stringent memory location write protection) 16bit x86 emulator:)
Yeah, there was the privilege escalation that affected all architectures and kernels across 2.4->2.6 (around 8 year timespan), the chunked-encoding exploit in Apache was around for quite a while as well, iirc - and those are just what I can remember off top of my head:)
At least this NTVDM is "only" privilege escalation - it's pretty damn bad, but not as bad as a remote service hole, or something that can auto-trigger in your browser (you don't need admin privs to do nasty stuff, even though admin privs help).
Btw, I thought Vista introduced running NTVDM processes in a way that LUA accounts couldn't interact with the processes, not even send window messages (and thus paste text etc.) - but perhaps I'm confusing this security with the win32 console mode subsystem, which is something completely different from NTVDM.
Most 32bit stuff runs with no perceptible speed difference (positive or negative) on 64bit Windows - there's a few corner cases, though. Foxit Reader (at least some versions) has/had extreme slowdown in PDF rendering, for some reason - we're talking bad enough that rendering a single page of a complex PDF takes 3+ seconds, with the elements gradually being drawn (Intel Quad6600@2.4GHz) - it was actually faster to render the PDF in a 32bit VM on the 64bit host:-) .
Some things seem slightly faster, though, and it's definitely nice being able to use a lot of memory - and 32bit apps compiled with large-address-aware can use almost full 4GB of memory space, they aren't limited by the 2:2 (or 3:1 with boot.ini option) split as on a 32bit host. And when you have a need for huge address spaces or lots of GPRs, 64bit apps are quite nice. Iirc context switches have less overhead under 64bit as well, even in face of the extra GPRs.
And then there's all the nice extra kernel improvements that Vista and Win7 have brought along - concerning security as well as speed. Too bad the usermode subsystem developers partially ruin that;)
Good luck auditing even such a "limited" part as the kernel, even if you've got a full team of people - claiming that any individual could audit an entire distro is lunacy.
And it's not like serious bugs haven't had long timespans in linux before they were discovered; probably not any that were present as long as the NTVDM bug:), but still - shows that having the ability to audit the code doesn't help _that_ much if nobody are actually doing it.
Sounds plausible; the thing that irks me is that if these USB devices really do have AES-256 capabilites and the contents of the flashram is encrypted... why the hell have they made such a terrible flaw implementing the rest of the system?:-s
Also, keep in mind that RSA by itself is much too slow to encrypt large amounts of data; thus, PGP and other solutions only use RSA to encrypt a symmetric cipher, which is then used for the bulk encryption.
Standard AES-256 is actually just fine, problem with these devices is that the manufacturers screwed up the implementation *majorly* (as I understand it, use the same key for every device and depend on a usermode app to say GOOD_GUY/BAD_GUY to the hardware) - but that's covered elsewhere.
That video is so low-quality I can't tell if it has motion blur or not - could just be encoding artifacts;)
Btw, don't most of the ports actually render to 32bpp, even though the source data is 8bpp indexed? That'd make it a lot easier to add motion blur, transparency, and whatnot.
...and even though Magic Carpet was one of the most enchanting games ever, the franchise was discontinued. How I pine for a Magic Carpet 3... or *proper* XCOM follow-ups:(
The Borland IDEs were definitely top notch back then, and the integrated help was world-class... code generation sucked, though, which was even worse back then because CPUs were so slow. For pascal, it became of mix of "Sallys Peephole Optimizer", custom CRT, and hand-written assembly.
Older versions of pascal had a very cool feature, btw: compiling directly to RAM. This was way before UDMA disks, so it sped up compile/test cycles tremendously.
Still, as long as you used the lowest-level possible read (_read() rather than fread()), there shouldn't be any advantage in doing disk reads in assembly rather than C. *perhaps* if you went through the trouble of writing a full disk driver and not just calling DOS/BIOS interrupts, but...
Indeed it is, and personally I'd much rather re-use somebody else's lock-free code than having to write my own;) - but the potential for savings can be big.
Which OS + compiler were you on to get behavior like that? Back in the early 90's I was doing Pascal (Turbo6, then Borland7), and routinely had to write chunks of assembly code because CPUs were slow and the compilers sucked... never has the overhead of doing PUSHes/CALL/RET vs. issuing a raw syscall been an issue - assuming that the library routine didn't add a lot of extra junk of it's own. Same when I finally gave up the 16bit world and moved to 32bit dos-extended C++, the to linux and windows.
Ah, the days when optimizing printf() actually mattered:)
As for 68k vs x86, oh well. x86 is insanely hacky and there's so much I'd like to see changed about it, but obviously it's been superior to 68k for quite a while, clockspeeds as well as instructions and architecture.
I'm not saying you shouldn't synchronize, but that adding synchronization to your containers is the entirely wrong granularity to do it - ask yourself what's more efficient: lock, 500 inserts, unlock... or 500 times lock-insert-unlock? The latter is impossible if you add synchronization at the primitive container level.
You should probably move up a notch on the abstraction level ladder:), and not deal directly with primitive containers from client code.
Apart from simple mutexes, there's other things to consider like lockfree algorithms, reader/writer locks, and "divide and conquer" even if it means duplicating data per-thread.
Synchronization is expensive, sometimes too much, and then you have to restructure your logic.
Heh, getting higher disk transfer rate by writing a routine in assembly than C? Bullshit. Unless of course you've done a really silly apples-and-oranges "benchmark" like comparing 1-char-at-a-time FILE* reads to raw buffer-at-a-time read syscalls...
If you can go faster by doing syscalls in assembly than using posix read(), your libc implementation sucks - it's not asm being faster than C in this case...
ps: an assembler is the tool that assembles assembly code.
You're not suggesting it's a good idea to use synchronization directly in collection/string code, are you? O_o
The original JAVA collections (like vector) were synchronized - there's a pretty good reason the new-style (like arraylist) collections aren't. Just like BigLocks are bad for threaded performance, so is trying to do synchronizing on a too low level.
I'm afraid it's too late at this point; they screwed up by continuing Win9x after they made Windows 2000. If that had been "one OS to rule them all", including non-admin default account, things would probably have looked different today.
Instead, we're left with a situation where MS have a kernel that's superior to traditional *u*x because of it's VMS origins, but a shitload of problems because of moronic 3rd-party developers that have been used to developing and testing entirely on admin accounts.
It's a shame when they listen to the **wrong** customers. As you say, tehy get shit no matter what - might as well do the right thing and catch the flak for it:)
Apple can get away with radical changes because of the fan culture, MS can't. And even thought Apple can, they don't utilize it to the fullest; when they dropped non-x86 support, they could've introduced proper ASLR, canaries, (proper) 64bit support and a lot of other things... but they didn't.
Microsoft didn't remove UAC from Windows 7 - they added various levels of naziness. The big mistake, however, was adding levels beyond the first lesser level, setting a non-max level as default, and have anything but the strictest level open to escalation.
It's a shame MS bows down to public pressure on issues like this.
An OS with a high marketshare is interesting to auto-exploit because you can build yourself a botnet that way. For lower marketshare OSes, you'll only be able to grab a "handful" of boxes by auto-exploiting; on the other hand, there might be some "really interesting" systems you can break into.
Anybody with half a clue knows what this means: you keep your 0-day exploit code to yourself, because the value of breaking into those interesting systems is vastly higher than penis-enlargement from getting your name out with a 0-day exploit. Think industrial espionage, blackmailing, etc.
Just because there's no known exploit code out in the wild doesn't mean people aren't exploiting systems.
Slashdot Mirror
This is (or well, was) more useful than it sounds at first: back in the days, you pretty much had two choices for 32bit dos-extended C++ programming. Either Watcom C++ (the de-facto standard), or Borland C++ with the dos-extender add-on pack (which didn't come default). Using a 3rd-party PE-console supporting dos extender (the first one I came about was WDOSX, well before HX) let you use whatever Win32-supporting compiler for producing 32bit dos apps, including Borland C++ without the dos-extender pack, Visual C++, et cetera.
Different platforms have different instruction sets, and thus different mnemonics. As for operand order, Intel follows the C style of "dst, src", whereas AT&T tries to follow English rules ("mov src, dst" -> move source into destination) which looks plain wrong to us people used to Intel syntax :)
Furthermore, there's also a bit of mnemonic difference on the same platform, at least between GAS and "most everybody else" - GAS wants operand size as part of the instruction mnemonic instead of deducing it from arguments.
IMHO a GZIP or ImageMagick benchmark suite wouldn't be very relevant here, since you'll almost exclusively be testing usermode code unrelated to the OS. Yes, there's of course going to be some time spent in the I/O subsystem, and of course scheduler and kernel locking granularity has something to say as well... but you'll mostly be testing 3rd party code and the quality of your compiler's optimizations, not the OS kernel.
That said, it would be very interesting if such a benchmark turned up noticeable differences :)
The bit-width of the system makes no difference to the amount of RAM used for file caches;
With the exception, of course, that non-server 32bit editions of Windows won't let you use above 4GB of RAM, even though it's supported with PAE (and PAE is enabled for hardware DEP support). Heck, it isn't even a "4GB of RAM" limitation, but "you can only use lower 4GB PhysicalAddresses", which is different... BIOS remapping and all.
Capping to 4GB was a marketing decision, which kinda sucks but is sorta fair enough. Capping to 32bit PhysicalAddresses sucks because you can lose a lot of memory that way, but was done for compatibility reasons; really sucky driver developers thinking they only need to use addr.LowPart instead of addr.QuadPart when dealing with PhysicalAddresses, because they're on a 32bit system...
A lot of people confuse the two!
Even people who should know better... I kinda hope it's only the name that sticks, and they don't think they're actually running DOS programs.
Btw, while x64 Windows drops DOS support (no wonder since Long Mode doesn't support v86 tasks), it still has the ability to execute 16bit BIOS routines. That's right, MS included a (very limited, and with pretty stringent memory location write protection) 16bit x86 emulator :)
Yeah, there was the privilege escalation that affected all architectures and kernels across 2.4->2.6 (around 8 year timespan), the chunked-encoding exploit in Apache was around for quite a while as well, iirc - and those are just what I can remember off top of my head :)
At least this NTVDM is "only" privilege escalation - it's pretty damn bad, but not as bad as a remote service hole, or something that can auto-trigger in your browser (you don't need admin privs to do nasty stuff, even though admin privs help).
Btw, I thought Vista introduced running NTVDM processes in a way that LUA accounts couldn't interact with the processes, not even send window messages (and thus paste text etc.) - but perhaps I'm confusing this security with the win32 console mode subsystem, which is something completely different from NTVDM.
cmd.exe has nothing to do with DOS or NTVDM - it's a native 32bit Windows console mode application.
Most 32bit stuff runs with no perceptible speed difference (positive or negative) on 64bit Windows - there's a few corner cases, though. Foxit Reader (at least some versions) has/had extreme slowdown in PDF rendering, for some reason - we're talking bad enough that rendering a single page of a complex PDF takes 3+ seconds, with the elements gradually being drawn (Intel Quad6600@2.4GHz) - it was actually faster to render the PDF in a 32bit VM on the 64bit host :-) .
Some things seem slightly faster, though, and it's definitely nice being able to use a lot of memory - and 32bit apps compiled with large-address-aware can use almost full 4GB of memory space, they aren't limited by the 2:2 (or 3:1 with boot.ini option) split as on a 32bit host. And when you have a need for huge address spaces or lots of GPRs, 64bit apps are quite nice. Iirc context switches have less overhead under 64bit as well, even in face of the extra GPRs.
And then there's all the nice extra kernel improvements that Vista and Win7 have brought along - concerning security as well as speed. Too bad the usermode subsystem developers partially ruin that ;)
Good luck auditing even such a "limited" part as the kernel, even if you've got a full team of people - claiming that any individual could audit an entire distro is lunacy.
And it's not like serious bugs haven't had long timespans in linux before they were discovered; probably not any that were present as long as the NTVDM bug :), but still - shows that having the ability to audit the code doesn't help _that_ much if nobody are actually doing it.
Sounds plausible; the thing that irks me is that if these USB devices really do have AES-256 capabilites and the contents of the flashram is encrypted... why the hell have they made such a terrible flaw implementing the rest of the system? :-s
Not really applicable to a hardware device.
Also, keep in mind that RSA by itself is much too slow to encrypt large amounts of data; thus, PGP and other solutions only use RSA to encrypt a symmetric cipher, which is then used for the bulk encryption.
Standard AES-256 is actually just fine, problem with these devices is that the manufacturers screwed up the implementation *majorly* (as I understand it, use the same key for every device and depend on a usermode app to say GOOD_GUY/BAD_GUY to the hardware) - but that's covered elsewhere.
That video is so low-quality I can't tell if it has motion blur or not - could just be encoding artifacts ;)
Btw, don't most of the ports actually render to 32bpp, even though the source data is 8bpp indexed? That'd make it a lot easier to add motion blur, transparency, and whatnot.
...and even though Magic Carpet was one of the most enchanting games ever, the franchise was discontinued. How I pine for a Magic Carpet 3... or *proper* XCOM follow-ups :(
That's hardly "engine changes", though.
Hehe :)
The Borland IDEs were definitely top notch back then, and the integrated help was world-class... code generation sucked, though, which was even worse back then because CPUs were so slow. For pascal, it became of mix of "Sallys Peephole Optimizer", custom CRT, and hand-written assembly.
Older versions of pascal had a very cool feature, btw: compiling directly to RAM. This was way before UDMA disks, so it sped up compile/test cycles tremendously.
Still, as long as you used the lowest-level possible read (_read() rather than fread()), there shouldn't be any advantage in doing disk reads in assembly rather than C. *perhaps* if you went through the trouble of writing a full disk driver and not just calling DOS/BIOS interrupts, but...
Indeed it is, and personally I'd much rather re-use somebody else's lock-free code than having to write my own ;) - but the potential for savings can be big.
Easy now :)
Which OS + compiler were you on to get behavior like that? Back in the early 90's I was doing Pascal (Turbo6, then Borland7), and routinely had to write chunks of assembly code because CPUs were slow and the compilers sucked... never has the overhead of doing PUSHes/CALL/RET vs. issuing a raw syscall been an issue - assuming that the library routine didn't add a lot of extra junk of it's own. Same when I finally gave up the 16bit world and moved to 32bit dos-extended C++, the to linux and windows.
Ah, the days when optimizing printf() actually mattered :)
As for 68k vs x86, oh well. x86 is insanely hacky and there's so much I'd like to see changed about it, but obviously it's been superior to 68k for quite a while, clockspeeds as well as instructions and architecture.
I'm not saying you shouldn't synchronize, but that adding synchronization to your containers is the entirely wrong granularity to do it - ask yourself what's more efficient: lock, 500 inserts, unlock... or 500 times lock-insert-unlock? The latter is impossible if you add synchronization at the primitive container level.
You should probably move up a notch on the abstraction level ladder :), and not deal directly with primitive containers from client code.
Apart from simple mutexes, there's other things to consider like lockfree algorithms, reader/writer locks, and "divide and conquer" even if it means duplicating data per-thread.
Synchronization is expensive, sometimes too much, and then you have to restructure your logic.
Heh, getting higher disk transfer rate by writing a routine in assembly than C? Bullshit. Unless of course you've done a really silly apples-and-oranges "benchmark" like comparing 1-char-at-a-time FILE* reads to raw buffer-at-a-time read syscalls...
If you can go faster by doing syscalls in assembly than using posix read(), your libc implementation sucks - it's not asm being faster than C in this case...
ps: an assembler is the tool that assembles assembly code.
You're not suggesting it's a good idea to use synchronization directly in collection/string code, are you? O_o The original JAVA collections (like vector) were synchronized - there's a pretty good reason the new-style (like arraylist) collections aren't. Just like BigLocks are bad for threaded performance, so is trying to do synchronizing on a too low level.
...and you assume they write their data-mining tools in PHP just because the "end-user experience" is written in that language?
I'm afraid it's too late at this point; they screwed up by continuing Win9x after they made Windows 2000. If that had been "one OS to rule them all", including non-admin default account, things would probably have looked different today.
Instead, we're left with a situation where MS have a kernel that's superior to traditional *u*x because of it's VMS origins, but a shitload of problems because of moronic 3rd-party developers that have been used to developing and testing entirely on admin accounts.
It's a shame when they listen to the **wrong** customers. As you say, tehy get shit no matter what - might as well do the right thing and catch the flak for it :)
Apple can get away with radical changes because of the fan culture, MS can't. And even thought Apple can, they don't utilize it to the fullest; when they dropped non-x86 support, they could've introduced proper ASLR, canaries, (proper) 64bit support and a lot of other things... but they didn't.
Microsoft didn't remove UAC from Windows 7 - they added various levels of naziness. The big mistake, however, was adding levels beyond the first lesser level, setting a non-max level as default, and have anything but the strictest level open to escalation.
It's a shame MS bows down to public pressure on issues like this.
Think for a few seconds.
An OS with a high marketshare is interesting to auto-exploit because you can build yourself a botnet that way. For lower marketshare OSes, you'll only be able to grab a "handful" of boxes by auto-exploiting; on the other hand, there might be some "really interesting" systems you can break into.
Anybody with half a clue knows what this means: you keep your 0-day exploit code to yourself, because the value of breaking into those interesting systems is vastly higher than penis-enlargement from getting your name out with a 0-day exploit. Think industrial espionage, blackmailing, etc.
Just because there's no known exploit code out in the wild doesn't mean people aren't exploiting systems.