What µP-8085 taught me
** The following post describes an ugly-hack.
** Continue reading at your own risk.
** Kids, please Do NOT try this at home.
( unless U want to end up like me… )
2005-09 was a very enlightening phase of my life. I was pursuing my B.E in Electronics & Communication. I learned a lot of “stuff”
(and not just academic “stuff”; here is what SKSVMA taught me 😉 ).
Academically speaking, the first 2 semesters were a repetition of what i had learned in 11th & 12th in school. So i was able to quickly parse through the textbooks and finish my academic “stuff” in no time at time. Hence, I was either killing terrorists in IGI:2 or doing jobs in GTA or scoring goals from the half-line in FIFA. Once in a while, when got bored of that, i started to roam around looking for interesting “stuff” to do.
Most of the time i would end-up in the library (my adventures in the Library). But, on the rare occasions when i managed to overcome the temptation of going to the library to read the latest issue of DIGIT, i DID meet other people and learn “stuff”.
On one such occasion, i wandered off to the “TWO-MAN” room (guys in SKSVMA-Hostel ought to remember this room :-)). Legend has it, this room was constructed and occupied for 4 consecutive years by he-who-will-not be-named-unless-he-wants-to-be (here onwards HWWNBNUHWTB).
Now HWWNBNUHWTB was a senior of mine. He was in the same stream as me (i.e. E&C). This meant- while i was roaming around for lack of things to do in the 1st year of B.E, he was in 2nd year B.E tackling life’s major problems.
One such problem HWWNBNUHWTB faced was coding the 8085-microprocessor. It was not a problem per-se, rather there was no 8085-kit to practice code upon. Students weren’t allowed to “borrow” the kits OR carry them outside the lab for personal use. (Quite sensible considering what we did with them. hee hee 🙂 )
Now with the externals fast approaching, HWWNBNUHWTB was desperate to try out a piece of code he had written for the 8085. So he had pleaded the college-librarian to lend him a floppy that shipped with R.S.Gaonkar’s book on 8085 (our prescribed Textbook). Then he had rushed back to his lair, the legendary “TWO-MAN” room. He had just about popped in the floppy and copied the emulator onto his PC, and was trying to launch the emulator to try out his hand-coded assembly program for some sort of sorting routine (i think). But, to his dismay the emulator keep asking for a password/serial-key at the splash-screen. Having no access to the internet in the hostel then, he couldn’t register the copy online and retrieve the password to continue. ( The hostel was 2 kms outside the city outskirts. It still is, but now it has a 2MBps dedicated OFC line apart from the V-Sat access in the college.)
At this point i happened to cheerfully pop-in and asked him the cause of the miserable look on his face. Once i realised his problem, i decided to try out my wits against the program. The GUI looked clunky enough to be from the pre-XP era. So, i ran back to room and fetched a copy of ResHacker. (secret of my lean physique in college. I was extremely impatient and so used to run everywhere 🙂 )
Resource HackerTM is a freeware utility to view, modify, rename, add, delete and extract resources in 32bit Windows executables and resource files (*.res). It incorporates an internal resource script compiler and decompiler.
Once i opened-up the 8085-emulator inside ResHacker, i found a lot of rubbish in terms of images/icons stuffed in it. But what i was looking for was some way to access the main window that would be launched after the password was entered. ResHacker did show a list of windows, but it did not allow me to view the internal code in any form.
As i was playing around with ResHacker, (and HWWNBNUHWTB, growing tense with every passing minute) i happened to notice that the splash-screen had its property
MDIchild = False
MDI stands for Multiple-Document- Interface; its an alternative interface compared to SDI ( Single Document Interface). In simple-terms apps designed using SDI are like notepad. With each instance of the app supporting a single document. opening multiple files using notepad opens multiple instances of notepad. On the other hand. apps designed using MDI are like wordpad with multiple documents being opened in the same instance of the app.
Being familiar with VB (Visual Basic) a plan started taking shape in my mind.
I knew from experience that properties were not referenced unless their values were different from the default-value for that property. This was done to reduce executable size, especially the initialisation code. Whenever a window was to be shown, the runtime created a window with all the properties initialised to their default values. The properties that were different from the default were then re-initialised one by one. The line MDIchild = False meant that once the splash-screen window was initialised by the runtime, and since by the default value of MDIchild property is true, it was being re-initialised to FALSE (as required by the program).
The mention of MDIchild property implied the existence of a MDIparent window in the emulator app. Logically this MDIparent window would be the “MAIN” window.
If we were somehow able to launch this MAIN MDIparent window then we might be able to access the emulator after all.
My first thought was to somehow get a handle to the parent window. so that i could call:
But, even if i did get the handle to the parent window, i could NOT add any procedural code using ResHacker. In other words, there was no place where i could add my parentWnd.Show() line.
And then it hit me like a flash of lightning. The answer was right in front of my eyes. It was the line that had got me started in the first pace.
All I had to do was modify the line
MDIchild = False
MDIchild = True
I quickly hit compile and saved the executable and ran it again. This time the splash screen did pop-up and ask for the password. But seconds later the main window popped-up!!
Now to try out one’s code, all one needed to do was drag the splash-screen aside and start coding in the emulator in the main-window.
Suddenly, HWWNBNUHWTB, who had all but given up hope, screamed with joy and hugged me and thanked me and went on to try his sort-routine. (Which, by the way, ran fine without any errors; which is amazing in its own regard. And i think he went on to score the highest marks in µP-8085 in his class that year; he was in the top3 for sure).
How it worked?…
The simplicity of this hack was due to the design-hierarchy imposed on the child-parent windows. According to design whenever any window’s show method was invoked, i.e. a window drawn on-screen, its parent window’s show method was automatically invoked. This was done to prevent any orphan child windows.
In the above case, the splash-screen was not a child of the main window. But by defining it as the child of the main window we overrode the default flow of the program and forced an auto-load of the main-window.
And HWWNBNUHWTB got to test his program!!
And that, in-a-nutshell, is what µP-8085 taught me
NOTE: Dear Prof. Gaonkar, if U are reading this, then let me inform you that no copies of the program were ever made by me (or HWWNBNUHWTB, to the best of my knowledge). I have liked your book a lot. U may be delighted to know that It was my FIRST microprocessor book. Thank You for sharing your knowledge with the world.