Writing a non-portable app converter: need apps to test with

[Kermode]

All we need is some mechanism (an ini inclusion list?) to specify what additional directories we want redirected for that particular app.

Yep, gets my vote

[dyce]

redllar, you are doing a very great job. your program is almost like thinstall, except the comercial stuff about it. the next thing you may also want to do is remove the need for dependencies, if the app looks for something in the windows directory, it will look in its directory, and all the dlls will be there that it needs. but one question, does this all work on guest accounts? does your app actually write to the registry? because guest accounts deny access to registry.

Thanks for the kind words and the thoughts about dll dependencies. I would hope that running the app's setup via PP would get you all of the "special" dlls put into the app's directory, but there definitely could be others missing that the app dev assumes are there (I know I assume the user will go download gdiplus for 2K use, for instance.)

I don't know if this all works on guest accounts. Another good thing to try out. Neither the PP exe nor the dll write to the registry. And the dll does not allow any app-requested registry write or delete (that it sees) to be processed as such. But I have noticed during log reviews that a very few key handles show up that the PP dll did not create, meaning that there's some internal Windows system dll registry accesses going on that the PP dll does not see. It's possible that those keys are used to modify the registry.

it will work fine on a guest account as long as portapotty doesnt require writing to the registry.

[redllar]

Just a quick note to say there won't be a new version for a few days. Last night I ran into a couple of technical snags when testing some InnoSetup setups and other apps that kick off child processes. I finally worked out a reasonable solution to the problems but I don't have time to finish up the testing, and of course the weekend's here so it's time to take a break from this. :)

I'll upload a new version sometime early next week, assuming no other snags crop up when I get back to the testing.

[redllar]

Hey all,

The redirection of the file system is testing well, but there's a usage issue that I want to bring up and discuss to make sure the way it's working sounds reasonable.

What's happening is the PP-run apps are showing the paths for their directories and files as the real system paths, not the redirected equivalents. So the PP-run apps are giving the impression that you're accessing "C:\Program Files\WikidPad\readme_Wic.txt" or "C:\Documents and Settings\username\Desktop", for instance, when in fact you're being redirected into the portablized file system. In other words, you're really accessing "E:\Portables\Program Files\WikidPad\readme_Wic.txt" or "E:\Portables\Documents and Settings\username\Desktop".

I have to say that even for me and all of the testing I've done so far, it's a bit unnerving to see these directory names pop up. The apps have thus far always only modified the redirected file system, not the real system directories and files. But I always end up starting a non-PP run file browser app to check that no real system directories or files were messed with. And not just because I'm testing. I would be doing this as an end user as well. I think it's because, unlike the registry redirection, you see the path the app is using.

So what do you think? Is this good enough as it stands and just requires some getting used to, or should I burn some time now and look into trying to get the app to use the redirected directory and file names at all times? Or do I need to explain this better before you can decide?

[portable-freak]

It really sounds good redllar, where is the download link?
Fair enough mate, I personally really don't mind, I mean as long as the real system files remain untouched, it's quite superb
Thanks for the efforts once again!

[Kermode]

Hm... as long as it doesn't redirect what it shouldn't redirect...

[Andrew Lee]

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?

Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

If so, that would be a little tricky...

[portable-freak]

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?
Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

The way I understand what redllar wrote, it seems to me pretty logical.
You're accessing a file in C:\ABC\MyDoc.XYZ using a PP-run application, the edited file will be converted to E:\Portables\ABC\MyDoc.XYZ as this is the way it is meant to work, isn't it?
If I run a portable application, I want to have a sort of packaged environment and that's the purpose for me.

So what do you think? Is this good enough as it stands and just requires some getting used to, or should I burn some time now and look into trying to get the app to use the redirected directory and file names at all times? Or do I need to explain this better before you can decide?

You most likely mean PP-run app, am I right?

[Kermode]

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?
Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

The way I understand what redllar wrote, it seems to me pretty logical.
You're accessing a file in C:\ABC\MyDoc.XYZ using a PP-run application, the edited file will be converted to E:\Portables\ABC\MyDoc.XYZ as this is the way it is meant to work, isn't it?
If I run a portable application, I want to have a sort of packaged environment and that's the purpose for me.

Well I dare say is not the purpose for most of us, the purpose is to make it *portable*

Ie, if I use a text editor it should be able to start up from a given folder, and all the files and data it requires to run should be launchable from that folder, BUT if I save a document I want and need to be able to save it to any path i choose without having it redirected.

[redllar]

It really sounds good redllar, where is the download link? :P
Fair enough mate, I personally really don't mind, I mean as long as the real system files remain untouched, it's quite superb :)
Thanks for the efforts once again!

I'm still testing and making a few tweaks as I find apps that are using file system apis I haven't redirected yet, so no download yet.

As far as I've been able to tell, no obvious system directory changes are made, except in ones that aren't being tracked, like Documents and Settings\username\Local Settings\Temp.

[redllar]

Hm... as long as it doesn't redirect what it shouldn't redirect...

I don't think it is. It only redirects changes to "system directories", which I'm defining as the list I previously posted. Mostly it's directories that are normally found in Documents and Settings. Directories like username\Desktop, username\Start Menu, etc.

[redllar]

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?

Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

If so, that would be a little tricky...

Right now, if C:\ABC is a "known system directory" (see my list from a previous post) then yes, it will, if the file is to be changed, which means that the app opens it with write or delete access. If the file is only opened for reading purposes, then the path is left alone and the app opens the real file. If it then attempts to overwrite it, the path is changed and the new version of the file is written to the redirected directory. If the file is then ever re-opened, even for reading purposes only, the path is modified since a redirected version of that file exists.

Also right now, if C:\ABC is just a regular user directory, no redirection occurs. Eventually I'll add an inclusion list which will allow us to say "treat C:\ABC as a known system directory," which means access to it would then be redirected as well.

[redllar]

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?
Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

The way I understand what redllar wrote, it seems to me pretty logical.
You're accessing a file in C:\ABC\MyDoc.XYZ using a PP-run application, the edited file will be converted to E:\Portables\ABC\MyDoc.XYZ as this is the way it is meant to work, isn't it?
If I run a portable application, I want to have a sort of packaged environment and that's the purpose for me.

Not if C:\ABC is a normal user directory. Please see my post above.

So what do you think? Is this good enough as it stands and just requires some getting used to, or should I burn some time now and look into trying to get the app to use the redirected directory and file names at all times? Or do I need to explain this better before you can decide?

You most likely mean PP-run app, am I right?

Yes. Thanks for catching that.

[redllar]

What if I want to access a file that is a real path eg. C:\ABC\MyDoc.XYZ?
Would that be silently converted to E:\Portables\ABC\MyDoc.XYZ?

The way I understand what redllar wrote, it seems to me pretty logical.
You're accessing a file in C:\ABC\MyDoc.XYZ using a PP-run application, the edited file will be converted to E:\Portables\ABC\MyDoc.XYZ as this is the way it is meant to work, isn't it?
If I run a portable application, I want to have a sort of packaged environment and that's the purpose for me.

Well I dare say is not the purpose for most of us, the purpose is to make it *portable*

Ie, if I use a text editor it should be able to start up from a given folder, and all the files and data it requires to run should be launchable from that folder, BUT if I save a document I want and need to be able to save it to any path i choose without having it redirected.

I'm shooting for what you're suggesting, but there's a catch here; the apps that PP should be used with aren't always portable with regards to file sytem use. In other words, the app is hard-coded to read and write data to %userprofile% or some other non-portable directory. So PP redirects those accesses to a directory that is portable. But in doing so it has to redirect all of the app's changes, since it doesn't really know what the app is doing when it asks the system to open a file for write access in %userprofile%. PP doesn't know whether the file is an app config file or an app "user data" file. Maybe later we can "teach" PP to get smart about these sorts of things. But for now the limitation will be to not store your user data anywhere in one of the "known system directories."

[portable-freak]

Just to narrow it down one bit, "packaged environment" might have sounded a little clumsy as it were ...
I am not saying that every single application should run independently from the operating system. I am pretty aware that this would be hardly possible to achieve.
Nevertheless, a purpose of mine or a purpose of yours .... it's still great to have an application like this made by one person, hat off