The Sega 32X system was designed to breath new life into the aging MegaDrive and Genesis video game console, which was being ripped apart by Nintendo's juggernaut the SNES. Sadly, it didn't do so well and quickly evaporated from store shelves. Despite the poor reception, it's still has a birthday, so make sure you play your favorite title tonight. It shouldn't be too hard to pick one, given the limited selection of good titles for that platform. It's probably for the best that we don't mention the Sega CD either... well, despite my obvious misgivings about the system, I know it is near and dear to a more than a few people. So Sega fans, on this happy day, I salute you!

The Nintendo DS needs no introduction, since many of you have an incarnation of that device sitting in your house right now. With over 149 million units sold worldwide, I think it could be considered a success. Let's do a little math, shall we?

149,000,000 x $150 + (149,000,000 x (6 * $40)) = $58,110,000,000

That's an average cost of $150 dollars per unit, and each unit having an average of 6 games which sell for an average of $40 each. Let's assume that 70% of that amount went to pay for everything from manufacturing, to licensing, to marketing and employee salaries. We're still talking close to $20 billion in the clear.

So Nintendo Corporation, while you sit upon your mountain of money contemplating this special day, we the bottom dwellers of society raise our filthy hands in a formal salute!

As an aside, the usability goals for an editor within an IDE such as Borland C++, seem to be the exact opposite for the goals set out by the authors of many PEs. The editing within IDE is almost universally easy to use, while performing the same tasks within a PE requires practice and certain degree of research. Approaching this from the viewpoint of a novice looking into the dark world of a seasoned, and perhaps a little cynical UNIX-computer programmer, it would seem a little odd since the interface of an IDE can do so many different tasks (and thus have so many opportunities to botch things up), whereas a PE tends to be targeted to one task: editing source code. Surely, with fewer features, it must be easier to craft something which is even easier? It's almost as if the author of a PE is trying to compensate for lack of development features by throwing in additional editing complexity. For example, how many standard forms of regular expression syntax does your PE support? If you answered anything other than "as many as I want since I can simply write a plug-in to support it," then you're not using the right editor.

I stumbled across TDE while browsing the download area for a local BBS. It included the source code for the program which was written in C, and it seemed to have a variety of interesting features; it certainly had more technical features than the QuickC editor I was using at the time. I guess I gravitated towards complexity at the time, and I quickly grew to love TDE and began modifying the source code to suit my needs. If I were to use the latest version of TDE today, I'm betting a lot of those hacked-in features would already be implemented.

The code for TDE was a great learning experience for me. It was organized fairly well so it made for relatively easy modifications and creative hacks. I lost the source code for my modified version during The Great Hard-drive Crash in the mid-1990's. For some odd reason, I didn't have a single back-up. It was particularly strange since most of my favourite projects were copied onto a floppy disk at some point. Frustratingly, I think I still have a working copy of the original 3.X code on disk! Anyway, the source code had excellent implementation details like fancy text and syntax handling, decorated windows, and reasonably tidy data structures. I don't remember using any code from the editor in any future project, but I certainly took away a number of ideas. Doublely-linked lists may not seem like a big deal to me now, but I hadn't read that many books at this point, so glimpses of real implementations using these data structures was very cool and inspiring. I found the windowing classes and structures particularly interesting since some of the windows were used for configuration, others for editing, and some for help. This was the first abstraction for a windowing system within an application I had run across. It was beautiful and gave me a lot of ideas for HoundDog - a future project which was used to track the contents of recordable media like floppies and CD-ROMs, so that I could find that one file or project quickly without needing to use those floppy labels.

QBasic shipped with MS-DOS 5 and consisted of only an interpreter, meaning it translated small chunks of code into machine code as they were executed (I believe it did cache the translated portions, so it wouldn't need to translate them again). QuickBASIC was more advanced and had a compiler as well as an interpreter, which allowed it to translate and optimize the machine code it generated before you ran it. It had only one dependency during compilation, and that was the QB.LIB library. Using the QuickBASIC IDE or the command line, you could compile multiple modules into a single target which could be a library or an executable program.

QuickBASIC was handy for prototyping and demos. I didn't need to do many of these for my own projects; although, I did a lot of experimentation with network interrupts before porting those routines and programs to C. QuickBASIC was mainly used for projects and demos at school and eventually college; many of them were also written in C due to a few course requirements.

While in college, I had written a chat application over a local area network for DOS before the concept became popular. It was using the SPX protocol for some parts, and the IPX protocol for others. It only supported peer-to-peer communication and only with one other person, bit it served as a demo for simple network communication, and many of the students used it quite regularly.

In other programs, I was using Novell Netware interrupts for communication, broadcasts and client machine discovery. I loved it and found coding these applications fun and exciting; my Ralph Brown textbook was well used during this time. I think my interest in programming these network applications stemmed from my days playing DOOM over similar networks. Basically, I just loved lot the potential for interactivity, which is a tad ironic since I was fairly quiet programmer back then. A few of my friends became interested in the software I was writing and one day we decided to play a few practical jokes on my fellow students. We created a custom program for sending messages via the Netware API. These messages could be broadcast to every machine on the network, a group of machines, or a specific machine. When a machine received one of these messages, it would display a dialog and show the user a message. Pretty simple concept, but many people were not aware their machines could even do that, or what it meant to even be on a network.

Simply using the network software which came with Netware wasn't an option, since the message dialogs produced by those tools contained the name or address of the machine from which the message originated. According to Steve Wozniak, co-founder of Apple Computers and well-known prankster, the most important element to any gag is not to get caught. We needed to customize the message being sent so that it included only the details we wanted to send, and the only way to do that was to write a custom program. This was fairly easy since I had been writing software on Netware for several months, and when the packets were sent off through the network, our machine name was carefully omitted and our address forged.

We used the program to send funny or confusing messages to some of the students. No profanity or crude humour, mind you... well nothing too crude anyway. My goal was always to get the user to believe what the machine was telling them. I had convinced one student her computer didn't like the way she typed; her keystrokes were always too hard or fast for the computer's liking. She had actually phoned the administrator's office and asked them for a computer which didn't complain so much! Several computers were being used by students to view pornography, so I did my best to make them feel uncomfortable in a public setting. Many of them believed they were being watched by the network administrators, which could have been true (although network monitoring software was generally never used or not available). Anyway, these people quickly shuffled out of the room red-faced, hoping not to get caught on there way out. I still get a giggle out of it even now, when I think about it.

In a way, I am kind of saddened by the complexity of today's operating systems. Trying to write the same software on modern machines would be extraordinarily more difficult today, mostly because of new operating system features and application stacks. They just aren't managed in the same way anymore, so a programmer's ability to exploit a network so directly has disappeared. That being said, I don't particularly disapprove, it's just not as easy to have a little fun.

There are a number of differences between the BASIC and C programming languages. One of the more obscure differences lies in how the C programming language deals with special variables that can hold memory addresses. These variables are called pointers and are an integral part of the syntax and functionality of the language. BASIC did have a few special functions which could accept and address locations in memory - I'm thinking of the CALL and USR functions specifically, although there were others. However, a variable holding an address was the same as one holding any other number since BASIC lacked the concept of strong types. The grammar of the C language is also much more complex than BASIC; it had special characters and symbols to express program scope and perform unary operations, which introduced me to the concept of coding style. When a programmer first learns a particular style of coding, it can turn into a religion, but I hadn't really been exposed to the language long enough to form an opinion. That would come later, and then be summarily discarded once I had more experience.

There were libraries of all sorts which provided functionality for working with strings, math functions, standard input and output, file functions, and so on. At the time, I thought C's handling of strings (character data) was incredibly obtuse. Basically, I thought the need to manage memory was a complete nuisance. BASIC never required me to free strings after I had declared them, it just took care of it for me under the hood. Despite the coddling I received, I was familiar with the concept of array allocations since even BASIC had the DIM command which dimensioned array containers; re-allocation was also somewhat familiar because of REDIM. However, there were many more functions and parameters in C related to memory management, and I just thought the whole bloody thing was a real mess. The differences between heap and stack memory confused me for a while.

There were many features of the language and compiler I did enjoy, of course. Smaller and snappier programs were a huge benefit to the somewhat sluggish software produced by the QuickBASIC compiler and the BASIC interpreter. The compiled C programs didn't have dependencies on any run-time libraries either, even though there was probably a way to statically link the QuickBASIC modules together. Pointers were powerful and were loads of fun to use in your programs, especially once I learned the addresses for video memory which introduced me to concepts like double buffering when I began learning about animation. Writing directly to video memory sounds pretty trivial to me right now, but it was so intoxicating at the time. I was more involved in game programming by then and these techniques allowed me to expand into areas I never considered. It allowed for flicker-free animation, lightning fast ASCII/ANSI window renderings via my custom text windowing library, and special off-screen manipulations that allowed me to easily zip buffers around on the screen. A number of interesting text rendering concepts came from a book entitled Teach Yourself Advanced C in 21 Days by Bradley L. Jones, which is still worth reading to this day.

At around this time, I also started to learn about serial and network communications. The latter didn't happen until my last year at high school. Basically, I wanted to learn how to get my computers to talk to one another. It all started when I became enchanted by the id Software game called DOOM, which allowed you to network a few machines together and play against each other in a vicious winner takes all death-match style combat. Incidentally, games like Doom, Wolfenstein 3D, or Blake Stone: Aliens of Gold led me down another long-winding path: 3D graphics, but that didn't happen until a few months later. Again, the book store came to the rescue by providing me with a book entitled C Programmer's Guide to Serial Communications by Joe Campbell. I was somewhat familiar with programming simple software which could use a MODEM for communication, since BASIC supported this functionality through the OPEN function, but I knew very little about the specifics. Once I dug into the first few chapters, I knew that was all going to change.

I am living in an area now which is a tad on the remote side, so finding a decent video rental store is next to impossible, and the store I did find only provides a very small number of titles, most of which are still recorded as VHS cassettes. When my wife first talked to me about NetFlix, I must admit I was fairly reserved at the idea. I was mostly concerned about movie selection, but movie quality was also high on the list as well. After using it for a little less than a month, I must give the service 5 / 5 stars. I did see some minor quality problems in some movies, and the service had a bandwidth hiccup or two (probably not their fault), but overall I am very pleased with the video and audio quality and movie selection process. The NetFlix application on my PS3 is very easy to use with snappy response times and a rating system tuned to your personal tastes. The rating system does take time to learn what you like to watch, and it's important to rate a film after you watch it.

The service costs $7.99 per month with the first month being free at the time of this writing. A standard-definition movie which runs for 2 hours consumes approximately 1.8 GB of data, while a high-definition movie running the same amount of time chews through approximately 3.0 GB of data. I don't know what the consumer break-down is for Roger's service plans, but one of their plans gives you a 60 GB transfer limit (upload + download) per month. Overage costs vary with your plan, and our plan costs us $2 for every GB over our 60 GB limit up to a maximum of $50 per month. We live in a 5 member house and four of us work in the technology sector, which means our tendency for data consumption is usually higher than most families, except those families with one or more tech savvy teenagers doing strange things in their basement. What this usually means is that we tend to consume more than half our available transfer limit just doing our day to day activities for work or recreation, which leaves less than 30 GB of wiggle room. That leaves us with the capacity for watching approximately 11 standard-definition movies, or  5 high-definition ones without getting charged extra. Since I prefer to watch some types of films in high-definition, my film roster is looking fairly small for an entire month, so naturally I'm going to enter into overage costs, rent more movies, or just do without.

I personally know a few families who use NetFlix mostly to provide entertainment for their children. I am wondering how often they run into overage costs since kids love to watch movies repeatedly, and does it save them money if they didn't need to rent or buy those videos? For those types of users, it would be nice if NetFlix offered a download and record option so that the movies do not need to be repeatedly streamed. Those cached movies could have an expiration date based on the last time the movie was viewed (and not based on when it was downloaded), since NetFlix supports the policy of watching a movie as many times as you like. As usual, it would also behoove Rogers to offer more competitive Internet service plans (compared to the plans available in the USA), and for the CRTC to step out of the picture and stop meddling with what should be a privately run business sector. But, now I'm really dreaming.

If you take the angle that there will be less packaging, therefore production costs will come down and the publishers will offer the game at a lower price, then you may want to think twice about that. Consider iTunes, for example, the music they offer is pretty much on par with the retail price of a physical compact disc, if you multiply the price you pay per song by an average number of songs per album (12-14). Less packaging may not translate into a cheaper price for the consumer, but it certainly does translate into larger margins for the publisher.

With the advent of collector's editions becoming more popular, I was hoping that a trend towards better and more interesting packaging would be upon us. Think Baldur's Gate, Space Quest, or the Ultima Games. Beautiful works of art and a real pleasure to own.

The wait is over. In your hot little hands, you hold the biggest, baddest Doom ever - DOOM II: Hell on Earth! This time, the entire forces of the netherworld have overrun Earth. To save her, you must descend into the stygian depths of Hell itself!

Battle mightier, nastier, deadlier demons and monsters. Use more powerful weapons. Survive more mind-blowing explosions and more of the bloodiest, fiercest, most awesome blastfest ever!

The 3-D modeling and texture bit-mapping technologies push the envelope out to the max. The graphics, animation, sound effects and gameplay are so virtually realistic, they're unbelievable!

Play DOOM II solo, with two people over a modem, or with up to four players over a LAN (supporting IPX protocol). No matter which way you choose, get ready for adrenaline-pumping, action-packed excitement that's sure to give your heart a real workout.

It must be tough to keep reading - what with your hands trembling in shear anticipation. So we'll stop talking now to let you take this box to the counter.

DOOM II. It's time to get obsessed again.

As it exists today, computer virus defense is wide collection of software programs and support networks which are offered to companies and users for the sole purpose of protecting their data from loss, damage, or theft from a myriad of small computer programs called computer viruses. These programs must have the ability to replicate (either a copy of themselves or an enhanced version) and which often carry a payload. The means by which a computer virus can replicate are complicated and often involve details of the operating system. In addition to preventing virus outbreaks from occurring, anti-virus software is also used to help prevent service outages and ensure a general level of stability. In other words, they are selling security or at least one form of security, since security in general is a very large net which cannot be cast by only one program. As an aside note, please be aware of the tools you are using for anti-virus protection. With some research and a little education, it's often not necessary to purchase these programs in the first place.

I am currently reading Peter Szor's book entitled, The Art of Computer Virus Research and Defense (ISBN-10: 0321304543). I am almost finished the text and I have found the book to be incredibly informative; filled with illustrations and summaries for all sorts of computer virus deployment scenarios, technical information about individual strains, and historical pieces of information as to how the programs evolved and mistakes made by both researchers and virus writers.

Even though I have the skills and the opportunities to do so, I have never written a computer virus for the purposes of deployment, nor do I ever wish to do so, but I can tell you that writing an original computer virus is challenging work; writing a simple virus is easy. Isolating, debugging, and analyzing the virus is also interesting work, albeit somewhat more tedious. Both jobs require similar skill sets, detailed knowledge of and low level access to a specific system.

I used to posit that the best virus writers would be the people who have taken it upon themselves to write the anti-virus software. After all, the best way to ensure the success of a business built on computer virus defense is to construct viruses that can be easily and quickly disarmed by your software. Much to the disappointment of conspiracy theorists, this is probably not the case, since fellow researchers would easily link a pre-mature inoculation with a future virus outbreak if it happened too often to be mere coincidence. However, if your business was based on quick and successful virus resolutions, then timely outbreaks followed by timely cures would seem to solidify the business model. Personally, I think anti-virus researchers are kept busy enough with "naturally" occurring strains to necessitate a manual jump start of the industry. Although that could change as users and technology platforms become more advanced, although the more probably route is the disappearance of the anti-virus industry; we live in a messy world and there may be opportunities for those wanting to leave their mark, even in the face of futuristic technology gambits.

Computer virus writers are plagued, somewhat ironically, by numerous problems with deploying their masterpiece. A computer virus can be written generically so that it can spread to a wider variety of hosts, or it can be written for a specific environment, which can include requirements on the hardware or software being used. Dependencies on software libraries, operating system components, hardware drivers and even specific types of hard-disks are all liabilities and advantages for a virus. They are liabilities because dependencies limit the scope of infection so the virus spreads more slowly, but at the same time, they often enable the virus to replicate, since the virus may be using known vulnerabilities or opportunities within these pieces to deliver the payload or as as means to allow for it to spread.

Virus research, writing, and defense is a fascinating topic. Unfortunately, I find the pomposity, and to some degree the absurdity, in various branches of the industry to be laughable and a little scary at times. In case you haven't heard, the University of Calgary is offering a course on computer virus research. While I find this to be a refreshing take on education, my hopes are quickly dashed when I read the requirements and the Course Lab Layout (warning PDF monster). Do they think their students are secret agents working in a top secret laboratory? Of course they do, why else would there be security cameras installed in the room, and why do they restrict access to the course syllabus? Well, I've got news for the committee who approved the layout of the lab, and who probably approves the students who can attend the course: computer viruses are just pieces of software. That's right, they're just software. They don't have artificially intelligent brains, they can't get into your computer by the power lines, and they are quite a bit less complicated than your average word processor. This means that any programmer with the desire and a development environment can write a virus, trojan, or any other form of malware. They don't need to take your course and they don't need access to your Big Brother Lab.

The absurdity of protecting information which is already publicly available and has been for decades makes me want to laugh out loud and strangle someone at the same time. It's rather disturbing and I really don't like the idea of closing doors on knowledge, even if the attempt is futile. The University of Calgary's computer science department should be ashamed at perpetuating such ignorance within a learning institution, and I am truly disappointed how bureaucratic such systems have become.

Update 12-29-20008: To respond to a verbal conversation I had with a couple of people: I understand why the university placed the security restrictions in the program; they want to validate the program and make it appear legitimate to the community and their peers. That's fine, but at the same time, it must be acknowledged that the secret to mounting a successful defense against viral software and Internet based attacks is shared knowledge and open avenues for information. Understandably, this information will go both ways, but the virus writer will gain nothing they do not already possess (except the knowledge that we know what they are doing), while the general public may be a little more aware of the problem than they would be without this information.

Indeed, using viral kits and small customization programs can make viral programming easy for the layman or immature programmer, but we shouldn't be locking away information about these techniques or programming practices simply because the result is something undesirable or easy to dispense. There are real opportunities to learn and disseminate this knowledge today, and the bigger the audience, the larger the opportunities for successful anti-viral software and general consumer awareness which will combine to create the most effective vaccine of all: knowledge.

While scripting batch files, you can also make use of ANSI escape sequences to control the cursor, display coloured or blinking text, etc. In case your interested, DOS requires an ANSI driver in order to translate these escape sequences. These escape sequences are non-intuitive and look something like this:

ESC[=5;7h

Ahh. Isn't it cute? Many people have been discreetly killed for creating less offensive syntax than that. In addition to the regular set of ASCII characters which can be used in creative and artistic ways to produce a recognizable picture, using the set of extended ASCII characters provides an easy way to draw connected lines within the grid of displayable characters. When creating your picture keep in mind the screen size, since this is dependent on the video mode (some video modes can display more rows and columns).

TheDRAW was written by Ian E. Davis and was last released in October of 1993. It is a program which allows you to paint a picture or create an animation using these special characters and ANSI attributes. It's not like painting individual pixels, you are limited by the set of characters available. However, this hasn't stopped ASCII artists from creating fantastic content. The most stunning examples I found were on Bulletin Board Systems. They were often themed according to design of the on-line system. Using TheDRAW, these pictures could be exported as ANSI-compliant or ASCII text files, or as header files to be used in other programming languages. There are a number of small tools available for translating these files into other formats used by other languages.

TheDRAW package is bundled with a utility called TheGrab which can take an screen shot of a running program. It's not your typical screen shot utility which takes snap shots of any graphics screen. This program works only for text mode screens and will output a file in ANSI, ASCII, COM, or TheDRAW format files. Be wary of using this memory resident utility under DOSBox 0.72 as it will crash and force you to end your session.

Last but not least, TheDRAW package is bundled with a utility for creating your own fonts to be used in TheDRAW paint program. This is without a doubt one of my favourite features and makes creating screens a breeze. There are many fonts available in the wide, wide world so have fun.

All of these features are thuroughly explained in the documentation and in-program help. Many of my programs took on a more professional and fun look because of this drawing tool; although I think I went overboard in some cases. I still find it the best tool available for doing this sort of work in DOS, although I'm sure many of you may prefer other software such as AcidDRAW.

I'm trying to run with the concept of an open system (no case) which is essentially mounted to a peg board. The boards could slide into slots on a rack which would save on space because there would be only one rack. Or I could create a rack capable of suspending multiple motherboards, which would then be mounted inside a cabinet. The cabinet could have a table top for the monitor, or the monitor could be mounted on the back of the cabinet. The hard part will be find the right cabinet... obviously, I'm still mulling it over.