I've never been much of a fan of intrinsics, they tend to lock you both to specific hardware and a specific compiler vendor - unless you accept #ifdef hell in your source files.
I prefer to have as much of the platform-specifics as possible in the build system, where it's pretty easy to use either a foo-x86.asm or foo-x64.asm file.
For some of the lockless algorithms where you'd want to use CMPXCHG16B I know it's not too pretty to rewrite the entire thing in assembly, and doing a function call just for that instruction kind of defeats the purpose - and for other stuff, like writing an OS kernel, you might not care how portable your source is (for anybody talking about how portable linux is, do realize the difference between toolchain-portable and hardware-portable).
Btw, there isn't a 64bit version of "InterlockedCompareExchange"? With some IFDEFs (sigh:)), that set of API call turns into instruction-emitters.
Btw there's a lot of free (including source) assemblers that'll work for multiple systems and support both x86 and x64... FASM, NASM, YASM to name a few.
Smart developers don't use inline assembly, but use external asm modules. Easier to port source between compilers that way, you can use a full-featured assembler with macro support etc.
If you complain that it's too big a fuzz compared to inline assembly, well, chances are good that your piece of code is so small/insignificant you shouldn't be dealing with assembly at all - or at least you should refactor the code and do a larger chunk in (external) assembly.
My above post might have made a bit more sense if the "Mu" sign hadn't been cut out:) - it should have read "people are using utorrent though" and "cling on to ut religiously", but of course with a Mu sign instead of the 'u'.
The point is, of course, that with the purchase of utorrent, BitTorrent inc. have purchased a pretty large marketshare...
If BitTorrent inc. hadn't purchased torrent, it'd be entirely a non-issue since their client more or less sucks, and the current protocol is already well explained far and wide, with lots of opensource clients available.
a lot of people are using torrent though, so if BT inc starts doing protocol changes, they could potentially shatter the BT "community". We can only hope that, in case they do this, people won't cling on to t religiously but move to another client...
Try using 'find' instead of locate and search through your entire filesystem - you should be able to tell the difference with and without the "noatime" option, especially if you don't have a 10.000rpm drive.
I've been using the NT equivalent (NtfsDisableLastAccessUpdate) since win2000, and I use noatime on linux/bsd boxes as well.
A CD or DVD is a medium customarily used for software interchange.
So, what if you recorded a DVD video scrolling through all the source files in an editor?:)
...and then you have to join the split-up files again before you can extract. RAR (and other archivers with split archive support) automagically extracts without wasting time and disk spice on a 'join' operation.
bypassing hardware dongles requires that you reverse engineer the driver to the dongle, this is just plain easy, all you need to do is find a disassembler that can handle the format, or if it's a kernel mode driver, then you just use a kernel mode debugger... Or keep using IDA on the driver. Or do a mix of IDA and one of {windbg, softice, syser}. And probably add some private/homecoded tools for dealing with obfuscation and protection.
when you locate where the driver is being attached to from the program itself, then you just emulate the hooks. Even the most advanced dongles are easy to hack this way. Yes, it's obviously always this simple, also when the dongle actually runs code... *cough*
Bottom line: while you're basically right that anything will eventually be broken, you're making it sound a bit easier than it really is.
Slashdot Mirror
I've never been much of a fan of intrinsics, they tend to lock you both to specific hardware and a specific compiler vendor - unless you accept #ifdef hell in your source files.
:)), that set of API call turns into instruction-emitters.
I prefer to have as much of the platform-specifics as possible in the build system, where it's pretty easy to use either a foo-x86.asm or foo-x64.asm file.
For some of the lockless algorithms where you'd want to use CMPXCHG16B I know it's not too pretty to rewrite the entire thing in assembly, and doing a function call just for that instruction kind of defeats the purpose - and for other stuff, like writing an OS kernel, you might not care how portable your source is (for anybody talking about how portable linux is, do realize the difference between toolchain-portable and hardware-portable).
Btw, there isn't a 64bit version of "InterlockedCompareExchange"? With some IFDEFs (sigh
Btw there's a lot of free (including source) assemblers that'll work for multiple systems and support both x86 and x64... FASM, NASM, YASM to name a few.
Smart developers don't use inline assembly, but use external asm modules. Easier to port source between compilers that way, you can use a full-featured assembler with macro support etc.
If you complain that it's too big a fuzz compared to inline assembly, well, chances are good that your piece of code is so small/insignificant you shouldn't be dealing with assembly at all - or at least you should refactor the code and do a larger chunk in (external) assembly.
The point is, of course, that with the purchase of utorrent, BitTorrent inc. have purchased a pretty large marketshare...
a lot of people are using torrent though, so if BT inc starts doing protocol changes, they could potentially shatter the BT "community". We can only hope that, in case they do this, people won't cling on to t religiously but move to another client...
Try using 'find' instead of locate and search through your entire filesystem - you should be able to tell the difference with and without the "noatime" option, especially if you don't have a 10.000rpm drive. I've been using the NT equivalent (NtfsDisableLastAccessUpdate) since win2000, and I use noatime on linux/bsd boxes as well.
A CD or DVD is a medium customarily used for software interchange. So, what if you recorded a DVD video scrolling through all the source files in an editor? :)
...and then you have to join the split-up files again before you can extract. RAR (and other archivers with split archive support) automagically extracts without wasting time and disk spice on a 'join' operation.
Man, that's just out of this world...