I used to use PortableApps software a while back and enjoyed the flexibility it gave. Over the past couple weeks I have been doing a lot of computer fix ups and needed a solution with portable applications.
I needed a few of my own programs to be portable as well as some freeware programs. I was looking through here at how it was done but I already had some ideas in my head. I actually program in Delphi(I was happy when I saw PortableApps was coded in the same thing) and was wondering why API hooks were never done in the process of making applications portable(I might have missed exactly how it was done here, skimmed through the template).
Windows API such as RegOpenKey() RegOpenKeyEx() RegSetValue() RegSetValueEx() LoadLibrary() can be caught before they are sent to windows. Hooking them will there by make your own "mini-registry" for each program.
I was just wondering why applications aren't make like this because they can be turned into single files with no need for anything else.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
The PortableApps.com Menu is actually the only thing coded in Delphi. Even so, if that works, the menu could set it, and then programs launched while the menu is running could use it, but we would still have to accommodate for those not using the menu, as the launchers for the applications are coded in NSIS.
I hope I'm understanding correctly, it sounds cool to me.
I understand that the menu is the only thing coded in Delphi. What I am proposing is that the applications that are made portable can be made into a single executable instead of multiple folders for it.
This way the menu can create it's own registry that the applications can use, since the windows registry is just files as well. Everything can be emulated, in this fashion the PortableApps menu will be like it's own mini windows because all the API that the applications that are made portable are being redirected to the menu
That's basically what I understood. The one big problem is that many people to not use the menu and we would therefore have to have an alternative route. It does sound quite awesome however.
The menu isn't required, it's optional. The executables that are being made portable will check it the menu is running; if not, they will do the same thing on their own level.
Sorry, still not following fully. This would mean the applications are still developed in NSIS, or would have to be switched to Delphi?
They wouldn't be developed in NSIS or Delphi. There would be an application that takes the application and it's files the application and wraps it.
Let me show you an example(This would be an "as hard as it could get example"):
Autocad 2008:
When installed it has the main executable and files(dll's other files to make the program work) and files it puts in the windows system folder and registry entries.
The easiest way to track all of this would be to have the Portable Program Maker(PPM) run with it and track exactly what happens with File Creation hooks and registry hooks.
It records everything done and once the installation is complete it shows you what has happened. You then can choose what is needed and not needed. The needed stuff is then compressed and put into a single executable.
Now, when this new portable program is run, a dll is run with it. When the original program is looking for a certain file(We know this with API hooks) we extract it out of the executable and point it to the file we have instead of the one it thinks is on the disk.
Of course this is all null if the program doesn't need to be installed and in that case there can be an option for that as well.
This sounds amazingly like "Thinstall",
or shouldn't I mention that
Tim
Things have got to get better, they can't get worse, or can they?
Now I finally understand (I think :P). Haha, I'm with Tim.
But umm, it does sound new and interesting. We'll see what John thinks. It's a pretty massive change and may have some issues.
It's supposed to sound amazingly like Thinstall but much less expensive and easier to use.
And on the point of it having to change anything: The menu doesn't have to be changed at all, it would help; but doesn't have to be. The new system can be program only.
Reason I'm pointing all this out is because things can be made easier and more efficient. I only know this is possible because I done similar things in hooking and Process from memory(no hard disk).
What about %appdata%? Not all programs support redirecting it...
Insert original signature here with Greasemonkey Script.
You may want to check out JauntePE - http://portablefreeware.com/forums/viewforum.php?f=10.
Not really what I had in mind at all. My idea was to have a virtual windows(VW) surrounding the PAM or each Portable App. This VW will be complete with it's own API thanks to api redirection and it's own registry.
JauntePE can do that. And Ryan McCue is working on an open source hooking thing for it (its MadHook.dll is closed source) and then the author (Reddlar) may make it open source.
See https://portableapps.com/node/7707 for the most recent discussion of it.
I was at school and no one had replied when I saw this - I thought, "Ah hah! JauntePE to a tee!"
Dagenham: thanks for suggesting it!
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
MadHook as in madshi Code Hooking? No, that will never be open source. Plus, there are already hooking thing that are open source.
Right. Hooking the API is hooking the API, and madshi's is one way to do it. I understand he has a very good reason for not making it more widely available -- it is too easy to misuse.
If you want to see how a more commercial program does it, look at Mojopac. Thinstall is another.
API hooking is not something for novice programmers to do. I wouldn't be surprised if it could be done in Delphi. Most think in terms of C or perhaps Assembler.
Coming up with an Open Source way to do it would be ideal, as long as it didn't give the script kiddies ideas for messing with other people's computers.
MC
fyi Madshi's codehook was made in delphi.
I've used Thinstall and am disappointment in its hardness of use..I already have delphi hooking code that is partly mine, partly madshi's. The plan was not to have the code itself be open source but a application that bundles the portable apps. The nitty gritty that can be misused can be put elsewhere besides somewhere where people can see it.
The plan was not to have the code itself be open source but a application that bundles the portable apps. The nitty gritty that can be misused can be put elsewhere besides somewhere where people can see it.
Using Closed Source Software to make Open Source Software where people can't see how to do it themselves? Has a strange taste to it
Tim
Things have got to get better, they can't get worse, or can they?
Yes, but this isn't a portable app, it's an app to make a portable app. Everything will be open source except the hooking code. Even that can be open source if you really want it to be.
Thieving,
I think it would have to be open source if we were to use it.
And I'm pretty sure we couldn't do it with our Flag Ship Mozilla Products.
Tim
Things have got to get better, they can't get worse, or can they?
Why wouldn't it work?
The precedence on how it works is simple: All programs use WinAPI to complish tasks having to do with Windows. The registry, for example, is just a file on your hard drive.
My idea comes in where you have the programs that are made portable all being hooked to have things like the registry not go to the real Windows.
Example:
Portable App A Runs and starts writing to the registry.
The hooks catches this and writes it to its own file called PortableAppA.preg.
If the App A starts reading from the registry it will be given information gotten from PortableAppA.preg.
Sorry
I meant "couldn't" as in "Not Allowed To".
Not "couldn't" in the "Technical" sense.
That's why I mentioned them as our "Mozilla" Flagship Products.
Tim
Things have got to get better, they can't get worse, or can they?
I don't think he was saying there would be functionality issues. I think Tim meant legality issues. Bundling open source software with a closed source product often isn't legally feasible.
The developer formerly known as ZGitRDun8705
"Bundling open source software with a closed source product often isn't legally feasible."
Why is it illegal. I might be missing something but I don't see why it would be.
It could break the terms of the license. For example, under the GPL, any derivative works must also be under the GPL. Repackaging, or wrapping with a closed component violates this.
The developer formerly known as ZGitRDun8705
Ok, I think I am missing something. Firefox is close sourced is what your saying?
[edit by Mod Tim]
Replies should pick up here:
https://portableapps.com/node/13623#comment-83965
This space is getting too tight
ThievingSix, Just to let you know I am working on my own alternative of application hooking and it's based off the idea of JauntePE and Steve Lamertons Lapwing, I was wondering are you interested in working on the project with me
your friendly neighbourhood moderator Zach Thibeau
I am actually. My idea right now for me is a portable windows shell that I am starting on.
Well lets put it this way
I'll help you if you help me 
just let me know your answer 
"You scratch my back and I'll scratch yours"
your friendly neighbourhood moderator Zach Thibeau
Fine with me, what kind of help will you be needing?
email me at thibeaz_-([at])-_gmail_-([dot])com and I'll let you know
your friendly neighbourhood moderator Zach Thibeau
This is a SHIFT TO THE LEFT
of the conversation
from:
https://portableapps.com/node/13623#comment-83962
"Ok, I think I am missing"
It's getting too tight over there.
No FireFox is not Closed Source but we can't repackage it with a Closed Source App.
[Additionally FF has very strict trademark issues that give them a lot of control over anything "called" Firefox"]
Tim
Things have got to get better, they can't get worse, or can they?
So if it's made with an open source application that is wrapped around it is there a problem?
*Thanks god for the shift to the left*
That is why I said:
[Additionally FF has very strict trademark issues that give them a lot of control over anything "called" Firefox"]
Same applies for Thunderbird by the way.
Tim
Things have got to get better, they can't get worse, or can they?
So how is the current FFPorable going along fine?
(Take that as a question, not a smart ass remark please =P)
John has special permission to package FF as a Portable program and still use the FireFox name. And even that has limitations
Things have got to get better, they can't get worse, or can they?
Ahh, I see. What kind of limitations? And how hard would that be just to transfer the permissions to a different type of Portability. Lastly, we can just not apply this technique to FF at all.
Don't want to be rude but I am going to cut this short soon, so if I don't answer your next reply I'm sure someone else will pick this up.
What kind of limitations?
See:
https://portableapps.com/support/firefox_portable#modifications
for some of the modifications that have been made with Mozilla's permission.
Currently we have a problem with the AutoUpdate Check for updates. We are not allowed to turn it off.
how hard would that be just to transfer the permissions to a different type of Portability
That question is beyond me.
Lastly, we can just not apply this technique to FF at all.
Again, that question is beyond me.
Things have got to get better, they can't get worse, or can they?
I do thank you for explaining everything to me. Hopefully we can proceed with this on some level but not now at least.
I'm currently writing a virtual registry program, using madshi. So far I've setup hooks for nearly all the registry calls (there are a LOT!). Then I'm going to test it with the first program I want to be portable (cMud or zMud in this case), see which calls it's making, and program them first. Interesting project (far more advanced than anything else I've done!!!)
A few clarifications might be in order:
Mostly, it is a matter of details (and the devil that is in them). I think there are legal ways of creating a portable environment that uses hooking. I would be delighted to see it happen. There are several details that might make it difficult to happen on this site, but that is not to say that it is a bad idea, or that this is a bad site.
MC
BoxedApp SDK (founded at here link to sdk web-site ) could be used to make probably almost any application portable, if you can modify source code of course. It's for developers... For example, you can register embedded DLLs in a virtual registry, ActiveX, I mean. Even .NET runtime can be embedded. It seems that even 64 bit system is supported, but I haven't tested it yet. There are a few examples for Delphi.
I think, with this SDK it's possible to create a sandbox, in which you launch an installer, all changes are saved in virtual environment ("registry" and "file system")... Not sure, but I hope
And the cost is only 300 euros.
MC
I've done a lot with hooking, first with madshi, then with my own hooking functions and wanted to make applications portable with this in a different sense. More a long the lines of a portable windows shell if you get my drift.