Only in your first couple projects. By your third DOS project, you probably would have built up your own UI library.

But the big thing that DOS did better than Windows back in the early to mid 1990s was using all the features of the VGA. DOS applications could run in low definition (Mode 13h, Mode Y, and Mode X, with resolution of 320x200 to 320x240). This allowed updating the whole screen before Windows finished updating half of a 640x480 standard-definition screen. DOS could also use hardware scrolling to pan over a large virtual area without having to do the bit shifting bullcrap that plagued standard VGA mode back then. Both of these became less relevant, however, as CPU speeds and bus speeds rose and especially as graphics cards began to incorporate 3D rasterizers.

The problem here is that once "a program or a script" reaches some level of generality, configuring it becomes almost as hard as just creating the links yourself. Hence the reference to application programming interfaces (APIs) and domain-specific languages (DSLs) in the article.

And watch suppliers decline to do business with your startup company because they don't like your lack of experience or they don't like where its office is located. For example, some makers of computing platforms lock down who's allowed to have a devkit, and they have a history of reserving devkits for the most experienced companies with traditional offices.

In some North American markets, especially those served by CDMA2000 carriers, it's either buy your phone from the carrier or get 0 bars. These carriers tend not to sell any devices that allow viewing web pages and loading user-made apps without Apple's walled garden or Google's alleged spyware. Is your "simple fix" doing without?

The difference between iOS and Android in this respect was that during the Android 1.x days, manufacturers and carriers sold Android phones in countries where Google hadn't yet opened Google Checkout. This meant that in order to get an app into Android Market in any of those countries, the developer had to make the app available without charge. The common way to do that involved selling advertising space. This set price expectations on Android lower than they are on iOS, where Apple has made sure to open the iTunes Store in a country before selling iPod, iPhone, or iPad products there.

It's hard to find apps whose manifest doesn't request the INTERNET permission. Is there some sort of control within Google Play Store that would let the user filter apps by permissions?

Which would require first buying the app, after which point my ISP already has my money for the bandwidth used for downloading it, and Google already has my money for buying it.

If you archive a 4K video, you need to scale it down anyway before it'll play efficiently on a handheld device, no matter what codecs that device accepts. Besides, if you produced video, you may want to archive the source footage in its original format and a non-destructive edit decision list.

But does it have anticircumvention legislation (DMCA, EUCD, etc.)? Besides, the process of finding a country with acceptable living conditions and visa requirements, finding an employer to sponsor a work visa, and finally moving one's family isn't practical for everyone, I understand.

To an extent it depends on what your video is of. I'd assume that users of Internet Explorer 8 at home have far less disposable income than users of Firefox, Chrome, Safari, or new IE. Will they be paying for your video or for the product that your video advertises?

It doesn't include video game footage or anything else that's edited because as I understand it, the video editing software needs to have its own licensed encoder.

Ever wondered what the "89" in GIF89a stands for? It stands for 1989. Unlike copyrights, patents encumber all implementations of a method, even those resulting from independent reinvention. To make up for this, patents last only 20 years, not 95 like a copyright.

Make it two decades and we'll talk.

Not so fast though. When I made a similar point, people mentioned that video providers will continue because they have the choice of decoding H.265 in battery-gulping software or H.264 in battery-sipping hardware.

It sounds like you want all scripts associated with an HTML document to come from the same domain as the document. Say a publisher (the operator of a web site on which an advertisement appears) ran its own ad server on its own domain (such as "ptb.example.com"). Would you be fine with that? Say a publisher established a CNAME for an ad network's server (such as "ptbgoog.example.com") and served ads from there. Would you be fine with that?

Google Play Store's permission screen doesn't tell you how much data an app can transfer in any given time.

If you are archiving a video that you produced, what's the big advantage of H.264 over VP8? VP8 is rate-distortion comparable to H.264 baseline, and VP8 is free today. An archival copy needs to be read by software, not necessarily read by specialized hardware in a battery-constrained device.

If you are archiving a video that someone else produced, most streaming video providers have a policy of implementing technical measures to prevent just that, backed by national anticircumvention legislation.

Unless you have to watch a video in order to gain access to pay your bill. Or do you prefer to pay the monthly surcharge for using paper billing and paper checks?