That's because Nero and Roxio no longer try to market a streamlined product for burning buffs. Most of the people burning things these days have no clue about how it works and expect the burning software to do more than burn a disc. For example, burning a DIVX movie they downloaded to a disc they can play in their DVD player. They drag the movie onto the project in Nero and expect it to figure out the details, like converting the video/audio, settting up the disc layout and burning an SVCD disc. Roxio takes this a step further by monitoring and popping up the instant you put in a disc and attempting to figure out what you want to do with it.

Half of the tools that come with the full Nero package are things like a media center, media sharing server, photo manager, sound/video editor and numerous other apps that have nothing to do with burning a disc.

Tools like MagicISO or PowerISO have become the tools for people who just want to burn discs and work with image files. Nero and Roxio have become some sort of massive media suites that also happen to burn discs.

If you wanted the best performance for your new computer you should install MS-DOS. Naturally MS-DOS is somewhat lacking in features as you probably want to use things like multitasking, protected memory, a TCP/IP stack etc on your new computer.

My point is that computers are expected to do a lot more things and there is more abstraction between the software and the bare metal. MS-DOS was fast but programs had to do everything themselves. For example, to draw a line on the screen you would have to manually query the video adapter and determine how to write to it's memory so it does what you want. On modern systems there's usually a display driver and an API (like GDI) which separate the programmer from the hardware. The program can draw a line without knowing anything about the specific hardware or VESA screen modes.

VBA is just the macro language. Developing an Office application in VBA would be a project of gargantuan magnitude. that kind of project would be difficult even with full Visual Basic 5/6. I don't think VBA can be compiled into an application either. I would assume most of the Office apps are written in C++, and expose their VBA interfaces using COM.

People forget how heavily COM is used in Windows too. It hides the component's underlying implementation so components can be written in any language and used in any language that can query the component's interfaces. Of course, the layer where COM is implemented is far above the kernel, HAL and base subsystem libraries which are done in C.

The programming language has nothing to do with the security of the system, it's the quality of the programmers. They could code the entire thing in QBASIC and still have a secure and stable system if they know what they are doing. I doubt they are using a bunch of greenhorn C++ programmers, so it won't be like herding cats for them.

I don't know a lot about ADA, but I do hear that it is better suited for embedded systems, and (as you mentioned) is more proven in those scenarios. It also has a lot of built in checking which would probably make securing it easier. It doesn't mean it's the only choice however. There must be a reason for them to decide on C++ (I hope).

Windows btw is written mostly in C. C++ is awkward for writing operating system kernels and core API's, so it is generally not used for that (although it can be done). If you look at Charles Petzold's "Programming Windows 95" you will not see any C++ code in the whole book. All of the Win32 API's are built around C but are made easier to use with C++ wrappers like MFC.

Are you sure it's a true DOS application and not a Win32 Console App? I know it is entirely possible for someone to write a CGI in DOS but it seems really weird to me that they would use DOS since it didn't have anything that would server CGI, and coding a hand rolled database format would be a lot of extra work.

If it is using Win32 it might just be accessing a DAO database without using the mdb extension, which many companies do to make it look like a proprietary format you can't just open with MS Access. If you look at the raw data it might look crazy and unusable because JET databases use XOR to obfuscate the contents of the database file (and prevent you from extracting the strings inside).

I also have spent a long time dealing with FileMaker too and it can be a huge PITA. Be thankful you didn't have to maintain a FileMaker Pro Server or web server for many people!

It is very easy for non-tech savvy people to use to build a bunch of databases and start using them which is cool. The problem is that the databases have a very simple design and most people don't even know how to setup a relationship between two fields. They just drag and drop fields onto a form and let FileMaker figure out how to store and share the data.

Those databases then tend to evolve and as they get more complex they are harder to manage using the simple interface that FileMaker Pro tries to provide. One person's quick inventory tracking database suddenly becomes a massive asset database used by the whole company years down the road, and you're left struggling to keep it running.FileMaker Pro and Lotus Domino are the worst for this kind of thing.

IIRC there are a few ways to extract the data from FileMaker Pro databases. There is an ODBC driver that comes with the FileMaker Pro client (at least it did back in the 3.x and 4.x days). That would be the easiest way to extract the data for other applications to use. FileMaker Pro 4.0 used to also come with a web server plugin that would use CDML to generate dynamic web pages from the database (of course Claris HomePage was the best tool to nuild CDML apps at the time).

CGI works by having the server executes the program (passing the data to it from STDIN or the command line) and then retreiving the page's complete HTML code from STDOUT. You can use any file that can be executed and use STDIN/STDOUT in this manner that is located in a specified location(like cgi-bin). On Windows this would be any exe,com,pif,bat or cmd file, and the extension must be there for the operating system to determine that it is an executable. On Linux you can use any file that +x permissions, compiled binaries or scripts with a bang at the beginning, so it can have any extension you want (or none) for a CGI.

People used to write a lot of CGI applications in perl because of it's text processing capabilities, but there were many CGI's that were compiled programs (written in languages like C). At one point Microsoft was really pushing the idea of easily writing CGI applications in Visual Basic and hosting them with IIS.

CGI fell out of popularity in favor of embedded scripting like PHP and ASP which have much less overhead (they don't have to create a new process to service every user request and wait for it's output) and are much less complex for people to use (they don't require special directories or permissions).

I really like your idea of laying out the problems with IE6 to the end user and providing solutions for them to upgrade, but your other comments about people being spineless and greedy because they can't do the same makes you look like a fanatical asshole.

Your job as a developer is to develop code that meets the needs of your users and customers, not to dictate what you like to them and make an ideological stand. If you tell your boss or customers to fuck off because you don't like their browser then they find a developer who will do the job that they are fucking paying him to do. The end user doesn't give a shit about open standards or who follows them, they want to get shit done. Standards are nice but if they aren't laws, and we have to follow supply and demand if we want to feed our family and succeed in the real world.

Even Microsoft had to do shit like make sure Word could open WordPerfect documents and IE could open web pages built for Netscape. If they had told customers to fuck off because they wanted to do things the way they liked, no one would use their shit and they wouldn't be in the dominant position they are in today.

Yes you're comparing a string under a single thread in the same memory space. Now multiply the CPU time by the number of requests that probably go across the OpenID servers every second and also take shit like context switching and memory management into account. You can't assume a highly loaded server is the same as your workstation.

For example, on one of our Windows servers someone installed the J2RE which also runs an updater app when you login to your profile. It used 100MB of memory but it was almost entirely paged to disk so he thought it was ok. The problem was that it was a Citrix server which thousands of people logged to every day (each running a copy of the updater app). Pretty soon that 100MB of added up to gigabytes, consumed the entire size of the paging file, and the server started to run out of memory.

While it may sound strange to you, most people aren't interested in writing scripts and compiling source code on their iPhone.

There were lots of games that didn't have the Nintendo seal of approval. Most games made by Tengen, Color dreams, and CodeMasters were unlicensed.

Yes but Nintendo restricted unlicensed cartridges with their 10NES protection scheme. Any NES built after 1987 would would continually reset itself if it couldn't authenticate with a 10NES chip which was only included in licensed cartridges.

First of all, when a hard drive is turned off and unplugged, the moving parts aren't moving. So the mechanical wear and stress of constant operation aren't really a problem.

Hard disk parts can also become seized and have trouble starting if the drive is inactive for a lengthy amount of time. I'm not sure how long it takes or how often it happens though.

In the real world the manager justifies his job by cutting costs wherever he can. I've never seen a manager get rewarded for being proactive and spending a lot of money. If anything they'll ask him to reduce the IT budget this quarter because none of them know what the IT guy actually does.

BREW is an API layer which sits above the phone's native API in order to provide a consistent programming interface across various phones. You write BREW apps with C or C++ and compile them into binaries. BREW is basically just a wrapper which translates the BREW APU calls to the phone's internal low level API calls. It would actually be stupid to code all your apps for the phone's native API because it will be different on every single model of phone, and you would have to re-write them every time.

Because it's professional to kick someone ... because you don't like the way that they type

I haven't used IRC in a while but I don't ever remember it being very professional, and yes, anything the channel ops don't like gets you kicked (at least in the channels I used to hang out in). The fact that they gave him 30 minutes before kicking him from the channel is probably as professional as you can get.

He was typing weirdly, posting password hashes to main...he could be an RIAA agent in disguise, just some crazy guy threatening to hack them, he could be anybody. Channel operators aren't there to make friends with everyone in the channel, they are there to keep things in check.