Firecode Progress Log
For Firecode v9.0.2 All Builds to 1499
(C)2009 Gabriel Sharp, Revision C
Abstract: Tracks day-to-day
progress of the Firecode project and all projects that support it. It is
kind of like a code writing journal in a sense, which most of my life revolves
around it. This progress log will be updated daily when possible, and will help
me and anyone else participating, track and finish daily tasks and solve daily
problems with the project. Please contact me for more info or for the original
firecode PROGRESS.LOG that this document was derived from,
Attn: Reader - This is the
offline portion of the project, if you are reading this then most of it is out
of date by far now, make sure you read the actual postings of the blog for more
up to date information.
Revision C - Published to
coder's nightmare blog
Revision B - Ported all code from .NET CLR to native
Revision A - (for v9.0.1) ported code from VB6 to C# NET (C# 3.0 standard) ** no
longer valid **
Note, Some aspects of this
text are now copyrighted (see COPYRIGHT.TXT)
Introduction
Firecode History
Firecode was a fast, console (text mode) based application which was coded
entirely in TASM (assembler) in 1997. It gained 200-400% faster screen write
speeds over typical COMMAND.COM and boasted a 100% customizable interface (every
last string in firecode could be changed by the user, color, etc).
When the windows revolution came with Windows 95, firecode ran fine but lost
something
when things shifted toward NT, once DOS stopped running windows and windows
started running
'Virtual Consoles', it seemed we needed something more. Keyboard fanatics who
didn't like
endless mousing around to do file and folder tasks or run apps who themselves
were keyboard
driven got frustrated by working from a non-windows client like cmd.exe.
Firecode moved
to windows, first in visual basic given that I knew nothing of Win32 and only
native assembler
at the time. VB6 was the core port for a long time up to version 7.0 which would
come to
doom firecode to death. In Fall of 1999, the VB6 version stopped working due to
overwhelming size
of the executable, and the inability to separate the code into anything more
than simple classes.
The project was shelved. In 2003, I attempted several times to port to .NET but
failed. The code
was finally deemed importable in 2005. Still a backburner project, I slowly
worked on it as a side
project with my NET library, StarlightGL which allowed for some unavailable
graphics methods to
still be used by NET (use of native GDI and Pixel fonts, for example). It
started out working great and I thought i found my solution. In 2008-early 2009
i finished prelim testing on Firecode 9.0.1 and started serious work on it
again, but by the 2,300th build, I found that the more .NET you used with
native, the more performance losses endured-i benchmarked almost 9k page-fault
delta by the time that build ended! I was very very upset, had put almost 300
hours into code I had to scrap. I saved, however, starlightcore.dll which was
written in C++ and inline MASM, and from it's source, the core of Firecode 9.0.2
was born. At the time of this intro, it is April 19th, I put in about 6-7 hours
a day of work, which puts me at about 91 hours of development. I have in this
time almost completely duplicated all my work of StarlightGL AND Firecode into
this new version. It runs faster than NET version ever could, and uses a very
surprisingly low amount of memory. All the commands are now native and can be
unloaded when memory gets tight, this version is codename Phoenix because of the
nature of the 'rebirth' of this program. After testing on April 9th, I confirmed
that all code will be written in C++ from here on out (except accessories that
are short lived, such as the help and HLX editors that have no impact on the
system because they normally don't even run by the user) My goal here is to
provide a DOS-Like experience with all the 'prettiness' of a windows app. This
includes currently, support for ANY true-type, open type, or raster font (like
the veteran's famed Terminal which we all know is unavailable under NET (unless
you use StarlightGL or your own native code). Also, CMD.EXE does not allow for a
wallpaper, transparency, more than 16 colors at a time, multi-font support, rich
text viewing, image viewing, media (MCI) support. Also, in addition to the
typical 'drives' in dos, the user can also access certain hardware and software
targets as 'drives'. This will include but IS NOT limited to
the windows registry (REG:), the sound mixer (MIX:), the windows network (NET:)
where UNC paths used to be prohibited in DOS, will now be allowed through
Firecode as a wrapper to the low level nature of the operating system.
In the development process I will retain these solid ideals:
Key Driven: keyboarding is
the main interface, any interface the mouse can access should be primarily
available (and encouraged to be used) by keyboardMaximum Speed: always
coding in a way to show results, very very quickly, gives a hint on whether
or not my application is slowing the machine down, or helping you do things
faster
with little overhead.Accessibility: Any
function available under Windows Explorer AND the Command Prompt (cmd.exe)
must also available under Firecode.Optimization: Code to be
optimized to take advantage of some of the most important processor
technologies including MMX, 3DNow!, SMID, SMID2, and the floating point
unit, when applicable.Verbosity: Always give the
user feedback about status, errors, things that are happening, with the
ability to change the level of verbosity as high as 'Debug' and as low as
'Silent'Extensibility: Allow as
many features to be plug-in-driven and keep the SDK updated to allow users
to add or remove features in Firecode as they see fit.Resilience: Code in a
manner whereas if there is an error, allow the user to exhaust all methods
of resolution before program failure. (IE, if the HLX file is missing,
restore
it from a resource, keep DLL default commands bundled with the executable's
resourcesReliability: Make certain
to the user that the program ensures the safety of their data, this will
always come comes second to none allowing an easy method of reporting errors
or concerns to the developer(s).Portability: Offer the
capability of any OS build (versions for Windows, Unix, etc) This will
require some help from outside developers who I hope take interest in this
project.
April 7, 2009
_____________
Begin, Firecode Progress Log (at this time this is an offline progress log, not
released to the public)
v9.0.2
------------------------------------------------
v9.0.1.1833-2700
Ported from VB6 to C#3.0 (VSNET9) but suffered
a performance drop (serious one).
Dot Net code has proved to be much slower than
wanted. Unfortunately, despite the extensive
work on StarlightGL, I will have to put the
project to rest :( I am going to try
to use as much of the code as possible in
the new Native Win32 version.
now porting to:
v9.0.2.0 - 1499
April 8, 2009
-------------
Begin porting StarlightCore's DLL source and
Firecode 9.0.1 (.NET version) into C++/MASM
Support for Intrinsics and much faster code.
Many speed tests were performed on v9.0.2 and
v9.0.1 (even moving most drawing code to the
C++ StarlightCore did not perform 1/25th as
good the C++ Win32 Native code.
StarlightGL/Core no longer needed
FirecodeSDK no longer needed, a new one
will be created, but will use no libs
the plug-in functions aren't compatible
either, porting to a C++ dll, loaded
by LoadLibrary() and GetProcAddress()
(not by Assembly scan and Activator)
Tomorrow's Objective:
- Complete the Console Buffer class
- incorporate and finish Console class
- if there is time, implement the 2 new menu items SetWallpaper and SetFont
April 9, 2009
_____________
Code files to have a header with this format:
(DELETED- HTML FONT DOES NOT SHOW THIS CORRECTLY-SEE PROGRESS.TXT)
adapted from Firecode 9.0.1.1833
- 9:52AM - Finished Class CConsoleBuffer, preparing for runtime testing.
incorporated Console class.
- 8:01PM - Finished testing on CConsoleBuffer, 100% reliable and error-free
code file headers are all in place.
Tomarrow's Objectives
- finish basic Console class operation
- implement the new menu items SetWallpaper and SetFont
April 10, 2009
_____________
1:26PM - During the basic console class operation sequence, I have come to
discover
the following:
There is need for some new data types to support fast string output these
data types are the following:
WCHARARRAY - a free store array manager for strings (fast assembler optimized)
STRINGMEASURER - a utility class for measuring strings and DC bounderies
Today's Objectives Must Be Re-Ordered to Fulfill The Original Objectives:
- create and finish WCHARARRAY, then STRINGMEASURER
- STRINGMEASURER must be able to determine how many lines a string needs,
how many lines are left, how many scrolls needed to show a string, and
if a string will fit on a single line or if it needs broken
once this is done, the original objectives can be completed
but first I want to implement SetWallpaper and SetFont as they have
been delayed for several days and I want to get them out of the way
since they dont require these new structures and SetFont will help
guarentee testing of the STRINGMEASURER class is 100% accurate (TTF,OTF,etc)
- finish basic Console class operation
this item will be done today if there is time, otherwise will be done tomarrow
at the earliest convienience. (GS)
11:20PM - Objectives met: Implemented SetFont menu item, completed testing and
design of
the STRINGARRAY (aka WCHARARRAY).
Tomarrow's Objectives
- implement SetWallpaper command
- finish STRINGMEASURER and CFirecodeConsole classes
April 11, 2009
______________
9:00AM - finished SetWallpaper implementation, 100% working.
3:00PM - finished tweaking the SetFont menu item, to regain history
- more tweaks: added position-out of bounds checking on window resize,
and caret recreation and destruction to follow window design guidelines
3:05PM - starting string measurer class
3:35PM - finished string measurer class, 3 methods and 2 construction methods
3:37PM - started finishing CFirecodeConsole class (last objective of the day)
10:02PM - finished basic design of CFirecodeConsole, testing confirms 100%
operation
tested against Firecode 9.0.1 performance, porting to C++ gave me:
working set of 7kb instead of 70kb, 70 handles instead of 150, page faults
limited to GdiPlus and Dialog operation, delta never above 1 whereas with
9.0.1 the delta could be as high as 9,000 during simple keypress events.
overall performance testing concluded no memory leaks as opposed to CLR,
and that a 180% gain in performance, speed, and memory usage were obtained.
From here out, all other 9.0.1 code will be pseudo-ported to 9.0.2 meaning
i cant actually copy the code over and use it, but i can redesign clones
of classes and libraries (except starlightGL which isnt neccisary since it
was just a bridge to native API which firecode is immersed in now).
today was very productive and I have made my final decision to stick with C++
and assembler (MASM) from now on.
Tomarrow's Objectives
(going light since it's easter)
- tweak invalidation routeen - only invalidate written-to areas of the screen
- add some features to CFirecodeConsole
- work on designing command execution class and plugin library design
- do a flat speed test (via the 'dir' command hook)
if online
- get assembler language reference specific to MASM
- get some info on mmx and intrinsics
these objectives may be multi-day since I might not get to them at all tomarrow.
April 12, 2009 (Easter Sunday)
______________________________
9:00AM - added additional BITBUFFER (cobuffer) a compositing layer, to
doublebuffer
screen output and give smooth flicker-free feedback.
4:10PM - did no further work on this day.
April 13,14,15,16,17 (Mon-Fri) 2009
___________________________________
I had a very bad toothache this last week, and didnt get alot done, just bits
and parts really.
I will try to sum up in the next couple days. This has been a debilitating week
for me, I hope
to be back on track by monday.
April 18, 2009 (Saturday)
_________________________
Observing some of the code I partially did over the week, this includes the
following:
- Building of the Command class derived from the class built under C#
(v9.0.1.1833)
- Subclasses for internal and external commands differ in these ways:
- classes are NOT assembly driven, but are native DLLs instead, the gains
outweigh
the losses and include run-time upgrading, local thread mapping, etc
- The Command class now can contain several commands instead of just one, as can
the external DLL versions.
- CInternalWrapperCmd wraps a default behavior to all Internal commands used in
firecode
and CExternalWrapperCmd wraps the DLL's external behavior, also avoids alot of
code
duplication.
- both nExternal- and nInternal- wrappers derive directly from Command class, as
before
supports special 'coded commands' that tell firecode to do low level stuff as
well.
- finished the string array class and used it's bare bones to develop the
FirecodeArray template
which all other 'array' objects will be based on. Now that CExtStringArray is
complete,
it is also used by the SDK, but the source wont be distributed, it is
distributed in
a library form 'FCExtStringArray10.lib' and it's complementing header. Keeping
the source
hidden from developers who dont need to worry about it's function.
April 19, 2009 (Sunday)
_______________________
- Major work done on CExternalWrapperCmd, almost finished at 2:52PM
relooking at my objectives now, and finishing up some loose ends one by one :
* means finished
* tweak invalidation routeen --- finished, decided to go double-buffer and
intruduced the cobuffer layer to maximize speed
* add some features to CFirecodeConsole --- finished, added ConOutFast,Raw and
Regular Line-By-Line, for now it is as fast as I had hoped.
- work on command execution class and
plugin library design --- have been working on, but need to break this
generalization down into smaller tasks
These, not really objectives
- MASM reference? --- NO have not been online
- MMX intrinsics? --- dito :(
So 75% of my sunday (easter) objectives were completed no thanks to the tooth
ache!
I am going to map some new objectives for today and monday:
- Command Part:
- important! (priority) implement stdout/stdin pipe for console apps
(this is the main feature of firecode)
- finish CExternalWrapperCmd and get a success test run of base_cmd.dll
- implement a singular Internal multi-command class
schedule max finish date: April 22nd
- Interface Part:
- start work on the HLX text lookup/string pooling system
this involves an XML design, and will probably need C#
to get this done on schedule, shooting for May 1st.
- beta testing
- make conn's on irc efnet with coders channel find some beta
testers
8:53PM - After reading up on COM i have decided that instead of linking
multiple ProcAddresses from a command plugin, I will instead
create a Command base class whose implementation lies within
the main executable, the library for this will be exported to
support the base class in the SDK. Commands must derive from
and override pure virtuals, and return a pointer to the base class.
(This works along the lines of returing an IUnknown with COM)
CInternalCmdWrapper and CExternalCmdWrapper and Command classes were removed
from the project and placed in the .\Removed folder.
There will be one class for internal commands (since Commands
can be "hives" of commands as explained earlier).
This class is "CInternalCommandCluster" and derives from
CFirecodeCommand.
The new CFirecodeCommand Class features
- Execute can optionally called on ALL commands, increasing versitility
of the command (ie, 'cls' could be performd before other commands like 'type')
- class contained commands in the DLL, the DLL need only one exported function
which will be GetLocalInstance() and returns a pointer (*CFirecodeCommand)
- classes will not be loaded until needed
- this aglorithim was pretested in a seperate project "PluginServe/Client"
without any errors
Tomarrow's Objectives
- finish STDOUT/STDIN mapping and implementation
Monday, April 20, 2009
______________________
- worked on some code, but didnt get the STDOUT and STDIN mapping done, going to
take
some time to finish up UTE project to ease my highlighting scheme colors and
finish
it for public release
- Tomarrow's Objectives
Finish UTE 2.0 basic program operation
Tuesday, April 21, 2009
_______________________
- wrote the basic core for VS UTE v2.0 (couldnt find the code source for 1.0 so
i had
to rewrite it.
- basic functionallity auto-loads the default installation of visual studio
UserType.dat
file and tracks the validity of it's entries and saves it either to the install
or backup
- Tomarrow's objectives
Add support for Edit, View menu items
Add Add/Modify dialog
Wednesday, April 22, 2009
_________________________
still working on UTE, finished all graphics and made the functionality of all
menu items
work. Also added a bookmarks pane and toolbar to filter out certain entries, and
added duplicate entry detection.
Tomarrow's Objectives
- Add Help About dialog
- Add support for saving and loading settings
- Add toolbar representation of menu commands
Thursday, April 23, 2009
________________________
Visual studio Usertype editor is finished at 10pm EST. Added an about dialog
with
license agreement. Added a generic help file (in html) for unfamiliar users.
Also
added the toolbars and support for load/save. Menu items are added and are fully
functional. Some bugs are present (very minor) and may be fixed in comming
versions.
Added a Setup (Microsoft Installer .msi) program to install/replace/remove on
target
client's machines. Also tried to add an add-in version of the program but for
some
reason Add-Ins are not working with my version of visual studio! I will now
resume my
work on Firecode (this program in which the doc was meant for, although UTE is a
firecode
'utility project' and is in the same dir thats why I am writing this log).
Tomarrow's objectives
- resume work on firecode
- contain executable functions in a class FirecodeFramework (fireframe.dll)
- if there is time deal with the STD/IN/OUT and Command DLLS it is looking like
there
wont be time.
Friday, April 24, 2009
______________________
- 1:57 began resume work on firecode, starting with the FirecodeFramework
(fireframe.dll)
Tomarrow's Objectives
- STDIN/OUT test and implementation
Saturday, April 25,2009 - May 11, 2009
______________________________________
- Changes to the API are being made to encapsulate the core of the program.
Monday, May 11, 2009
____________________
- Cleaning the API of unneeded header files
May 11 thru May 24
_____________________
- All previous objectives have
been met. Also, the program has been tested for soundness and I am preparing to
commence to level 2; actual development of the client interface. Most of
the core libraries and binaries are in place and have been debugged as best as
possible at this time. I now am proceeding to port Firecode's sister
application, the HLXR editor. This editor is a special binary resource
editor that allows every aspect of Firecode to be changed without the threat of
reverse engineering the program. Since Firecode was rewritten since the
last HLX editor, and the old HLX file format is somewhat limited (also in size
limited to 64k) I have chose to rewrite it also. This will only be version 2.0
of the editor since it only had been written one other time.
I do not plan on keeping a log
on this until I reach the 24th, the deadline for the core of HLXRE to be
finished.
May 25, 2009
__________________
Core of HLXRE has been
finished, rather quickly done thanks to some ATL and MFC classes that sped up
production. I have finished within a day of my projected deadline. Also, I
have chose to put the project online, and it has been a nightmare, but I have
been playing with the idea of maybe getting some other developers in on the
project, since it is growing exponentially. Happy memorial day....
- END OF RAW PROGRESS LOG -
(BEGIN RSS PROGRESS (B)LOG) -
No comments:
Post a Comment