This blog has now been reacquired during paradisim's account reclamation project -- reacquiring lost accounts within the last 10 years. This is 1 of 3 accounts that has been recovered. For more on this:
http://paradisim.uuuq.com

PLEASE NOTE
The posts on here were formerly private, this blog is now going public as of June 14, 2012
I wont answer blogs replied to items written out before that time regardless of current date!

june 2, 2009

today:

Worked on HLXRE Interface for common editing tasks (formatting text and clipboard functions)
new classes: IEditCommand (CCmdTarget) interface class, handling editor commands in multiple views (text, image, etc).
Firecode was not worked on today.
HLXRE features added today were:
clipboard functions added for text, key and entry editors.
custom UI graphics finished and partially placed
context menus and their command mappings in place
added extra runtime checks for pointer variables
removed unused resource ids
removed unused accelerators
installed trace mechanism for editor views
installed multi-view menu commands (overloaded for all views)
updated missing prompts and missing pointer variables that were needed now but not before

tonight:
updated and added the rest of the website template pages and named them properly

tomarrow:

at least finish UI graphic importation
and write FC HLXRE non-mfc loader (binarytree-to-flat model)
start vg engine work

tomarrow maybe:

continue fleshing out website

june 1. 2009

Beginning of the month of june ( and summer )

The work on HLXRE - to - Firecode Integration has begun!  I have started the interface elements of HLXRE and with editing the UI elements of Firecode from within HLXRE. The purpose for this is to allow every aspect of Firecode to be editable but without having to know anything about graphic design or having expensive programs such as Photoshop to do these effects .  HLXRE will include a Rich Text style editor with some custom features as well as an Image, Cursor and Icon editor with preset templates for creating nice graphics quite quickly. 

My web page, http://paradisim.uuuq.com is still under construction. I used a template to save time but it is really cutting into my coding time (plus I have two kids and i need to spend time with them too). So I apologize in advance for spelling errors and leftover template trash. Anyone who used www.paradisim.net will find that it is gone. If you used InverseGoogle then you can find it now at http://paradisim.uuuq.com/ig (it is a nice convenient starting point for web searching in Google as well as some other engines without ads... I put it up mainly for my own purposes, but allow others to use it as well... my eyes are sensitive to light so this helps me a great deal).

STILL Looking For HELP...

I am still roving around the net looking for recruits-if this project is to be a success I will not be able to do this without help.  So far I haven't put too much into finding people or advertising, which is probably why nobody has visited this page  yet (since I haven't really even advertised it anywhere - if you are reading this and it is June 1st, then i would love to hear how you managed to end up here!! Anyway, that's it for now... lots of work to do, any interested parties should e-mail me or post a reply here, thanks.

Today's objective: finish up context menu and toolbar interface for HLXRE, get on irc and place my client online (no channel decided yet) on efnet. The channel will be published as soon as it is created. You will be able to contact me realtime this way (i DO NOT use ims-absolutely hate 'em).

may 31, 2009 (end of the month review)

End of the month, review time!
Right now: Firecode and HLXRE are both completed to the point that they perform all their core functions that will be the same from here to the time of release. The cores have been tested on both XP and Vista operating systems for right now. I have worked all memory leaks out of both and now, for june am aiming to actually get the meat of the project in the oven.

Today: finished up core testing, data loading and other such stress tests. Ready for phase two of the project which will begin tomarrow; the UI integration and implementation. I have been contemplating whether to start on UI at the graphics level, or at the logic level, or both... I think I will just have to see what happens as I start to integrate hlx into fc. A note on interface: if there is to be any unix support, someone is going to have to write the .so module support and nix-specific plugins, since I really don't have time for it. And as for OSX support, the same. If there's anyone out there that needs to kill some time and write some code, I have just the job for you! heh

may 30, 2009

Saturday! Weekend goals have been semi-met. HLXRE has been finished and I spent most of the morning/evening tracing out memory leaks which are all but gone now. I will be releasing the file format specification for .hlx in the next few days or so. I am just waiting for VS to be installed on my vista machine to ensure that forward compatibility is sound, though I haven't had any problems in cross-compilations as of yet. Good night everyone have a good weekend!

may 29, 2009

CPU overheating on both machines caused no constructive progress today. I managed to subscribe to a hosting service, the old website 'www.paradisim.net' is now closed. The new url
is 'paradisim.uuuq.com' and will be just like the old site was. My email is changed to that domain as well or at live.com, "gabriel.sharp.is.a" is the address followed by @ and the domain.

may 28, 2009

Objectives have been with debugging the VS macros that I use, making it somewhat easier to move, modify and delete code. Especially in the case of putting in description boxes and removing endless lines of wizard code (which we used to, in VC6, had the option of not having comments included, why was this taken out?). I have at this time finally started with my real day objectives, when I close for the day I'll let you know how it went. I plan on touching base with the main executable as well, but the hot weather is causing my CPU to overheat and I need to try to clean the fan here soon before i get another IRQL_NOT_LESS_OR_EQUAL error again!

may 27, 2009 (night)

Managed to clean up some of the project's useless files or leftovers of the port process. I will have to try to work double tomarrow to keep with the objectives. Also, I have found a subtle bug in VSNET, certain IDC_STATICs are being overwritten and crashing it, and Messenger seems to cause a crash, I have traced these to a root cause, although i am not sure of the signifigance of the findings... The CPU temp was up around 70C, very hot! I will have switched from air-cooled to water cooled system soon I hope....

Tomorrows Objectives

get an early start + previous objectives

may 27, 2009

HLXRE is at version 2.02, the file standard has changed as following:

- HLXR files are no longer in XML format, since Firecode is not in .NET anymore.
- The new format is as follows

File Extension: .hlx (same as before)


ByteOffset Length(bytes) Usual Value Meaining
----------------------------------------------------------------------------------
HEADER SECTION:
0x00 0x0A "FIRECODEPD" Firecode Portable Document Sig.
0x0B 0x02 0x0902 Expected Firecode Version or >=
0x0D 0x02 "ST" "Subtyped" document signature
0x0F 0x02 0x02 Sub type ID, 2=HLXR Document
0x11 0x05 "HLXRV" HLXR signature validates doctype
0x16 0x01 "2" Major file version (in 8bit asci)
0x17 0x01 "0" Minor file version = =
0x18 0x01 "2" File Revision, in ascii 8bit
0x19 0x01 "B" HLX Type: B=Basic F=Final***
0x1A 0x01 "A" HLX Pre-Release Change Ltr: A-Z
0x20 0x02 0x0202 file version validation****
0x22 0x01 0x02 version type validation****
0x23 0x02 0x0FFFE or 0x0FFFF document flag (see doc flags)
0x25 INDEFINITE Root node in which all other nodes are contained
there is only one root node, extra data at the end of the
file is ignored, but data after the end of node IS allowed however is reserved for later use and not standardized.

NODE:
DWORD number of child nodes in this branch (see node structure)
DWORD number of data keys for this node

STR node name (null-terminated, unicode)
CHAR lock flags, bit0 = locked, 1-7 reserved
CHAR extra flags, bit0 = flags defined, 1-7 reserved
CHAR system flags, bit0= is a system-defined node, 1-7 reserve
GUID 192 bit GUID (see GUIDs below)

END NODE



DATA KEY:
STR Iten name in unicode
STR Item data or text body, unicode or raw
DWORD Item Flags (32-bit) (see item flags)
STR Item description in unicode
GUID 192 bit GUID (see GUIDs below)

END DATA KEY



The file is basically structured like this:



HEADER SECTION

ROOT_NODE

DATAKEYS

may 27,2009

Firecode is still in it's pre-release state for version 9.0.2. It is written in C++ without MFC. Intrinsics and alot of inline assembly (and some pure asm libs) make this code fast.

Currently I am working on the UI, to make it look pleasing to the eye, like WPF without using it.

Working without NCPAINT has commenced because NCPAINT was too restrictive, even though it did work ok... I am not going to use uxtheme, so i can make the app more portable. I have completed the CExtWindow class which supplies an MFC-Like CWnd class without overhead (very small model)

Today's objectives

To get the main frame paint functions to include even nonclient areas which will be managed also by Firecode, this requires the following NEW classes:

CPainter
CFramePainter
CCaptionPainter
CButtonPainter

CFrameWidgetPainter
where W will be the widget type: CwScrollbar, CwSizeGrip, CwToolCaption, CwIcon, CwDrag, CwFocusMarquee, CwInactivateMask, CwHotMask, CwOverMask

the classes will be initiated today, starting at the top and working my way down, to help label these files' comment h eader (in the source, at the top of the file) I have grown tired of entering the info in and drawing endless text rectangles that nobody will see but me, so I have written a series of macros to automatically label the files for me, completely. All i need to do is add a description and im done. I have packaged these box-drawing macros to this article, you may use them to label your files as well (and since TheDraw doesnt work right with cut/and paste this is a must!)

Tomarrow's Objectives

Return to HLX development, i am short on artists and need more help programming and with artwork, you dont need to be both, so if you want to help, reply to this entry or email me.

may 26, 2009

Today, i am finally making regular posts here. The status of my projects which I am working on. These are currently:

- Firecode 9.0.2pr
The Firecode Plugin API (FCSDK)
The Firecode Framework API (for windowing, a lightweight alternative to MFC)
Firecode Command Plugins (so far, ntfio.dll and ntops.dll - file and operation commands)
Firecode Text Translator Plugins (currently, just the nthlxcodec.dll)

Firecode is going to be the flagship product, a replacement for cmd.exe and maybe even explorer.exe some day. It is being developed under Windows XP Pro SP3 and Windows Vista Ultimate, in which I have full licenses for both.

- HLXRE (HLX Injectable Zero-Memory Object Resource Editor)
requiring: nthlxcodec.dll and mfc71x.dll (where x is many various counterparts)

some of the object files (such as ExtHeapMgmt) are shared between the two, but
that doesnt mean they are meant for public free use... see the LICENSE.txt if you
are a joint developer (which currently there are only 2)

may 25, 2009

About Firecode, HLX Editor, and this Blog

This is a public blog where I post my progress for my main project, Firecode.
Firecode is a command shell replacement for Windows and (in the future) other operating systems. It can do anything it's predecesor can do and more. Think of it as a way to do tasks
that would otherwise require a mouse. My goal with this project is to provide an up-to-date look and feel to the command shell world. Many shells do not take advantage of new technologies offered these days. Also, I will publish general findings in the course of my work, including solutions and workarounds to the many challenges of programming in C++ and assembler. I wish to remind myself and others that I do not wish to discuss CLR or the .NET framework library (yes this includes frameworks built on .NET like WPF). I do however welcome discussions on stability-proven frameworks such as MFC and ATL to name a few. For now I would like to keep exposure to COM at a minimal until it is really needed for the project, and I welcome and value anyone else's input. Like I said before, nobody is probably going to participate in this blog--so I am mainly using it as a personal online progress log (the PROGRESS text file included in firecode 9.0.2 prerelease builds).

jan 2, 2009 untill may 1, 2009

Up until now, my coding nightmare has been of a private nature, but still logged. Here is the Explanation of my project:

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 keyboard

  
  


• 
  

  Maximum 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
  resources

  
  


• 
  

  Reliability: 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) -