31 replies to this topic

[Gene]

Give "compiled" scripts the ability to ingest a file or to be stuffed in the same/similar way the "compiler" handles FileInstalls.

Currently if an INI or other data file is accidentally/inadvertently deleted, changed, corrupted or a compiled script registry entry is deleted, changed, or corrupted there is no easy way to recover. If a file is deleted in GUI mode and the user or their advisor are aware of the recycle bin, thats easy enough to get back unless it was on a small network and backups are erratic. But with registry entries and changed or corruped files there is often little chance of recovery. Why do I want to put them into the EXE, because in my experience, inveterate tinkerers regularly damage configuration and data files but usually leave the EXEs alone.

I realize that there are hurdles to this:
1- It may not be possible in any way.
2- Windows won't let you change a running executable.
3- There would be a reasonable size limitation.
I'm sure there are others...

Hurdle 1 may be a killer, but number 2 might not be. Since Windows will let a ZIP program add files to a self extracting .EXE, an EXE spawned on exit could add file(s) and file encapsulated registry entries to the main or other compiled EXE once it is no longer running. That would take care of hurdle number two. Hurdle 3 would have to be an arbitrary limit, I can see how a feasible limit could be impacted by RAM and HD size.

There would be security issues if running from an application server and some Win2K and XP PCs.

There would be issues about how to determine if a file had changed or been corruped. I would guess that an MD5 comparison would be effective.

Should the compiled script developer determine the actions to take on discovering missing or changed file(s) or registry entries, or should the user be given options? That last isn't really an AutoIt developer issue, but it will be for script developers.

I see that there are a number of negatives about this idea, so why am I setting myself up for a blast from Valik and maybe others too? I'm not seeing this from the LAN/Server Admin. or business software developer points of view, even though I have done those things in business networks from 30 PCs to more than 8000. I'm seeing that script developers are or are going to use AutoIt to develop applications for PCs at home and in small businesses with no or only rudimentary networks. That's what I am doing, I don't have many yet, and most are utilitarian. I'm not alone and there will be more. Given that, many of the negatives don't apply as strongly.

This may not be worth doing, but it is worth considering.

(Edited to put in the last point, and fix spelling)

Gene

Edited by Gene, 19 October 2005 - 03:33 AM.

[Valik]

I fail to see the correlation between your idea and your "problem". Its not very hard to restore missing files (Which are FileInstalled()) or to validate missing data. Good applications should have a default behavior for missing/invalid objects so it should be easy to convert from having a default to providing a default. Meaning, if the user deletes the INI, detect the missing file and re-install a fresh copy with all the defaults in place. Restoring missing files is as simple as:

If Not FileExists($sIni) Then FileInstall(".\SourceIni.ini", $sIni)

Restoring corrupted or missing data (inside a file or the registry) is slightly harder since it must be validated first.

This is all application specific and I don't see how it relates at all to being able to "ingest" files. In fact, the problem you describe is solvable in multiple ways with AutoIt as it currently is. I can't imagine the same users stupid enough to go around deleting random files are smart enough to find files if you back them up to a directory somewhere (@AppData) or just create your own file format somewhere which stores the important information.

[Gene]

I fail to see the correlation between your idea and your "problem". Its not very hard to restore missing files (Which are FileInstalled()) or to validate missing data. Good applications should have a default behavior for missing/invalid objects so it should be easy to convert from having a default to providing a default. Meaning, if the user deletes the INI, detect the missing file and re-install a fresh copy with all the defaults in place. Restoring missing files is as simple as:

If Not FileExists($sIni) Then FileInstall(".\SourceIni.ini", $sIni)

Restoring corrupted or missing data (inside a file or the registry) is slightly harder since it must be validated first.

This is all application specific and I don't see how it relates at all to being able to "ingest" files. In fact, the problem you describe is solvable in multiple ways with AutoIt as it currently is. I can't imagine the same users stupid enough to go around deleting random files are smart enough to find files if you back them up to a directory somewhere (@AppData) or just create your own file format somewhere which stores the important information.

Hi Valik, I expected you to jump on this quick, I did expect you to read it first. Of course it is easy to replace INI files with fresh ones, but if the user has (thru the program) changed the settings, that is not very useful. Additionally, whether it is elegant or not, quite a few people store data in INI files because it is easy and you don't have to read thru a file to find the data. I like to use delimited text files, but if I don't think there will be a lot of data, I use INI files for data too.

I specifically mentioned INI and data files (that would be user data) not easily replaced since the developer won't have a clue what the user(s) will put in it. I never mentioned anything about having a "problem", you made that up out of whole cloth (that means it is a fabrication). I also never mentioned anything about the user finding files backed up to a directory, you made that up too. As for restoring other files with the current implementation of FileInstall, that's all well and good if the developer can magically know what the user will put in them. As good an opinion as you obviously have of yourself (some of it deserved), I don't believe even you would give yourself credit for that. As for relating to being able to "ingest" files, I said ingest or be stuffed in the same/similar way the "compiler" handles FileInstalls. I think you're smart enough to understand that, but in case I'm wrong... When a FileInstall is coded into a script, the "compiler" compresses the referenced file and puts it in the resulting executable. I'm sure you understand the rest of the process.

Hiding files elsewhere as you suggest is an invitation to have one or both sets deleted as duplications.

While it is a stereotype that developers believe all users are stupid, only occasionally is that correct. Many users are in fact, ignorant of things obvious to developers, LAN Admins and other computer knowledgable people, but that doesn't make them stupid. Ignorance can be fixed, but the stupid you refer to in your frequent diatribes is forever. A seemingly good example of stupid is driving drunk, in any degree, but deveopers, doctors, lawers, law officers even EMTs do it, both the stupid and those not do it. You are obviously not stupid, but you are a brilliant JERK. But you could get over it, maybe.

If you were to really read the initial post, without the attitude, with an open mind, but then, I don't think ther has been more than twice that I've read anything by you that didn't have the attitude. Fortunately, most of the other developers are also smart and talented like you, but have MUCH less attitude. Consider, if Jon or JPM had your attitude what would be the state of AutoIt and Scite now?

Gene

[LxP]

Gene, could you please give some examples of situations where this functionality would be used and what actions would be undertaken by it? I think I might not be getting your idea yet because I would suggest that this is possible with AutoIt already (however not automatically -- it would require code written by the scripter).

[DaveF]

Gene, the functionality that you're describing would be a malware builder's dream come true. Anyway and regardless...

I think your point number 2 is why you should continue to other options. If the EXE is editable to the user, it's delete-able by the user. If you don't trust them not to delete registry settings I really don't see how you can trust them not to jack around with the EXE.

If you're really worried about the settings being preserved, name the INI file after the user name and copy it to an FTP host or a network share, either way you could use different credentials than the user so the user doesn't have to have rights to the remote repository, and you'd get the added benefit of the settings being distributed to wherever the user might log in.

[/dev/null]

Gene, I don't get yor point. If you don't trust the users to make backups of their data AND you expect them to delete the config files what do they deserve?? Even if you were able to write the config data into the EXE, what happens if the EXE needs to be deleted because it was infected by a virus? Whoops, gone are all your config data. What happens if the hard disk crashes? Whooops, gone are all your config data. There is no way around a proper backup of data. You simply can't compensate every stupidity a user might come up with. AND, the most likely reason why this will never be implemented. As DaveF already said: a malware builder's dream would come true. So, better forget about such a feature.

Cheers
Kurt

[Valik]

Wow, Gene, you were just baiting me and waiting to go off on me. Bravo to that. I think I could of posted anything as a response and gotten the same idiotic reaction from you.

I'll randomly address things below which I feel compelled to address. I'm not in the mood to do my usual point-by-point demonstration on all the places where you're just plain wrong.

First of all, notice I put the word "problem" in quotes (At first usage, any subsequent usage was forgetfulness rather than trying to imply a problem). That was meant to demonstrate that I know you did not have an actual problem. I was conjuring up situations similar to why one might want to "ingest" files and using them to demonstrate how its simple to work-around the problem.

Second, I was trying to point out that there are numerous ways to back up or store user's data and it is your responsibility to do it, not the language. I can think of at least half a dozen off the top of my head and most of them are trivial to implement. Some are, of course, simple and some are complex but all are viable alternatives to "ingesting" file(s) into the compiled binary.

As far as I'm concerned, Gene, you made yourself look like a damn fool with this thread. First you come up with a stupid idea that was ill-thought out (Or you would have seen the obvious malware implications which I totally avoided commenting on, by the way, opting instead to try to provide useful alternatives). Then I respond that there are better ways to accomplish what the overall goal of your (poor) idea was. What do I get? I get an attack from you that I didn't even provoke. You seemed to already have a fill-in-the-blank reply ready-made for me in the event that I did reply.

Now I'll point out a couple flaws in the arguments you have tried to use. First, did it occur to you that maybe the user wants to delete the data? Maybe they want to clear the data and start over? How can they do that if you store the data where they can't find it? You at least have to provide a feature of the program to do that. But then maybe they corrupted the data and your program won't even run because of the corrupt data. Then they may not be able to get to your built-in "clear" feature and they also can't find the data storage location; what then?

Oh, and before I forget, yes, you did say files could be deleted so I added context to it to show how to avoid that being a problem. So again, you attack me for no reason.

And lastly... don't you think "JERK" is a bit... weak? I'm at least a bastard, yes?

[Gene]

Gene, could you please give some examples of situations where this functionality would be used and what actions would be undertaken by it? I think I might not be getting your idea yet because I would suggest that this is possible with AutoIt already (however not automatically -- it would require code written by the scripter).

Thank you for your reply.

I'm thinking that use of this function would be determined by the (for convenience when I say developer, I mean the "compiled script developer" , and AI dev. means developers of AutoIt) developer. In those instances where the developer detemines or knows the the names of all the data and config files either directly or via an INI setting, the developer would (due to issue 2 in the original post) spawn another GUI or consol app on exit that would take either an MD5 key or at least a CRC reading of each file then compress and store them insde the EXE. As I mentioned before there would obviously be a size limitation and depending on where the EXE was run from, there could be security issues. That is why I pointed out that I'm focused on home PCs and very small business. On startup of the main app. the MD5 or CRC of the found data files woul be compared to those of the same named stored files. If there was a mismatch or the files were missing, then the app. could either rename the found mismatched files and extract the stored files in the case of changed or corruped files or ask the user whether to use the changed mismatchd files or use the stored files. In the case of missing files it could simply ask the user if the files had been moved and if so use FileSelectFolder for the user to navigate to the new location. If the user user didn;t know what had happend to the file(s) the stored files could be extracted and the app. could continue.

Most of what I suggest above would be the responsibility of the developer. The only thing I'm asking of AI devs is to provide the capability to directly or more likely indirectly add files to the executable in the field.

I believe that most home PCs are not backed up. More over a large portion of PCs in small businesses that are backed up are not done daily or regularly. Most homes with PCs also have children, PCs at small businesses are subject to entertaining children when they can't be at daycare, school or where ever. Children are insatiable explorers and cannot resist tinkering. Some adults are the same.

When you are dealing with people at home or running small business you don't tell them how stupid they are for not securing their PCs from their children, at least not if you plan to continue doing business with them. So you try to think of ways to protect them from themselves. I've got other responses to answer, if I haven't answered you questions here, maybe I will there.

Gene

[Gene]

Gene, the functionality that you're describing would be a malware builder's dream come true. Anyway and regardless...

I think your point number 2 is why you should continue to other options. If the EXE is editable to the user, it's delete-able by the user. If you don't trust them not to delete registry settings I really don't see how you can trust them not to jack around with the EXE.

If you're really worried about the settings being preserved, name the INI file after the user name and copy it to an FTP host or a network share, either way you could use different credentials than the user so the user doesn't have to have rights to the remote repository, and you'd get the added benefit of the settings being distributed to wherever the user might log in.

Thank you for your reply.

As I mentioned earlier I am focused on home PCs and very small businesses. Medium and large business access and data security protocols do not usually apply until they have been horribly burned. Until they've been burned they can't justify the cost of those procedures whose value is well understood in larger environments. Many if not most of these environments have no dedicated or even knowledgable person in charge of hardware and software, much less access or data security. Please read the reference to children in my previous response in this thread.

Given the current FileInstall capability it may already be a malware developer's dream. All he/she has to do is come up with a legitimate tool and FileInstall whatever disguised load s/he desires. On the first, 50th or 200th or after some date or when some othe specific software is running it can spawn the load(s) it is carrying. How many people have broadband access to the Internet and also have quality well configured Firewalls? The more important question is how many have no protection at all? If a well behaved useful app. application suggests to the user that it be allowed to check for updates, how many users will say no? Given permission, an AutoIt app. could legitimately phone home any number of times with the users knowledge, with a spawned app. it could phone home without the the users knowledge. During any of those sessions it could download and execute anything.

I never meant that the user would direct this capability. This would be driven by compiled script developers, of course a developer could create a tool that would give the capability to users.

What I am asking for from the AutoIy Devs, is the ability for compiled script developers to compress and add files to the EXE in the field. I expect that would have to be done (if technically feasible) by an app., console or GUI, spawned on exit which would act once the EXE was no longer running. I would leave functional implementation to compiled script developers.

Gene

[Valik]

Gene, let me ask you this. Can you name a single piece of software that uses the method you are describing to store its data files? In the decades of computing, people have stored data in databases, INI files, plain-text files, the registry, persistent storage, custom file formats, XML files, NTFS streams, archive formats. With the exception of NTFS streams which aren't very reliable (Copying the file doesn't copy the stream data, too), I can name you a large application that has huge market penetration and they have somehow survived with on-disk or registry based data storage. Can you name just one application which stores its data inside its own executable and dynamically updates it on termination?

[Gene]

Gene, I don't get yor point. If you don't trust the users to make backups of their data AND you expect them to delete the config files what do they deserve?? Even if you were able to write the config data into the EXE, what happens if the EXE needs to be deleted because it was infected by a virus? Whoops, gone are all your config data. What happens if the hard disk crashes? Whooops, gone are all your config data. There is no way around a proper backup of data. You simply can't compensate every stupidity a user might come up with. AND, the most likely reason why this will never be implemented. As DaveF already said: a malware builder's dream would come true. So, better forget about such a feature.

Cheers
Kurt

Thank you for your reply.

It is not that I don't trust users, I do trust them to mean well and to make mistakes dumb or otherwise because the are ignorant in many areas of computer technology. As I mentioned before I'm focused on home PC users and very small business environments. In these environments access security and data preservation protocols are seen as costly inconveniences. I mentioned INI files and data files too. I keep hoping someon will mention how a developer being able to compress and add files to an EXE is so much better for the nefarious than features already builtin, such as FileInstall, the ability to download and execute files from the Internet? Nearly anyone can use FileInstall to spawn and execute an app. to examine a hard drive or network looking for information of value. the TCP functions allow an app. to phone home or anywhere else and carry on any conversation. Already any app can initiate FTP sessions and move files in either direction.

You are right no one can protect people from all stupid activity or inactivity, but when you know and like them, and your livlihood (sp) depends on them, you find you're willing to try.

Gene

[Gene]

Wow, Gene, you were just baiting me and waiting to go off on me. Bravo to that. I think I could of posted anything as a response and gotten the same idiotic reaction from you.

I'll randomly address things below which I feel compelled to address. I'm not in the mood to do my usual point-by-point demonstration on all the places where you're just plain wrong.

First of all, notice I put the word "problem" in quotes (At first usage, any subsequent usage was forgetfulness rather than trying to imply a problem). That was meant to demonstrate that I know you did not have an actual problem. I was conjuring up situations similar to why one might want to "ingest" files and using them to demonstrate how its simple to work-around the problem.

Second, I was trying to point out that there are numerous ways to back up or store user's data and it is your responsibility to do it, not the language. I can think of at least half a dozen off the top of my head and most of them are trivial to implement. Some are, of course, simple and some are complex but all are viable alternatives to "ingesting" file(s) into the compiled binary.

As far as I'm concerned, Gene, you made yourself look like a damn fool with this thread. First you come up with a stupid idea that was ill-thought out (Or you would have seen the obvious malware implications which I totally avoided commenting on, by the way, opting instead to try to provide useful alternatives). Then I respond that there are better ways to accomplish what the overall goal of your (poor) idea was. What do I get? I get an attack from you that I didn't even provoke. You seemed to already have a fill-in-the-blank reply ready-made for me in the event that I did reply.

Now I'll point out a couple flaws in the arguments you have tried to use. First, did it occur to you that maybe the user wants to delete the data? Maybe they want to clear the data and start over? How can they do that if you store the data where they can't find it? You at least have to provide a feature of the program to do that. But then maybe they corrupted the data and your program won't even run because of the corrupt data. Then they may not be able to get to your built-in "clear" feature and they also can't find the data storage location; what then?

Oh, and before I forget, yes, you did say files could be deleted so I added context to it to show how to avoid that being a problem. So again, you attack me for no reason.

And lastly... don't you think "JERK" is a bit... weak? I'm at least a bastard, yes?

Hi again Valik,

I don't think I was baiting you, but if I was it wasn't very difficult. No, Valik, threre were many respnses you could have made that were equally opposed to my request that I would have respected, whether I agreed or not. I have read many of your responses to contributors in this forum. You manage to disagree quite civily and thoughtfully to those you apparently deem people. To the others, you respond just as thoughtfully, but delivered in words calculated to wound and anger. Oh, disagreeing with you is not proof of stupidity.

I am reminded of a character in the movie "McCabe and Mrs. Miller", three toughs are sent to kill McCabe. One of them, a relatively young man challenges another younger man to a gun fight for the privledge of crossing a footbridge. In the ensuing conversation where the younger man tries to get out of it he says that he is not sure his gun is in good working order. The challenger immediately says that he knows about guns, maybe he could fix it. Of course when the the younger man touched the gun, the challenger shot him dead. You do that with words, you're very good at it.

I have responded to 3 previous responses in this thread, they respond to some of your issues.

Your paragraph that begins "Second, I was trying to point " I agree with.

I would have liked your commenting on malware, I think there are already many features in AutoIT that would make the malware people deleriously happy.

You know, a forum is not just a stage to give the smart folks a place to shine. Many good thing have come out of mistakes and bad ideas.

Applicacations should always give users tools to delete records, and files deleted while the app. is running need not be seen as missing, but could be noted to be sure.

Following is a quote from my original post which you have conveniently failed to note.

I see that there are a number of negatives about this idea, so why am I setting myself up for a blast from Valik and maybe others too? I'm not seeing this from the LAN/Server Admin. or business software developer points of view, even though I have done those things in business networks from 30 PCs to more than 8000. I'm seeing that script developers are or are going to use AutoIt to develop applications for PCs at home and in small businesses with no or only rudimentary networks. That's what I am doing, I don't have many yet, and most are utilitarian. I'm not alone and there will be more. Given that, many of the negatives don't apply as strongly.

This may not be worth doing, but it is worth considering.

In your paragraph that begins...
"Now I'll point out a couple flaws in" Other that the first 4 sentences you make good points.

You have covered for many of your attacks by saying you speak plain and don't pussy foot around, in gist, if not in quote. With someone who presents themselves as you do, I don't either.

As for you being a brilliant JERK or a bastard, I yield to your greater knowledge of yourself.

Gene

[Gene]

Gene, let me ask you this. Can you name a single piece of software that uses the method you are describing to store its data files? In the decades of computing, people have stored data in databases, INI files, plain-text files, the registry, persistent storage, custom file formats, XML files, NTFS streams, archive formats. With the exception of NTFS streams which aren't very reliable (Copying the file doesn't copy the stream data, too), I can name you a large application that has huge market penetration and they have somehow survived with on-disk or registry based data storage. Can you name just one application which stores its data inside its own executable and dynamically updates it on termination?

Hi Valik,

This is your first civil response. Thank you.

No, I cannot. But, just because it isn't being done, doesn't make it wrong. I refer you to one of my previous statements. "This may not be worth doing, but it is worth considering." Most of the "BIG BOYS" in the industry have avoided doing one thing or another until an upstart began eating their snacks with what they had avoided. Microsoft is famous for many things, including buying up small companies doing something MS said was not feasible.

Gene


PS. You are one of the smartest people I have read here. I don't understand why you use it as a weapon against people who are either not as smart as you or who aren't as far along in experience or career as you. You could add sooo much more to this forum.

[Celeri]

Give "compiled" scripts the ability to ingest a file or to be stuffed in the same/similar way the "compiler" handles FileInstalls.

Currently if an INI or other data file is accidentally/inadvertently deleted, changed, corrupted or a compiled script registry entry is deleted, changed, or corrupted there is no easy way to recover. If a file is deleted in GUI mode and the user or their advisor are aware of the recycle bin, thats easy enough to get back unless it was on a small network and backups are erratic. But with registry entries and changed or corruped files there is often little chance of recovery. Why do I want to put them into the EXE, because in my experience, inveterate tinkerers regularly damage configuration and data files but usually leave the EXEs alone.

Gene

Well having read all the replies on this board (and not being able to sleep/code/whatever), might I suggest another approach?

Case in point one of my clients. A rehabilitation house with a few computers. The owner had me install the systems and he needed security. So I made a small program in AutoIT3 that locksdown a user (you need at least XP) so that he can only run a set number of programs. Added to that I changed the user's security level from administrator to simple user. So it's a cage you'd be hard pressed to get out of.

With a few tricks the user can only access A: and My Documents. The rest is off limits.

I know, I hate police states as much as anyone else but hey, that's what my client wanted and he's just so happy about his setup ...

If this looks like something that could help you out I can give you a few pointers on how to make such a program. Just say GO (no I won't post or give my au3 file - I'd have to translate it to english first and I just don't have any time or interest for the moment ...)

[Gene]

Well having read all the replies on this board (and not being able to sleep/code/whatever), might I suggest another approach?

Case in point one of my clients. A rehabilitation house with a few computers. The owner had me install the systems and he needed security. So I made a small program in AutoIT3 that locksdown a user (you need at least XP) so that he can only run a set number of programs. Added to that I changed the user's security level from administrator to simple user. So it's a cage you'd be hard pressed to get out of.

With a few tricks the user can only access A: and My Documents. The rest is off limits.

I know, I hate police states as much as anyone else but hey, that's what my client wanted and he's just so happy about his setup ...

If this looks like something that could help you out I can give you a few pointers on how to make such a program. Just say GO (no I won't post or give my au3 file - I'd have to translate it to english first and I just don't have any time or interest for the moment ...)

Thanks for the reply.

In the situation you describe that doesn't sound like an unreasonable solution. I'm not terribly familiar with XP, but I would have thought that it could have been achieved thru different logons and access permissions. I am interested in how you did it. I don't think my customers would like that. Except for the ones who are sadder but wiser, they mostly want an autologon with admin access.

Gene

[Celeri]

Thanks for the reply.

In the situation you describe that doesn't sound like an unreasonable solution. I'm not terribly familiar with XP, but I would have thought that it could have been achieved thru different logons and access permissions. I am interested in how you did it. I don't think my customers would like that. Except for the ones who are sadder but wiser, they mostly want an autologon with admin access.

Gene

No problem
I've gotten loads of help on this forum (yes, specially from Valik!) , the least I can do is help out others

Well basically my program is like so:

A password-protected program that is always accessible to the user (start menu) and toggles the protection.
Note if the account is not administrator, the protection cannot be toggled off (not my fault - windows prohibits a "user" account from writing to the registry keys the program uses)
Upon activation/deactivation of the protection, the program logs the user off and invites the user to log back on.

The protection is mainly activated by policies.
The policies are applied through the registry.

On any computer this program is installed I strongly insist there be at least one visible account with administrative rights (besides "administrator" that is). You don't want to lock yourself out of your own computer do you
So that takes care of power users - they have their password protected account, the policy laden account(s) are unprotected, hence, the place it's easier to go

Anything in All Users\Start Menu is moved, hidden or deleted (with caution!).
%user%\Start Menu of the protected accound is stripped down to the essentials - I hide nearly everything except useful shortcuts (i.e.: Word, IE, FireFox, WMP, Notepad, etc. etc.)

All unnecessary files/folders that can be browsed by user are hidden and controls to make them visibile disabled.

I even get rid of the right click on the desktop so no desktop shortcuts and no changing wallpaper or screensaver.

The only real bad side is that policies are slightly quirky. You need to do a lot of testing and poking around to get any solid protection. But in the end, this solution gets rid of a nice chunk of those "uh sorry didn't know "Format" deleted files".

For those who STILL manage to delete and destroy stuff ... I guess some have to learn the hard way ...

Keep us posted

Obi Wan Celeri

[Valik]

Gene, do you mind explaining for my sake and perhaps the sake of others who are just as puzzled, what exactly did I say or do in the first thread that was not civil? All I said was that I did not understand how your idea was supposed to solve the "problem"*. I also touched on a couple things which demonstrate that using your idea wasn't even necessary. How is that not being civil?

* I will remind you also that you accused me of fabricating the problem. However, you have gone on to provide examples of a problem which is identical to what I said.

[/dev/null]

I believe that most home PCs are not backed up. More over a large portion of PCs in small businesses that are backed up are not done daily or regularly. Most homes with PCs also have children, PCs at small businesses are subject to entertaining children when they can't be at daycare, school or where ever. Children are insatiable explorers and cannot resist tinkering. Some adults are the same.

When you are dealing with people at home or running small business you don't tell them how stupid they are for not securing their PCs from their children, at least not if you plan to continue doing business with them. So you try to think of ways to protect them from themselves. I've got other responses to answer, if I haven't answered you questions here, maybe I will there.

O.K. and what's your plan to prevent the children and small business owners from deleting the EXE with all your config data??? Do you really think children know the difference between an INI file and an EXE? Even if they knew, why should they only delete the INI files?

I'm sorry, but I really don't get it .... As Valik says, NOBODY "saves" config files back into the EXE because it's simply not a good idea.

Cheers
Kurt

[Richard Robertson]

I can see where you would want to do this but I don't see why you don't just do something like smack everything into one long binary file. I've been working on a Zip program that would allow multiple files kinda like WinZip etc. I could help you if you want.

[Confuzzled]

Self modifying code? I've only heard that recently in relation to viruses and other nasties.

Bad, bad idea.