Today is a good day to code

Windows Vista SuperFetch

Posted: December 31st, 1969 | Author: | Filed under: Apple, Microsoft, Uncategorized | Tags: , | No Comments »

Windows Vista SuperFetch

Picture of Irv Owens Web DeveloperMost PC users are plagued more and more by chronic slowdowns the older their PC gets. Some of this, probably most of this is due to spyware, but a vast majority of this is caused by software loading into the system tray. The tray is an area in which a program can run without having to have an interface, or appear in the taskbar. This was a great idea with the introduction of Windows 95, but in the era of many computer users running greater than 1 GB of RAM it seems un-necessary, or at least that it should be redesigned in Vista.

Microsoft is attempting to remedy the problem of slowness as well as acknowledge the larger amounts of RAM in currently shipping systems by building a technology called SuperFetch. Which is a fancy caching program designed to notice which software you use most frequently, and load that into memory at start-up. This can improve the percieved performance benefit to some users, but probably would end up being a technology that would get in the way of most power users. It would in a way take users back to the heady days of Windows 3.11 when we could choose how much system memory was to be dedicated to the applications, and how much was to be reserved for hard drive cache. This system would behave in much the same way, but instead of the user being in control, the system would adjust automatically.

In attemping to understand why the system tray is strange, and probably should be either redesigned or removed, it is a good idea to look at how Apple as well as Microsoft handle GUI-less applications. In Windows developers have the ability to create full applications that run in the background without disrupting the user, or appearing on their display. These programs are known as services. Probably the most widely used service is the IIS service. IIS, if you don't know already, is Microsoft's web server product. It is similar to Apache, except it has the ability to process scripts built in to the server. Whereas with Apache it is necessary to include modules for this functionality. As a result Apache is much more flexible, which could change if Microsoft is truly to build PHP support into IIS. But I digress. Some applications such as Apache for windows run as a service, and also include a system tray icon for management. In Mac OS X applications without a GUI typically either run without any notification to the user, or place a small icon in the upper right of the screen, such porgrams are fairly rare, since most applications on the Macintosh load themselves into memory at their first use and remain there. Since it is quite unnecessary to turn the Macintosh off, or to reboot most of the time, your programs always launch insanely quickly. It would be best for Microsoft to implement a similar type of system. This would minimize the overhead necessary for keeping frequently used programs in memory, and would be vastly less complex.

Another potential solution could be to automatically dump programs from the system tray if they aren't being actively manipulated by the user, or performing some operation on the system. This would do two things beneficial to the system. First, it would free system memory, handles, and other resources for use with software that is actually doing something. Second, it would discourage developers from using the system tray as a place to put their icons. To supplement this model, Microsoft should encourage developers to write services for Windows as opposed to tray software. The way it could work is that the first time this happened, the system would notify the user that it was closing the applications and ask them if they wanted to be notified in the future. That way the user would remain in control. On systems with less than 512 MB of RAM this simple system would pay back sometimes enormous benefits, reducing the idle footprint of the OS from around 400 MB on some systems back to a managable 256 MB. Microsoft is over-engineering this one, they should review the K.I.S.S. software development methodology.

The Future of Scripting

Posted: December 31st, 1969 | Author: | Filed under: ColdFusion, Companies, Microsoft, Programming, Sun Microsystems, Uncategorized | Tags: , , , | 1 Comment »

The Future of Scripting

Picture of Irv Owens Web DeveloperInitially I wanted to stay away from scripting languages as a developer due to the fact that they weren't really programming languages at all. For some time I was reluctant to even call myself a programmer until I built my first Java desktop application. In CNET's open source blog today, they ask the question has scripting peaked?

Scripting hasn't peaked out yet. The reason is clear. Building a web site with C++ or Java is like driving an armored tank to your mailbox. It is that ridiculous. The funny thing is that even Microsoft realizes this, giving their developers two languages to choose from when developing web applications. There are many reasons for enterprises to choose C# over Visual Basic when building a web application, especially if they already have desktop and client-server applications built using the technology. It would be possible to completely reuse many of the methods used in the desktop application for the web application. The frameworks built into J2EE as well as C# allow for robust development making it less likely that a developer will lose control of their code. Still, using these technologies and frameworks where a scripting language and a light framework would do adds un-necessary overhead to a project and can push deadlines out unreasonably.

Here's what I see. PHP is a fantastic scripting language that has no real back end and therefore is suitable for light to moderate customer facing websites and some intranet applications. Use of PHP in this regard will only continue to grow. I think some of the 25% decline in worldwide use is a reactive measure to PHP's early security vulnerability. PHP is losing ground quickly to and VB scripting as Microsoft's Server 2003 is more widely adopted. Personally I think that LAMP is superior for many tasks, but is almost ubiquitous now, hosting and maintenance are cheap. I'll continue to use PHP for light jobs, but at the same time I realize that this is just a preference and performance-wise is better. Talking about Java… Sun needs to buy ColdFusion from Macromedia / Adobe. It should be THE Java application server. There is no cleaner and easier scripting language, and it has nearly unlimited flexibility and is design-pattern friendly. Why this move hasn't occured yet is beyond me. It would have made sense for Macromedia to sell it, but I think the issue is that Sun has many proud engineers who love to over develop products. The thought of supporting something as business friendly as ColdFusion probably makes them sick. The business case for this is probably that Macromedia probably sees the big picture and that there are big bucks in ColdFusion, especially now that enterprises are seeing it as a way to get around JSP's notoriously long development cycles.

I see scripting as having a bright future, and I'll tend to side with Zend's guys as saying that regardless of how the Evans study got its numbers, PHP is increasing in use not decreasing. I'm not sure if it is true, but if the next version of IIS is going to have PHP support built-in, I'll be seriously considering going with a Microsoft server in the near future and running it alongside ColdFusion. I like PHP, but I just like ColdFusion better. – Scripting's demise