Show Posts
1
Ultra Hal 7.0 / Registry Assault
« on: September 08, 2001, 06:29:27 pm »
"I'm sorry dad, but all my friends were jumping off the building so I thought I should too."
Just to make a point. Not to be saucy. Microsoft is not my boss. Microsoft is not your boss. Do stuff because it's the right thing to do, not simply because MS throws "gadgets" at you and you feel obligated to use them. I'm something of a code purist.
Just because the almight MS decides to put a new "overlord" system into the OS doesn't mean everyone must use it.
Occom's Razor: the simplest path is usually the best path
This is what I miss from the days when programming had to conform to cpu speed and storage limitations. Writing compact, efficient code was the imperative. If everyone were to go back to that system, software speeds would be close to 10 times as fast as most current commercial Window's based software.
Today's method seems to be to try and be slick by incorperating everyone else's code libraries without any thought put into impending hardware compatibility issues.
Check out GRC.COM if you'd like to see some "oldschool" programming technique. It's all about security. But, i digress.....
A simple updated set of checksums within hal's own code could allow him to verify that his main files haven't been corrupted in some way. No highly suspect MS routines need ever be called upon to police your software.
A great programming moray would be to make your code as self sufficient as possible without relying on too many outside agencies for little, quirky (in)convenience routines.
Please let MS do policing on their own DLL's and let your program be system independant and handle it's own affairs. Don't just fall inline as an MS drone. We don't need any more of those.
----------------------------------------------------------------------------
As I see from your website and from your posts, Hal needs to do a few things.
1. Needs to read text files (Html, MS Word docs, PDF files, too, maybe, sometime? That would be super.)
2. Needs to access to the program menu. ( a second user-defined program list would be a great addition also.)
3. Needs access to the MS dialer.
4. Needs access to the Web browser.
5. Needs access to the SAPI devices (speech rec, synthesis)
6. Hal needs to know his main files are not corrupted before he runs.
All functions could be internal to hal's program with nothing but simple I/O calls to each necessary MS or 3rd party program.
-----------------------------------------------------------------------------
Hal doesn't need any outside installer program to place him in the startup area. That's easily done with a batch file from within hal's directory. Also, it should not be assumed that every user wants this program to autorun without even offering a choice before installation. It should be a secondary act, after installation, that the user decides at that time.
Here is a process that is simplicity itself. And it would make your software the ultimate in hardware compatibility
On dealing with installs:
1. Program is installed in it's own directory.
2. A box asks the user if he/she would like hal to run at startup.
3. If user say's yes, then the batch file places hal's main EXE path in the startup directory.
4. If someone wishes to uninstall hal, simply deleting the hal folder and deleting the program list entry wipes out all traces without using MS's somewhat confused and invasive "install wizard" crap.
All Done. One shot install. One shot delete. Amazingly, both done with a simple BAT file from within hal's own directory. Wow.
File test before running:
[/b]
Each time Hal runs, He does a quick checksum on his main files and determines if they've been corrupted. Pklite can do this for your exe files with no slowdowns. You should really look into it. PKware's systems have been tried and tested for years now, UNLIKE MS's new routines which routinely have bothersome unforseen bugs until about three versions into the process.
With FAT32 there is no lack of space. Hard drives are huge these days and only getting bigger. Don't be afraid to use a simple, single global ini file for hal's "personal data". I don't think one ini file or even 20 ini files in hal's folder will cause any undue hardship.
Check out this URL and read about FAT32 and it's "fewer limitations"
http://support.microsoft.com/support/kb/articles/Q154/9/97.ASP
Just because it's cool to use MS internal functions, it doesn't mean it's always the best idea.
Try to write your code as if you're working from pure DOS and you'll make it easier to work with and easier for you to port to other OS's if you decide to go that route.
This sickening dependance on unnecessary MS OS internal programs is just WRONG.
Take it back to basics. The basics always work. The basics can be just as convenient as using MS routines, where users are concerned.
Just my 2 cents as a systems analyst. I'm doing this for fun, not fees.
Just to make a point. Not to be saucy. Microsoft is not my boss. Microsoft is not your boss. Do stuff because it's the right thing to do, not simply because MS throws "gadgets" at you and you feel obligated to use them. I'm something of a code purist.
Just because the almight MS decides to put a new "overlord" system into the OS doesn't mean everyone must use it.
Occom's Razor: the simplest path is usually the best path
This is what I miss from the days when programming had to conform to cpu speed and storage limitations. Writing compact, efficient code was the imperative. If everyone were to go back to that system, software speeds would be close to 10 times as fast as most current commercial Window's based software.
Today's method seems to be to try and be slick by incorperating everyone else's code libraries without any thought put into impending hardware compatibility issues.
Check out GRC.COM if you'd like to see some "oldschool" programming technique. It's all about security. But, i digress.....
A simple updated set of checksums within hal's own code could allow him to verify that his main files haven't been corrupted in some way. No highly suspect MS routines need ever be called upon to police your software.
A great programming moray would be to make your code as self sufficient as possible without relying on too many outside agencies for little, quirky (in)convenience routines.
Please let MS do policing on their own DLL's and let your program be system independant and handle it's own affairs. Don't just fall inline as an MS drone. We don't need any more of those.
----------------------------------------------------------------------------
As I see from your website and from your posts, Hal needs to do a few things.
1. Needs to read text files (Html, MS Word docs, PDF files, too, maybe, sometime? That would be super.)
2. Needs to access to the program menu. ( a second user-defined program list would be a great addition also.)
3. Needs access to the MS dialer.
4. Needs access to the Web browser.
5. Needs access to the SAPI devices (speech rec, synthesis)
6. Hal needs to know his main files are not corrupted before he runs.
All functions could be internal to hal's program with nothing but simple I/O calls to each necessary MS or 3rd party program.
-----------------------------------------------------------------------------
Hal doesn't need any outside installer program to place him in the startup area. That's easily done with a batch file from within hal's directory. Also, it should not be assumed that every user wants this program to autorun without even offering a choice before installation. It should be a secondary act, after installation, that the user decides at that time.
Here is a process that is simplicity itself. And it would make your software the ultimate in hardware compatibility
On dealing with installs:
1. Program is installed in it's own directory.
2. A box asks the user if he/she would like hal to run at startup.
3. If user say's yes, then the batch file places hal's main EXE path in the startup directory.
4. If someone wishes to uninstall hal, simply deleting the hal folder and deleting the program list entry wipes out all traces without using MS's somewhat confused and invasive "install wizard" crap.
All Done. One shot install. One shot delete. Amazingly, both done with a simple BAT file from within hal's own directory. Wow.
File test before running:
[/b]
Each time Hal runs, He does a quick checksum on his main files and determines if they've been corrupted. Pklite can do this for your exe files with no slowdowns. You should really look into it. PKware's systems have been tried and tested for years now, UNLIKE MS's new routines which routinely have bothersome unforseen bugs until about three versions into the process.
With FAT32 there is no lack of space. Hard drives are huge these days and only getting bigger. Don't be afraid to use a simple, single global ini file for hal's "personal data". I don't think one ini file or even 20 ini files in hal's folder will cause any undue hardship.
Check out this URL and read about FAT32 and it's "fewer limitations"
http://support.microsoft.com/support/kb/articles/Q154/9/97.ASP
Just because it's cool to use MS internal functions, it doesn't mean it's always the best idea.
Try to write your code as if you're working from pure DOS and you'll make it easier to work with and easier for you to port to other OS's if you decide to go that route.
This sickening dependance on unnecessary MS OS internal programs is just WRONG.
Take it back to basics. The basics always work. The basics can be just as convenient as using MS routines, where users are concerned.
Just my 2 cents as a systems analyst. I'm doing this for fun, not fees.