bc-programming.com

Lately, I’ve heard a lot of talk about “Registry Boosters” and “PC speeder upper’s” and fix-it programs. They make big claims, and it seems that a lot of their customers refuse to accept that they paid for something that was either a scam or completely useless.

I have decided to put some of these programs to the test. The idea is simple; under various conditions, run the program “scan”- probably watching the program with process monitor. Then ensure everything works properly.

The test I have decided on so far will use a VMWare Workstation Guest OS, namely, XP Pro.

For each program I wish to test, I will start with a CLEAN install of the XP SP3 OS.

First, I will run the program right away- right after the clean install. Then, after another clean install (I will probably make a clean install Image) I install a number of common applications; MS Office XP, Visual Studio, and a few freeware programs such as IMGBurn. Then I will run the “booster” again. Making sure to test each program afterwards.

Each run will be monitored with Process Monitor; I’ve found that some of these “Scam” programs hardly access the registry at all, and simply make a claims of bad entries. Obviously, these are complete scams. There are also programs that do very little but are purported to make the PC much faster, a claim that I aim to disprove based on the fact that it simply doesn’t make sense. IF it does make the PC faster it is not in the order reported and likely has a few trade-offs that either aren’t reported or simply aren’t known.

I am uncertain what programs I will test with this method; suggestions are welcome. It won’t be hard to develop a list, however, through a quick web search. Also, I aim to put the copy of System Mechanic andFix-it Utilities I have to work, too. See just how “comprehensive” these utilities really are.

When first encountering a x64 based system running windows, one of the first questions posed is often, “what is C:\program files (x86)?” The simple response is that it is the equivalent of Program files on 32-bit systems; that is, 32-bit program files are installed there. This is true; but this is far from the only difference between the two systems and their file systems.

There is, however, further redirection within both other folders as well as The registry.

For example, the “real” %systemroot%\system32 folder actually stores the x64 system files; the 32-bit files are stored in %systemroot%\syswow64. However, when a 32-bit application access this system32, Windows automatically redirects all requests to the syswow64 folder, so accessing, say, “C:\windows\system32\file.txt” is actually accessing C:\windows\syswow64\file.txt. This includes any file operation at all. creation, editing, etc. there are a few folders exempt from this redirection- that is, they are not redirected. these folders include %windir%\system32\catroot,windir%\system32\catroot2,%windir%\system32\driversstore (this folder is redirected on all pre-windows 7 systems),%windir%\system32\drivers\etc,%windir%\system32\logfiles,%windir%\system32\spool. There are a few other features, for example, running “C:\windows\regedit.exe” from a 32-bit program will in fact run the program from C:\windows\syswow64\regedit.exe.

An additional feature is that a 32-bit program can access the 64-bit folder, Vista adds a “sysnative” alias folder in the windows folder, by accessing C:\windows\sysnative instead of C:\windows\system32, one gains access to the real C:\windows\system32 folder rather then being redirected to C:\windows\syswow64. The caveat of this feature is that most programs have validations before they accept a filename; since sysnative is not an actual folder but rather an alias used by the redirector, many validations (including the standard Open/Save dialog) can fail, meaning that one cannot “force” the access to a specific file. the main purpose is for use by the application for various reasons, not so users can access files within the folder from 32-bit applications.

The registry posesses redirection as well; the HKEY_LOCAL_MACHINE hive on x64 systems contains a key called “Wow6432node”, when a 32-bit program accesses, for example, “HKEY_LOCAL_MACHINE\Software\company\app”, they are in fact accessing “HKEY_LOCAL_MACHINE\Wow6432node\company\app”- basically, it separates 32-bit machine-specific data from 64-bit data. The only caveat is that, unlike the file system redirections, registry accesses are “mirrored” across the two; for example, COM classes are stored in HKEY_LOCAL_MACHINE\software\classes. when either HKEY_LOCAL_MACHINE\software\classes or HKEY_LOCAL_MACHINE\wow6432node\classes are have keys within changed, the change is reflected to the other location.

Additionally, certain 32-bit compiled applications can be given special treatment; if the image file (exe,dll, ocx) has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, wow64 (the windows 32 on windows 64 emulation layer) gives it a 4GB user-mode address space, whereas with a 32-bit system it would be given a 2GB user mode address space. the flag is required, rather then being the default behaviour, because such large addresses may not have been expected when the program was written; therefore, by adding the compiler flag, you are telling windows “yes, I understand and am able to deal with the larger address space in my program”. It doesn’t actually do anything to the program itself, just changes how windows deals it memory.

another special-case is with regard to program installers for some older 32-bit programs. Many such programs used a stub 16-bit windows 3.1 program to determine the windows version, and then, launch the 32-bit installer if possible. Since 64-bit windows cannot run 16-bit applications, Microsoft decided to hack about a little fix; the followint 16-bit installer technologies have 64-bit equivalents that will be launched instead:

Microsoft Setup for Windows 1.2

Microsoft Setup for Windows 2.6

Microsoft Setup for Windows 3.0

Microsoft Setup for Windows 3.01

InstallShield 5.x

the list of such redirections can be found in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\NtVdm64, the 64-bit equivalents are found in Syswow64.

For the most part, these changes make using a 64-bit operating system nearly indistiguishable from using it’s 32-bit equivalent; windows itself bears the brunt of the change, and the application developers pick up a little of the tail-end of it.

In my previous entry, I discussed and provided code that would allow for the detection of Triple-Clicks on a window. By extending the provided architecture, it is relatively trivial to allow any number of consecutive clicks; for example, detecting pentuple clicks.

More »

Visual Basic 6; and, well- nearly any other relatively modern language; provides a way to detect mouse events. These usually include mouse down, mouse up, mouseclicks, and double clicks. Absent are any higher “N-clicks”; I speak, for the most part, of the triple click. More »

I have been using Visual Basic 6 for many years; I have come to the point where using it is effortless; nearly any problem I have I can design and program with Visual Basic 6.

However. Visual Basic six is over 10 years old. Mainstream support ended a few years ago, and after Vista Microsoft makes no promises that programs designed with Visual Basic 6 will work. Even creating programs that support the various UI features of XP could be a chore. With Vista, Not only does one need to include the proper manifest resource or file  to force their VB6 applications to link with the newer version of comctl32, but it is almost always necessary to include an additional set of directives in the manifest to make the program request administrator permissions. I have yet to determine why some of my less trivial programs crash before they even start when run with the same security as the user, but I imagine it’s directly related to COM components, their usage, and the permissions surrounding them.

Another area of concern is with the use of proper icons; Visual Basic complains when you try to use a icon with a alpha channel. However, through a few API techniques and some resource editor trickery, it’s possible to have your application use 32-bit icons both as the program file icon as well as the icon for your forms. Rather then repeat the material here, I will point you in the right direction if this type of this piques your interest. www.vbaccelerator.com- I cannot praise that site and it’s creator enough. While many of the projects and controls he has on-line I have personally attempted before finding the site (I had a somewhat working toolbar control and a control I called “menuctl” that allowed moving the main menu around as a toolbar), the sheer number of completed, documented, and well written controls on his site is simply mind-blowing. There is also a .NET section to his site as well, which brings me to my next point.

There are only a few reasons why a programmer would choose to use Visual Basic 6 for a new project today. The main reason is simply because we are stubborn, for the most part. The fact that .NET is better in many ways then VB6 does not sway us to use it. The fact is, we all feel “betrayed” in a way, but the shift to .NET. Millions of lines of code that were dutifully compatible through all 6 versions of Visual Basic 6 now break when loaded in VB.NET. But I believe, that the majority of VB6 programmers have simply been blinded to the number of problems Microsoft would have faced to continue using the same COM oriented framework that VB4 and higher have used.

COM,or, Component Object Model,(sometimes referred to as “Common Object Model” which is dead-wrong) is a Binary compatible method of providing interoperability between applications. COM was essentially designed to prevent what was known as “DLL hell”, since at that point in time DLLs provided their functionality through exposed functions, some versions not compatible with previous versions, meaning it might be necessary to, for example, have 5 different versions of MFC41.dll on ones PC. The idea was, each version of a COM component would be Binary compatible with the previous version, which means, for example, that a program designed for version 1 of “foocomponent” could still run and use version 4, but without the new features of version 4. This functionality was implemented by the creation of Interfaces. Each version of a component would add a new interface- for example, IFooComponent, IFooComponent2,IFooComponent3, etc, and client applications who want to use FooComponent would use the interface appropriate to the version they wish to use.

There was, however, one problem. Most of the maintenance between versions was left to the programmer of the component- they had to create the new interface, make sure previous interfaces worked, that old clients could still instantiate their objects, etc. Basically, it made the critical mistake of putting the user of the technology (in this case, the programmer) in a critical position and with a number of responsibilities to get things to work properly.

Microsoft, of all companies, should know that putting the programmer in a position of such responsibility is prone to failure; hell, many of them can’t even be bothered to follow standard API documentation; for example, actually reading the documentation; this resulted in hundreds of man-hours of programmer time being consumed by the creation of “compatibility shims” to let these programs work. (otherwise, installing a new windows OS would break these programs; they worked before, so as far as the user sees the new Operating System is to blame). Anyway- this failed miserably. Programmers would sometimes simply change their interfaces rather then implement new and old ones, meaning, like with the DLLs of before, new DLL versions were incompatible with the old ones.

It was clear that COM, or, at least, COM as it was presently designed, was far to dependent on the programmer to “do the right thing” then was reasonable. So, Microsoft, at some point, decided they needed a new object framework architecture.

VB6, as a COM-based language, would have required extensive changes to support this new architecture. the prospect of such a huge revision probably made them take a second glance at the language itself, and the cruft it still has from previous iterations of the basic language. aside from retaining such archaic constructs as the “GoSub…Return”, VB6 also “failed” in a sense on a number of other areas. Error-Handling, for example, was still done using “On Error” statements, which redirected flow to another segment of code. It was up to that block of code to evaluated the error, using the “Err” object (In VB1-3 there was only Err which was the error number and Error$, which was the description), and then either resuming that same statement that caused the error (Resume) skipping that line, and continuing with the next, (Resume Next) or even raising the error again, causing the error to cascade up through the call stack.

This Error architecture had a critical flaw- by using this form of error handling, flow could change to the error block for any reason, at any time. This meant that if the procedure dealt with resources, such as file handles or memory blocks, it would have to keep track of what needs to be undone so that the error code could also double as partial cleanup code. Another critical flaw was simply that it was ugly; it looked and functioned nothing like the Try…Catch statements in many other languages. Also, it could become impossible to trace exactly where an error occured when errors cascaded; and error handler might be forced to handle an error from three levels down in the call-stack, so even if it understood the error in the context of the procedure, the context that the original error occured in and exactly what it means was lost.

My main language is Visual Basic 6, but I am not so blind as to reject VB.NET, or .NET as a whole, merely because it essentially replaced VB6. The truth is- we, as VB programmers, have made a large number of requests to the VB developers. VB .NET answered and fixed a huge number of those requests, and yet it is still shunned; it is clear to me that it is not merely the loss of backwards compatibility that causes such antagonism with VB6 programmers, but also the human element of resistance to change.

With previous versions of Visual Basic, one could migrate all their code to the new version with little or no difficulty.

This, however, had a price- since the new version made few, if any, requirements for conversion, old antique code would often be upgraded and imported into the new environment. Since backwards compatibility was the rule, old elements such as line numbers gotos, and gosubs remained in the language. Antiquated concepts such as type declaration characters remained in the language. Such visages of a forgotten era had no place in a modern language.

All the above being said, VB6 is still a language capable of creating modern applications; however it is important for the programmers who still use it to realize that they aren’t using it because it is superior or because .NET or any other language “sucks” by comparison, but rather as a result of their own stubborness and unwillingness to learn new programming concepts.

A anecdote, if I may, can be found in my introduction to the use of “class modules” within Visual Basic. at first, I had no idea what they were- I simply shied away from them, and stuck to Forms and code modules. I used all sorts of excuses- Class modules are slower, they bloat the code, etc. All of which were, almost universally fabricated or found on the web written by grade 8 students who barely understood the meaning of the word “class” in the context of programming or objects.

After, however, creating ActiveX Controls using the “userControl” Object, I realized the similarities, and the possibilities that could arise. My first conversion attempt was on my Current “flagship” program, the game I called “Poing”. At that time, the entire game was designed using User defined types as functions that operated on them. I understood the concept of encapsulation and managed to convert the entire architecture to a Class based object heirarchy- and it worked. My concepts still contained flaws, such as including critical game logic in down-level objects, but for the most part my udnerstanding was sound.

As my understanding of the concepts involved improved, so too did my antagonism disappear. It was clear to me that the fact that I didn’t understand classes at the time lent itself to a distaste for them- basically, the old adage that one is “afraid” of what one doesn’t understand was at least partly true. This, I feel, is at the very core of the antagonism against .NET. the main detractors of the framework are often people that neither understand the concepts involved nor do they realize how said concepts add increased possiblities and easier maintenance.

Even so- .NET has, in my opinion, one critical flaw. the IDE is slow. even on my quad core machine I see huge delays as intellisense is populated or any number of other operations. Perhaps it is a result of a mere 7200RPM hard drive? I don’t know. perhaps I need more then my current 8GB of RAM? who knows. I think, that using a 10 year old program and expecting and recieving quick responses from it have perhaps jaded me in terms of what the extra features of the new IDE actually cost in terms of performance; the delays feel like minutes, but in general it is only a few seconds. On the other hand- a few seconds is a lot longer then necessary to make one lose their train of thought. At the same time, this same argument was used against the initial usage of Intellisense; and there is no denying that although the initial display of a number of said intellisense lists can take some time, subsequent usage is nearly instantaneous, and the lists provide far more in terms of function information then the VB6 OR C++ 6 IDE could provide; this, in addition to the ease of use of assemblies between multiple .NET languages is not something that should be passed up because of an ego-centric desire to prevent change. The IT industry changes constantly. The fact that VB6 is now a “past item” should not dissuade us from moving forward because of a snobbish desire or fictitious affection for the corridor of our programming efforts for many years; the complaints about VB6 when it was introduced were very vocal. This is, no different with VB.NET, however the very complaints made about VB6 that have been remedied with .NET are now being passed off as inconsequential (since in many cases programmers have devised ways of working around limitations or even forcing behaviour that VB6 was not designed for, such as, for example the creation of Command-line programs.

The mistake Microsoft made was not the creation of .NET, but rather the belief that any sane person would move to a new platform if it was superior. They forgot the take account of the psychological factors involved.

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?

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.

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?