BASeCamp Programming Blog

Ever since I first had a mars bar, I was curious what the strange brownish stuff was that the caramel was sitting atop. It was good, but what was it? And why don’t they make a candy bar that is just that stuff covered with chocolate?

Anyway, recently, I decided to try a “three musketeers” bar, which I had never had. I had no clue what was inside. To my amazement, I discovered it was the theoretical bar I was pondering about before- composed solely of the strange nougat fluff stuff that is found in a mars bar. Why did nobody tell me? Why was I left in the dark?

I still haven’t figured out exactly what it is. My original hypothesis told me it was nougat of some form, but nougat is generally pretty chewy. I have determined it is some form of “whipped fondant” or something. The experience raises the question though- what other mysterious confections have I pondered about that actually exist?

UPDATE/EDIT June 20th 2012

For some reason, this is the most visited entry on my blog. That’s really all. I have no idea why it is, but it’s been at the top for views, being the first thing over 25% of visitors see when visiting my blog. This kind of sucks since it is a pretty crap post. I’m tempted to delete it but instead I decided to flesh it out a bit.

5,812 total views, 72 views today

Since we now have 64-bit desktop machines at affordable prices, So too have 64-bit operating systems made the migration from something that would be server-oriented to a OS aimed more at the consumer.

However, as with the migration from 16-bit to 32-bit, this new “revolution” towards 64-bit is attracting a number of detractors. common arguments range from “lack of manufacturer support” to “not enough 64-bit applications”.

First, manufacturer support is excellent. Drivers, being “closer to the hardware” (that is, running in Ring 0) are more sensitive to changes in the bit width of the processor architecture and pointers. While it is true that your unlikely to get that old serial Dot Matrix Printer working perfectly, there are a number of generic drivers included with windows that can often suite the task quite well. (for example, the Generic/Text Only printer driver). Lack of support is more or less the problem with companies with released products that they deem “legacy” hardware. For example, the aforementioned Dot matrix Printer.

The second issue hits closer to home. You see, it assumes that there are vast differences hat require many man-hours of work restructuring or rewriting code. However, this is only the case if the code is poorly written to begin with. Properly written code following the SDK documentation and proper coding practices (you have to code for forward compatibility, not assume newer operating systems will be built with backward compatibility in mind) can be switched to the x64 architecture by simply flipping a compiler flag.

So what is this about? The problem is, the software firms developing these applications that are having difficulty and/or need to dedicate extra work to releasing a 64-bit version of their programs either did not learn their lesson from the 16-bit to 32-bit switch or weren’t around at the time. The main question then, is how exactly these  types of bad coding practices occur.

What exactly does it mean when an application is “16-bit” or “32-bit” or x bits? How is it that an application can even have a concept, or even have it’s execution directly affected, by the particulars of the processor it runs on? Desktop applications have been compiled to Machine code, or at least have had a machine code interpreter of some form of “bytecode” for ages. This machine code, by it’s very nature, is dependent on the particulars of the PC it runs on. The “bit-ness” of a application really only has a single effect on most applications, but it is a far-reaching one. It changes the size of a pointer- a memory address. Application programs access memory to do their work. They allocate, deallocate, reallocate, copy to, copy from, etc memory all the time to perform their operations. So it’s not surprising that something so integral to their operations might affect them.

However- speaking of the windows environment, in particular- the Windows SDK itself has been designed to preclude any such source-level problems- such as bit-width issues. take the ubiquitous “handle” value in the SDK. Window Handles; Device Context handles, File handles, etc. Handles are used everywhere, and, internally, a “handle” is really just a pointer to some chunk of kernel-owned memory, likely containing some persistent information about said object, but nobody really knows- nobody needs to know. In the windows 3.1 SDK, the HANDLE type is typedeffed as such:

 typedef HANDLE unsigned short; 

Or something to that effect, effectively making a “HANDLE” a 16-bit Integer value. HANDLE was typedeffed to HWND, HDC, and all other handle types, as well. The idea was, that the programmer would simply use HANDLE types- for example:

 HWND getApplicationWindow(){
       return FindWindow("AppClass\0","My Application\0");
} 

It’s been a while since I wrote C or say the header for FindWindow, but the idea there is to return the window handle of a certain window. Notable is the fact that the return value of the function is a HWND.

The problem? Clever programmers this typedeffing was getting in the way- so they would declare their return types as short. When 32-bit windows rolled around and the updated SDK changed HANDLE to be a 32-bit int, these programs broke, and many vendors had to take many months updating their applications to work properly. (although, they had to change stuff a tad anyway, since there were also common controls and other goodies that often fit the bill or replaced- or even improved- upon the various implementations of similar controls in different applications and by different vendors.).

This very same hard lesson is being learned once again by another generation of young programmers who think saving a cycle or two during compilation was worth using a primitive type for these pointers.

Finally, 64-bit Systems support >4GB of RAM, something that has been common in servers for many years, and is just now becoming available to consumers. As our systems outgrow the 32-bit Operating Systems we insist on remaining attached to, there really has to be a point where we ask ourselves what it is that we are actually hanging on to. Do we really believe that “32-bit applications have trouble in 64-bit windows”? Did we ever experience it? Personally, I haven’t had a single problem with a game, or application ,32-bit or 64-bit, or a hardware device not working or not having a driver. Sure- For some of my more esoteric devices I wanted to use, I had to do some googling to find a working driver, and I doubt there are x64 Vista drivers for, say, my 16-bit ISA IBM token ring card.

Another common “grievance” for people commited to running 32-bit operating systems, even when their system is capable of running a 64-bit OS (this, I might add, is who I mean- those running a 32-bit Operating System on a 32-bit system are fine- I am not saying that 64-bit, as a whole, is something that should be preferred, but rather that using a 32-bit operating System on a 64-bit able PC is like running windows 3.1 on a Pentium 4.) Is that there aren’t a lot of 64-bit applications. This irrelevant, really. it would obviously be important if the 64-bit operating system could only run 64-bit applications, but as it is, all 64-bit versions of windows, at least, can run 32-bit windows applications without issue.

To revisit decisions between a 32-bit and 64-bit System, as opposed ot merely an operating System- 64-bit should be a no brainer, especially at today’s price differences. a 64-bit processor has twice the bandwidth of a 32-bit processor. The fact that people overlook this fact and claim it’s “over-hyped” need to relearn basic arithmetic. Behind their arguments  of incompatible programs, hardware, and other equally fallacious claims is something that we are all familar with. Somebody scared of change.

580 total views, no views today

When entering the domain of programming, one finds a plethora of programming languages to choose from; and there are more being introduced nearly every day. Each language was designed for a purpose. From Assembly language, designed simply as a way to write machine code easier, to C, designed to be as “close to the machine” as possible without actually becoming a low-level language, and Perl, designed for text processing.

The interesting thing? They don’t have to be used as designed. Perl, while created by Larry Wall to make text processing of reports easier, has been applied in all sorts of problem domains effectively. Visual Basic can be used to write STDCall DLLs. Scripting languages, once relegated to creating silly animations to annoy users visiting web pages, has found use both on the desktop as well as server side web processing.

As the Information Technology industry has aged so too have the techniques used for programming. new techniques are tried all the time. Previously, the widely held winning formula was called “Structured programming” because, rather then using Goto’s or conditional jumps, the language itself contained constructed for “structuring” code, a method that allows the code to be more readable and organized. It also embraced a top-down approach, whereby the “function” is created before the routine that requires it. Original “pioneers” for this strategem are numerous, but the recognized “original breeds” are  Pascal and C. Pascal was created as a teaching tool. by enforcing a number of things widely held asgood programming practice as part of the language, it “conditioned” new programmers to keep these habits when they moved to other languages. As Pascal evolved, however, it was made more useful, and more applicable to the creation of real applications. C, on the other hand, was designed to allow programmers easy access to a wide variety of functions, both of the language as well as the “bare metal”. This “bare metal” approach was facilitated with “naked” functions as well as inline assembly.

The “Structured Programming” concept dominated the academic circles, and was implemented as a standard by programming firms the world over. However- there was a pattern to how it was used, and this pattern, once recognized, was used to develop the “next leap”.

Program source code that was “structured” had it’s many components separated into various modules, and procedures. Each module would often hold the structure definitions and the procedures to handle them. For example, a program designed to graph functions might have a module, perhaps, modFunctions, depending on the naming convention. This module would define the “structure”- or in memory representation – of the various properties of a function- the expression, range, etc. The routines in the module would be used to manipulate draw, set, and retrieve the various items stored in the structure.

Eventually, this was migrated into the structure itself- that is, a structure might be defined to hold both the data relevant to the function as well as pointers to routines that manipulated it. The common convention was that the first parameter to these routines would be a pointer to the structure being acted on.

This type of programming was first implemented in C, and it worked great. essentially, it combined the concepts of Functions, and the data they manipulated, and created a single entity- the resulting structure. Oftentime the only routine required was a function that returned a pointer to the structure, after initializing the various function pointers. this because known as a constructor.

The problem with this technique was simply that there was a lot of work involved with using this technique- initializing pointers and other “bookkeeping” type tasks. the concept, however, was solid. Languages sprung up that implemented this technique internally, and exposed only those parts of the “object” as it became known, that needed to be coded or used. The concept spread like wildfire. Languages that once conformed to the “structured” paradigm were adapted and given object-based features. Pascal variants known as “Object Pascal” which more fully implemented the loosely object-like syntax of Pascal itself, were created. C was extended into C++, implementing nearly all of the Object Oriented concepts, such as inheritance and interfaces, and so forth. BASIC, in the form of Visual Basic, got Object Based, and later, with VB4, loosely object oriented. Entire languages sprung up on the concept that a “purely” object-oriented language would be the best choice. An early language of this form- or more precisely, the first more popular language of this form, was Java.

With Java, everything was an object. a simple console application was comprised of at least one object. at this point, the code that created the objects, – the very “template” from which they were instantiated, were known as “classes”. it was not until a “class” was instantiated that it became an object.

While Java, with it’s pure Object Oriented approach, created clean code as opposed to a structured language, or half-object based language, it also had shortfalls. While Object Oriented Programming was a excellent concept- it couldn’t always be used to apply to everything, and oftentimes a short quick little program was all that was needed. Java was however well suited to internet applications, since it was also a byte-code based interpreted language.

Now that the Object Oriented approach has matured and entire frameworks have been created based on the concept, such as .NET, one cannot help but wonder wether the idea is to make it easier for the programmer or the user. Just because a language makes it easier to program, or a certain conceptual method of creating said program makes it trivial to do something, doesn’t mean that the user’s experience with the application is any better. What if a user requests a feature not implemented by the run-time? Sure, there are “native” method calls in almost all such language, but is this not, in some sense, an admittance of defeat? that the Object Oriented approach is not flawless? Or, perhaps it is less controversial- maybe it is simply a lesser admittance of failure on the part of the Object Oriented design set forth by the creator of the framework.  But the fact remains- the framework does not make implementing the feature easier. Is this not what the framework is for, however?

So the ultimate question is- are we any better, now, with class framework and libraries all around us, then we were when we had basic Input/output and generic function libraries, and were left to fend for ourselves with all sorts of mundane programming tasks that we now take for granted?

123 total views, no views today

First post here.

For the record this will NOT necessarily override those entries I put on my blog at glitchPC.com, but rather be a location for more detailed code-oriented posts, as well as looser posts not necessarily about PCs at all

164 total views, no views today