They have a strategic problem, which is that somehow they have to make the transition to a Passport and.Net business model before Wall Street figures out that their current business model is screwed.
Believe it or not, Microsoft is a very agile company. They did a complete 180 in the mid-90's, going from almost complete lack of regard for the internet to almost complete and total embrace (everything was internet enabled, or embedded html, or whatever). If I were on Wall St., I wouldn't be worried that Microsoft can pull off the change, only that it may not be the proper direction (for what it's worth, I think Microsoft is going in the right direction, but that's a different comment).
I wouldn't be sleeping too well if I was a Microsoft strategist right now, because that's a really hard job, especially considering that they don't even have the technology in place for the new business model yet. Even if they had the technology in place, they would have a very hard job persuading corporate managers to buy into this, simply because of the control issue. If I have all my business processes farmed out to an ASP, I don't control them any more.
Microsoft doesn't have any of the technology in place for the new business model? What? ESR needs to realize that just because he says something doesn't make it true. Last time I checked, Passport was alive and kicking with quite a few members, the.NET servers were shipping, Windows 2000 could install the.NET Universal Run Time, Visual Studio.NET has shipped, etc. In other words, the infrastructure is now available to build (VS.NET), deploy (VS.NET again,.NET servers), and run (.NET URT,.NET servers, Win2K, Passport, etc).NET services. However, ESR obviously doesn't see that. He also, apparently, doesn't see what.NET is all about, if he thinks it's just a fancy name for an ASP.
ESR is a smart guy, or can be when he tries, but he should stick to espousing his open source propaganda and leave it at that. He's shown that he has no clue about Microsoft's past or present, and that makes him singularly unqualified to comment on their future.
Funny, last time I checked, C++ was an object-oriented language. (Okay, if you program in "C++", by which I mean C with a smattering of C++ syntax, then sure it's imperative. But that's not C++. That's C with syntactical sugar.)
have no doubt that even in the Windows/Mac world a really powerful Command Line feature for any given app would be super useful, but it is only so for those who have climed that learning curve. In that case, it's better to focus on making the App do what it needs to do.
In the Windows world, many applications do have powerful commandline features, as well as GUIs. However, you're trying to impose a unix-style of automation (shell script, tying a bunch of small commands together) on a system with its own methods of automation. Let me first say that there are tools you can install on Windows to do unix-style scripting, like Cygwin. I'm ignoring that for now. Typically, when you want to script something in Windows, you'll end up writing some vbscript or jscript that instantiates a COM object and does what it needs through that rather than running an app with some params and catching/piping stdin/stdout. I won't say which method is better, simply that they're different.
This is why *nix administration knowledge doesn't translate to NT administration knowledge, and vice versa. Too often people complain about NT admins trying to use linux or some other unix without ever thinking of the reverse scenario. Try writing a script to force a change of password on next login for some number of NT users. Now make sure it works for local users, NT4 domain users, and Win2K AD users. This is quite doable, but most unix admins look for a passwd-like app, find none, and give up, complaining that NT sucks because they have to go through a GUI to modify 50,000 accounts.
Actually, no. It is from the diseased mind of the author of the article.
My bad, then. I'm not 100% familiar with the FHS myself, so I made the (poor) assumption that when the author said that's what the FHS defines, he was speaking authoritively. Apparently not. If slashcode would allow editing of comments, I'd fix this assumption.
These are obsolete folders. When UNIX didn't have a package system (like RPM), sysadmins needed to separate an optional (or local) application from the main OS. These were the directories used for that.
I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong. Perhaps/usr/local is obsolete with respect to package managers, and that makes some sense (because the package manager should handle proper management of placed files, though in practice that's not always the case), but as long as open source is around, there will always be software that is compiled rather than installed through a package manager. There will also always be applications that are not distributed in your package format of choice (as long as there is more than one package management system, this will always hold true). In these cases, it's still a good idea to keep around/usr/local and/opt. Personally, I'll have/usr/local on my systems for a long time to come, because I prefer to use the Encap management system.
They need good game logic (and design) and not high framerates in order to be sucessful. Java fosters good design and is less prone to errors (buffer overflow anyone?) while still allowing for acceptable graphics performance.
I disagree. It is just as easy to write poor code in Java as in any other language. In fact, I'd be inclined to suggest that Java actually hinders good design, with its fragile system of inheriting everything from Object. That's Bad Design (tm), and should be avoided. If you want to be able to use something like Java's native collection classes (lists, for example), you have to inherit from Object even if doing so runs against your design. Better to either use a dynamically typed language (for example, Smalltalk), or a language with generic programming constructs (templates in C++). A smaller set of limitations may be imposed (for instance, it may be required that the class implement some sort of comparison operator, for sorted lists), but that does away with requiring inheritance from Object. (what happens if/when Object changes? everything that inherits from Object will need a recompile, at the very least.)
It may be "easier" to make a good design in Java than in C, but it's even easier if you use something like C++ and STL (caveat -- you need to know the language you're working with. If you're using C++, but treating it like C, it's going to be no better than C. Same for Java if you treat it like C++).
The "wierd vector units" and multiprocessor architecture of the PS2 was a stroke of genious! The PS2 vs XBox is analog to the Amiga vs AtariST (which had a faster CPU, but no co-prosessors).
It's not so simple as that. The XBox may not have generic co-processors, like the PS2's two vector units, but it does have a very powerful graphics co-processor, and another very powerful audio co-processor. Currently, the PS2's VUs are being used for things like enhanced graphics effects (doable on the XBox's GPU) and audio effects like surround sound (the XBox does dolby digital natively in hardware). Yes, if the PS2 had the same powerful graphics and audio processors, then the extra VUs would be a huge asset. As it is, those co-processors need to be used just to keep up with what the XBox can do.
True enough, but if you're at the point where 1C makes a difference, then you ought not be overclocking, or should get a better HSF. A shim is physical protection, not thermal protection.
The AC poster was wrong, and so are you. Thermal compound (arctic silver, the thermal pad you see on most HSFs, other grease) is completely different. It's used to fill in the microscopic holes in the top of the CPU core and bottom of the HSF (good HSFs are machined smooth, but if your HSF isn't, with a little patience you can lap it smooth). You only want a very thin layer of this stuff, because while it is thermally conductive, it's not as conductive as a dry metal<->metal joint. You want just enough to create a light film on the CPU core (if you get a little too much, that's fine as the pressure of the HSF will squeeze the excess out -- if you get way too much, grab some rubbing alcohol, clean off the core, and start over). It works best if you squeeze out a small line of the stuff, and then draw it across the CPU using a credit card.
Shims are for spacing, period. (other posts have explained shims sufficiently, so I'll leave that as an excercise to the reader.)
A shim is a small plate composed of thermally conductive material that you put between an FCPGA CPU and the heat sink. It has holes for the chip and the other parts of the CPU that rise above the rest.
Nope. A shim is generally not thermally conductive (and better damn well not be electrically conductive...), since it doesn't matter whether it is or not.
The idea is to increase the amount contact surface area between the CPU and the heatsink.
Again, wrong. The idea is not to increase the amount of contact surface between the CPU and the heatsink, as this would be impossible to do, unless you made the CPU itself larger -- heat only radiates off of a CPU from the little rectangular core in the middle; the ceramic surrounding the contact point has little to no thermal conductivity. Instead, the idea is to give the heatsink a larger area to which to apply pressure. This means it's going to be more difficult (though not impossible) to chip the CPU core if you're using a shim than if you're not. Shims only became popular with the Athlon Thunderbird chips that were trivially easy to break with a sloppy heatsink install. Since those shims were made out of copper (bad! that's electrically conductive, which means you could very easily short out your CPU), many of the more clueless overclockers instantly thought "copper == cool", and thus assumed that shims were another way to lower their CPU temps by a couple more degrees. They were wrong.
I would guess that XP has more legacy VMS code in it than OS/2 code.
Only if by "legacy code" you mean "guys that worked on VMS also worked on NT, and thus may have had tendencies towards doing things in a VMS way", rather than "old VMS code", since NT was a completely new OS. Also, while NT did for a while have an OS/2 subsystem, that's no longer in XP, and it was along the lines of the POSIX subsystem -- it was not part of the OS, other than that it added a layer to NT to allow POSIX or OS/2 apps to run. Other than the fact that NTFS was originally loosely based on HPFS from OS/2, that's the only OS/2 code you'll find in NT.
I know this is off-topic, but it's FUD that comes up quite often. Let me first say that yes, I do realize that the XBox controller is large. However, having said that, only those who have never used one (the fixed-position controllers on the XBox store displays don't count, because you can't hold those in a comfortable position) would complain about the XBox controller. Its largeness makes it feel very solid in your hand, more like a power tool than a game controller, while the ergonomic design and button layout makes the main action buttons and sticks easily accessible while holding the controller in a comfortable position.
This being slashdot, anecdotal evidence is considered irreproachable, and so I have some anecdotal evidence of my own. I've played many gaming consoles, from the original NES to the Genesis and SNES, through the N64 and Playstation (which would be the same as the PS2), and finally the GameCube and the XBox. Out of all of those controllers, the XBox controller is the only one with which I've ever been able to play for multiple hours without cramping or fatigue. The others were too small, or oddly shaped, or, in the case of the NES controller, had sharp corners. The XBox controller just fits right in my hand, and is as comfortable as console gaming gets.
Having not used NT4 in quite a long time, I can't be 100% sure the functionality is there or not. It definitely is in Win2K and XP (it's provided by the RunAs service, and there are several other ways to access it than by what I gave in my previous post). Try searching NT4's system help for "run as" and see what comes up.
Also, shift-right-clicking may not be very deterministic -- it only works on some file types (it seems to work on most executables or shortcuts to executables, but not something like the IE icon on the desktop, and not on document files that spawn an executable through the filetype handler), and you have to make sure you highlight/select the icon (click once if using classic double-click mode, hover briefly if using the single-click mode) before then shift-right-clicking.
And that's why Windows NT/2000/XP have the ability to run as different users. It's a little convoluted (highlight the app you want to run, shift-right-click the icon, select Run as, click The following user radio button, give the username and password of an administrative user), but it's available. Also, this will only work for executables or shortcuts to executables, so while you can run Word as a local administrator while logged in as a normal user, you can't start Word as a different user by trying to run a.doc file
Who gives a fuck if userfriendly is sold with flash? You don't have to buy it even if it is offered to you as part of a package containing a bucket of hot grits and Natalie Portman.
You misunderstand. I was not saying that User Friendly peddles Flash to their readerbase, but that they pretty much sell their fanbase to companies by way of awful custom-made Flash animations that supposedly target the "geek demographic".
At least they're not peddling their readership to businesses by offering poorly-animated, humor-lacking Flash animations. Gabe has always done art for things other than Penny Arcade. His art is a regular staple over on the Gamespy Network. At the very least, Gabe's art is good enough that he doesn't have to whore himself out to get work.
Shouldn't User Friendly be apologizing to you for subjecting you to bad art and no humor? The Penny Arcade guys were right. "People will pass up steak once a week for crap every day."
Still, I do agree that MS should probably distribute "lite" versions of their language products, gratis, with their OS's, which would certainly increase their user base.
The.NET framework is freely available, and includes compilers for managed C++, C#, and VB.NET. Get it at MSDN. That gives you "everything you need to write, build, test, and deploy.NET Framework applications - documentation, samples, and command-line tools and compilers." Of course, it doesn't include the Visual Studio IDE, so you'll have to write your code in something else (Source Insight, Notepad, vi, emacs (*shudder*), whatever), and you won't have any gui for drawing window forms, but you can still build and deploy applications. The only requirement is that you're running on an NT-based OS (Windows NT 4 SP6a, Windows 2000 (SP2 recommended, but not required), or Windows XP Pro) and have IE5.01 or later.
With proper exceptions, general sections of cleanup code are rarely necessary. As you go up the stack, objects go out of scope. There are a lot of C++ classes out there (often called "monitors" or "guards") that really only exist for their constructors and destructors. When they go out of scope, they make release a lock, free a pointer, or whatever. No finally clause necessary; it correctly handles both exceptions and normal function exit. There's no possibility of programmer error. Something like this:
Right, guard classes are good things to use, and I often do use them. In particular, I enjoy using the ATL classes CComPtr, CComQIPtr, CComBSTR, and CComVariant. CComPtr probably gets the most use out of me, because it's the most generic. It simply attaches to a pointer (or can create a pointer itself, if you'd rather do it that way), and takes care of deallocation for you when it goes out of scope. CComQIPtr is beautiful if you ever do any COM programming (no more cumbersome QueryInterface calls! CComQIPtr will do it for you). CComBSTR and CComVariant are essential for interop with automation (VB, windows scripting). (I'm giving Windows examples, because that's what I know.) Even so, there can still be general cleanup issues that you need to take care of, even when using guard classes. A trivial example would be doing some logging and rolling up an error value into something useful ("error value" meaning success or some type of error). Sure, the latter isn't necessary if you use exceptions, but logging is always good (okay, so it's a contrived example. pfah!)
I still don't buy that. I just can't think of many situations where you pump out exception after exception in a loop. Yes, they are at many places throughout your code. But those should be the branches that are infrequently taken. If they're not, I have to think something more fundamental is wrong.
C++ has historically had a very heavy exceptions model. I can't speak about whether it's gotten better, because I dismissed using exceptions a while ago, and haven't had any reason to go back and change my perceptions (okay, so I picked up VS.NET the other day, and in the new SDK some old functions I was using were deprecated and the new functions that replaced them throw exceptions, so I may be forced to start caring about exceptions, but if I had my way I wouldn't). This is what I'm referring to. It is (was?) expensive to throw an exception, and so code that is performance-sensitive avoids them like a plague. Given the same code written for exceptions and written for a lightweight error reporting facility, the lightweight facility will be faster given that at least one exception is thrown. I can't give you a code sample, however, because all the server-side work I've done has been for my employer, and I don't want to run the risk of exposing intellectual property. Since I'm only speaking about server-side code that needs to perform well under scale, client code would be a red herring, and so I won't bother trying to find an example there (likely I can't).
You don't need to handle every error right where it could happen; errors just slide down the stack until they are handled. Programmers are lazy enough that when they have to handle every error right where it happens (many if statements after repeated calls), they don't. So anything that makes error handling easier makes better (yes, more secure) code.
IMHO, it's poor programming practice to let your errors slide up the stack without doing anything about it until you get to the top level (or any level above where the error happened). The farther from the source you handle an error, the harder it is to determine what exactly caused the error to begin with. In that vein, I prefer a small section of general cleanup code at the end of a function, and macros that do something along the lines of if (an error occured) { // do logging, if you wish // goto the function's cleanup section }
Every function that uses the macro will need to define the label used by the macro, but that's a small price to pay to be able to catch your errors where they occur, using a lightweight yet robust (if you enforce its use, of course) error-handling mechanism. You'll end up with code that looks like: err_type SomeFunction(...) {
err_type err;
err = dostuff(...);
CheckError(err);
err = domorestuff(...);
CheckError(err);
ErrorHandler:
// general cleanup, possibly special-casing "if (err)"
return err; }
I much prefer that for readability to void SomeFunction(...) throws AnException {
try
{
dostuff(...);
domorestuff(...);
}
catch
{ // error handling here
} /* more catch statements, if you're doing things the "right" way, and not just catching broad exceptions, but catching specific ones */
finally
{ // cleanup here
} }
Sure, it's probably personal preference, but I know what I like, and I know what's easier for me to read.
In fact, you really should try writing Java code. You'll absolutely hate the performance (if you are doing gotos to get an extra nanosecond or whatever, you'll hate virtual machines). But it does exceptions extremely well, and you'll see they are a far superior way of handling errors correctly. And maybe it will teach you that a few nanoseconds here and there aren't as important as having proper algorithms - differences of seconds or minutes. Basically any little bit of code in Java will execute more slowly than C/C++, no matter what the Java advocates say. But if you do things properly, you can have a larger program that is not much slower - by spending time you would have spent on little things to improve the overall design.
I have tried Java programming (okay, so it was only for a lame elective class at university, because I was luckily a class or two ahead of all the changes to java. They even changed the AI class and the OS class to use java!). It never really grew on me. Maybe it was because this was something like four years ago, and things have changed, but I don't see me using java in the near future, either.
As far as the importance of algorithms go, you are correct. I totally understand that optimizing a poor algorithm is worse than not optimizing a better one. However, there does come a point where overhead does matter, and comparing lightweight goto-enabled error handling to heavier exceptions when dealing with server-side work (software that has to scale well, and still be performant), there is a difference. If you're talking on the client side, then it doesn't make much difference (obvious exceptions (excuse the pun): areas where performance is critical, such as games or embedded systems).
That's half true. You still have to make sure you deallocate properly (call delete or delete[] appropriately exactly once). But you don't necessary need to check return from new - it throws an exception instead of returning null.
God, I hope not. Exceptions are bad, especially when you're dealing with server-side software that needs to be performant. I much prefer an error code (say, HRESULT, if you're in the windows world), and a smallish error handler (usually reached via a goto, but the goto gets hidden in a macro). Much lighter on resources, and I prefer it. Plus, you don't have to write extra code for functions that don't already throw exceptions, though you'll still need to try/catch exceptions from functions that do throw them (ugly).
Then again, maybe I just don't like exceptions. Which is true.
Not true. There's an entire class of vulnerabilities that printf and scanf are vulnerable to that cin and cout are not: format string vulnerabilities. I think cin and cout suck, but they are unquestionably more secure than C-style format strings + varargs.
Right, format string vulnerabilities go away. That's good. However, you can still easily overflow a buffer. Yes, if you're writing pure STL code, and using string everywhere, you should be safe(r), but many people still use char*'s, and more importantly, many people prefer char*'s (or something based on char*, anyway. Again, perhaps that's only my preference).
My point was that simply switching from C to C++ is not enough to buy you security. You might get some things for free, but to truly be secure, you'll still have to code securely. There's no way around that (okay, there is, but it involves moving to languages other than C or C++).
Slashdot Mirror
Quoting from ESR
Believe it or not, Microsoft is a very agile company. They did a complete 180 in the mid-90's, going from almost complete lack of regard for the internet to almost complete and total embrace (everything was internet enabled, or embedded html, or whatever). If I were on Wall St., I wouldn't be worried that Microsoft can pull off the change, only that it may not be the proper direction (for what it's worth, I think Microsoft is going in the right direction, but that's a different comment).
Microsoft doesn't have any of the technology in place for the new business model? What? ESR needs to realize that just because he says something doesn't make it true. Last time I checked, Passport was alive and kicking with quite a few members, the .NET servers were shipping, Windows 2000 could install the .NET Universal Run Time, Visual Studio.NET has shipped, etc. In other words, the infrastructure is now available to build (VS.NET), deploy (VS.NET again, .NET servers), and run (.NET URT, .NET servers, Win2K, Passport, etc) .NET services. However, ESR obviously doesn't see that. He also, apparently, doesn't see what .NET is all about, if he thinks it's just a fancy name for an ASP.
ESR is a smart guy, or can be when he tries, but he should stick to espousing his open source propaganda and leave it at that. He's shown that he has no clue about Microsoft's past or present, and that makes him singularly unqualified to comment on their future.
Funny, last time I checked, C++ was an object-oriented language. (Okay, if you program in "C++", by which I mean C with a smattering of C++ syntax, then sure it's imperative. But that's not C++. That's C with syntactical sugar.)
Assuming by this you mean "moving to the Windows platform", why bother? When Microsoft said they want the .NET CLI to be cross-platform, they meant it.
In the Windows world, many applications do have powerful commandline features, as well as GUIs. However, you're trying to impose a unix-style of automation (shell script, tying a bunch of small commands together) on a system with its own methods of automation. Let me first say that there are tools you can install on Windows to do unix-style scripting, like Cygwin. I'm ignoring that for now. Typically, when you want to script something in Windows, you'll end up writing some vbscript or jscript that instantiates a COM object and does what it needs through that rather than running an app with some params and catching/piping stdin/stdout. I won't say which method is better, simply that they're different.
This is why *nix administration knowledge doesn't translate to NT administration knowledge, and vice versa. Too often people complain about NT admins trying to use linux or some other unix without ever thinking of the reverse scenario. Try writing a script to force a change of password on next login for some number of NT users. Now make sure it works for local users, NT4 domain users, and Win2K AD users. This is quite doable, but most unix admins look for a passwd-like app, find none, and give up, complaining that NT sucks because they have to go through a GUI to modify 50,000 accounts.
My bad, then. I'm not 100% familiar with the FHS myself, so I made the (poor) assumption that when the author said that's what the FHS defines, he was speaking authoritively. Apparently not. If slashcode would allow editing of comments, I'd fix this assumption.
From the article:
I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong. Perhaps /usr/local is obsolete with respect to package managers, and that makes some sense (because the package manager should handle proper management of placed files, though in practice that's not always the case), but as long as open source is around, there will always be software that is compiled rather than installed through a package manager. There will also always be applications that are not distributed in your package format of choice (as long as there is more than one package management system, this will always hold true). In these cases, it's still a good idea to keep around /usr/local and /opt. Personally, I'll have /usr/local on my systems for a long time to come, because I prefer to use the Encap management system.
I disagree. It is just as easy to write poor code in Java as in any other language. In fact, I'd be inclined to suggest that Java actually hinders good design, with its fragile system of inheriting everything from Object. That's Bad Design (tm), and should be avoided. If you want to be able to use something like Java's native collection classes (lists, for example), you have to inherit from Object even if doing so runs against your design. Better to either use a dynamically typed language (for example, Smalltalk), or a language with generic programming constructs (templates in C++). A smaller set of limitations may be imposed (for instance, it may be required that the class implement some sort of comparison operator, for sorted lists), but that does away with requiring inheritance from Object. (what happens if/when Object changes? everything that inherits from Object will need a recompile, at the very least.)
It may be "easier" to make a good design in Java than in C, but it's even easier if you use something like C++ and STL (caveat -- you need to know the language you're working with. If you're using C++, but treating it like C, it's going to be no better than C. Same for Java if you treat it like C++).
It's not so simple as that. The XBox may not have generic co-processors, like the PS2's two vector units, but it does have a very powerful graphics co-processor, and another very powerful audio co-processor. Currently, the PS2's VUs are being used for things like enhanced graphics effects (doable on the XBox's GPU) and audio effects like surround sound (the XBox does dolby digital natively in hardware). Yes, if the PS2 had the same powerful graphics and audio processors, then the extra VUs would be a huge asset. As it is, those co-processors need to be used just to keep up with what the XBox can do.
Hrm. Emacs developer. RSI problems. Think it could be all that insane chording required by emacs? Use a good editor, try vim.
Right, so this is flamebait because I corrected his incorrect explanations. Damn moderators.
True enough, but if you're at the point where 1C makes a difference, then you ought not be overclocking, or should get a better HSF. A shim is physical protection, not thermal protection.
The AC poster was wrong, and so are you. Thermal compound (arctic silver, the thermal pad you see on most HSFs, other grease) is completely different. It's used to fill in the microscopic holes in the top of the CPU core and bottom of the HSF (good HSFs are machined smooth, but if your HSF isn't, with a little patience you can lap it smooth). You only want a very thin layer of this stuff, because while it is thermally conductive, it's not as conductive as a dry metal<->metal joint. You want just enough to create a light film on the CPU core (if you get a little too much, that's fine as the pressure of the HSF will squeeze the excess out -- if you get way too much, grab some rubbing alcohol, clean off the core, and start over). It works best if you squeeze out a small line of the stuff, and then draw it across the CPU using a credit card.
Shims are for spacing, period. (other posts have explained shims sufficiently, so I'll leave that as an excercise to the reader.)
Nope. A shim is generally not thermally conductive (and better damn well not be electrically conductive ...), since it doesn't matter whether it is or not.
Again, wrong. The idea is not to increase the amount of contact surface between the CPU and the heatsink, as this would be impossible to do, unless you made the CPU itself larger -- heat only radiates off of a CPU from the little rectangular core in the middle; the ceramic surrounding the contact point has little to no thermal conductivity. Instead, the idea is to give the heatsink a larger area to which to apply pressure. This means it's going to be more difficult (though not impossible) to chip the CPU core if you're using a shim than if you're not. Shims only became popular with the Athlon Thunderbird chips that were trivially easy to break with a sloppy heatsink install. Since those shims were made out of copper (bad! that's electrically conductive, which means you could very easily short out your CPU), many of the more clueless overclockers instantly thought "copper == cool", and thus assumed that shims were another way to lower their CPU temps by a couple more degrees. They were wrong.
Please mod the parent AC up. Also, for those who don't see AC's, here's the full story from a less-biased source.
Only if by "legacy code" you mean "guys that worked on VMS also worked on NT, and thus may have had tendencies towards doing things in a VMS way", rather than "old VMS code", since NT was a completely new OS. Also, while NT did for a while have an OS/2 subsystem, that's no longer in XP, and it was along the lines of the POSIX subsystem -- it was not part of the OS, other than that it added a layer to NT to allow POSIX or OS/2 apps to run. Other than the fact that NTFS was originally loosely based on HPFS from OS/2, that's the only OS/2 code you'll find in NT.
I know this is off-topic, but it's FUD that comes up quite often. Let me first say that yes, I do realize that the XBox controller is large. However, having said that, only those who have never used one (the fixed-position controllers on the XBox store displays don't count, because you can't hold those in a comfortable position) would complain about the XBox controller. Its largeness makes it feel very solid in your hand, more like a power tool than a game controller, while the ergonomic design and button layout makes the main action buttons and sticks easily accessible while holding the controller in a comfortable position.
This being slashdot, anecdotal evidence is considered irreproachable, and so I have some anecdotal evidence of my own. I've played many gaming consoles, from the original NES to the Genesis and SNES, through the N64 and Playstation (which would be the same as the PS2), and finally the GameCube and the XBox. Out of all of those controllers, the XBox controller is the only one with which I've ever been able to play for multiple hours without cramping or fatigue. The others were too small, or oddly shaped, or, in the case of the NES controller, had sharp corners. The XBox controller just fits right in my hand, and is as comfortable as console gaming gets.
Having not used NT4 in quite a long time, I can't be 100% sure the functionality is there or not. It definitely is in Win2K and XP (it's provided by the RunAs service, and there are several other ways to access it than by what I gave in my previous post). Try searching NT4's system help for "run as" and see what comes up.
Also, shift-right-clicking may not be very deterministic -- it only works on some file types (it seems to work on most executables or shortcuts to executables, but not something like the IE icon on the desktop, and not on document files that spawn an executable through the filetype handler), and you have to make sure you highlight/select the icon (click once if using classic double-click mode, hover briefly if using the single-click mode) before then shift-right-clicking.
And that's why Windows NT/2000/XP have the ability to run as different users. It's a little convoluted (highlight the app you want to run, shift-right-click the icon, select Run as, click The following user radio button, give the username and password of an administrative user), but it's available. Also, this will only work for executables or shortcuts to executables, so while you can run Word as a local administrator while logged in as a normal user, you can't start Word as a different user by trying to run a .doc file
You misunderstand. I was not saying that User Friendly peddles Flash to their readerbase, but that they pretty much sell their fanbase to companies by way of awful custom-made Flash animations that supposedly target the "geek demographic".
At least they're not peddling their readership to businesses by offering poorly-animated, humor-lacking Flash animations. Gabe has always done art for things other than Penny Arcade. His art is a regular staple over on the Gamespy Network. At the very least, Gabe's art is good enough that he doesn't have to whore himself out to get work.
Shouldn't User Friendly be apologizing to you for subjecting you to bad art and no humor? The Penny Arcade guys were right. "People will pass up steak once a week for crap every day."
The .NET framework is freely available, and includes compilers for managed C++, C#, and VB.NET. Get it at MSDN. That gives you "everything you need to write, build, test, and deploy .NET Framework applications - documentation, samples, and command-line tools and compilers." Of course, it doesn't include the Visual Studio IDE, so you'll have to write your code in something else (Source Insight, Notepad, vi, emacs (*shudder*), whatever), and you won't have any gui for drawing window forms, but you can still build and deploy applications. The only requirement is that you're running on an NT-based OS (Windows NT 4 SP6a, Windows 2000 (SP2 recommended, but not required), or Windows XP Pro) and have IE5.01 or later.
Right, guard classes are good things to use, and I often do use them. In particular, I enjoy using the ATL classes CComPtr, CComQIPtr, CComBSTR, and CComVariant. CComPtr probably gets the most use out of me, because it's the most generic. It simply attaches to a pointer (or can create a pointer itself, if you'd rather do it that way), and takes care of deallocation for you when it goes out of scope. CComQIPtr is beautiful if you ever do any COM programming (no more cumbersome QueryInterface calls! CComQIPtr will do it for you). CComBSTR and CComVariant are essential for interop with automation (VB, windows scripting). (I'm giving Windows examples, because that's what I know.) Even so, there can still be general cleanup issues that you need to take care of, even when using guard classes. A trivial example would be doing some logging and rolling up an error value into something useful ("error value" meaning success or some type of error). Sure, the latter isn't necessary if you use exceptions, but logging is always good (okay, so it's a contrived example. pfah!)
C++ has historically had a very heavy exceptions model. I can't speak about whether it's gotten better, because I dismissed using exceptions a while ago, and haven't had any reason to go back and change my perceptions (okay, so I picked up VS.NET the other day, and in the new SDK some old functions I was using were deprecated and the new functions that replaced them throw exceptions, so I may be forced to start caring about exceptions, but if I had my way I wouldn't). This is what I'm referring to. It is (was?) expensive to throw an exception, and so code that is performance-sensitive avoids them like a plague. Given the same code written for exceptions and written for a lightweight error reporting facility, the lightweight facility will be faster given that at least one exception is thrown. I can't give you a code sample, however, because all the server-side work I've done has been for my employer, and I don't want to run the risk of exposing intellectual property. Since I'm only speaking about server-side code that needs to perform well under scale, client code would be a red herring, and so I won't bother trying to find an example there (likely I can't).
IMHO, it's poor programming practice to let your errors slide up the stack without doing anything about it until you get to the top level (or any level above where the error happened). The farther from the source you handle an error, the harder it is to determine what exactly caused the error to begin with. In that vein, I prefer a small section of general cleanup code at the end of a function, and macros that do something along the lines of
// do logging, if you wish
// goto the function's cleanup section
// general cleanup, possibly special-casing "if (err)"
// error handling here
/* more catch statements, if you're doing things the "right" way, and not just catching broad exceptions, but catching specific ones */
// cleanup here
if (an error occured)
{
}
Every function that uses the macro will need to define the label used by the macro, but that's a small price to pay to be able to catch your errors where they occur, using a lightweight yet robust (if you enforce its use, of course) error-handling mechanism. You'll end up with code that looks like:
err_type SomeFunction(...)
{
err_type err;
err = dostuff(...);
CheckError(err);
err = domorestuff(...);
CheckError(err);
ErrorHandler:
return err;
}
I much prefer that for readability to
void SomeFunction(...) throws AnException
{
try
{
dostuff(...);
domorestuff(...);
}
catch
{
}
finally
{
}
}
Sure, it's probably personal preference, but I know what I like, and I know what's easier for me to read.
I have tried Java programming (okay, so it was only for a lame elective class at university, because I was luckily a class or two ahead of all the changes to java. They even changed the AI class and the OS class to use java!). It never really grew on me. Maybe it was because this was something like four years ago, and things have changed, but I don't see me using java in the near future, either.
As far as the importance of algorithms go, you are correct. I totally understand that optimizing a poor algorithm is worse than not optimizing a better one. However, there does come a point where overhead does matter, and comparing lightweight goto-enabled error handling to heavier exceptions when dealing with server-side work (software that has to scale well, and still be performant), there is a difference. If you're talking on the client side, then it doesn't make much difference (obvious exceptions (excuse the pun): areas where performance is critical, such as games or embedded systems).
God, I hope not. Exceptions are bad, especially when you're dealing with server-side software that needs to be performant. I much prefer an error code (say, HRESULT, if you're in the windows world), and a smallish error handler (usually reached via a goto, but the goto gets hidden in a macro). Much lighter on resources, and I prefer it. Plus, you don't have to write extra code for functions that don't already throw exceptions, though you'll still need to try/catch exceptions from functions that do throw them (ugly).
Then again, maybe I just don't like exceptions. Which is true.
Right, format string vulnerabilities go away. That's good. However, you can still easily overflow a buffer. Yes, if you're writing pure STL code, and using string everywhere, you should be safe(r), but many people still use char*'s, and more importantly, many people prefer char*'s (or something based on char*, anyway. Again, perhaps that's only my preference).
My point was that simply switching from C to C++ is not enough to buy you security. You might get some things for free, but to truly be secure, you'll still have to code securely. There's no way around that (okay, there is, but it involves moving to languages other than C or C++).