Extending the concept of portable.

Discuss anything related to portable freeware here.
Post Reply
Message
Author
sgbotsford
Posts: 2
Joined: Sat Dec 01, 2007 7:06 pm

Extending the concept of portable.

#1 Post by sgbotsford »

I found this collection, and many thanks to Andrew for making this site public.

I have a slightly different problem: I'm sysadmin at a boarding school. Because this is the boys home as well as their school, the computers get used for recreation as well as school stuff.

I've been looking for games that can be installed and run from a network share. I can then make that share readable after school is out.[1] Many of these look to be ideal, except for the 'settings written to application folder' Ug. I never let users have write access to program folders on my servers. It would also mean they would stomp on each other all the time.

All my users map a server folder of their own to H:\.

Anyone have a general method for discovery and redirection of settings to their own folder? (E.g. For normal thunderbird the process is to delete the default profile, create a new profile, which gives you the choice of where to put it. I enter H:\tbird, and let the otherstuff remain the same.)

Also, is there a general term for this kind of 'portable'?

(As a side light: If anyone can recommend good non-portable (can write some stuff to registry, can have some local DLL's) that can run from a network share, drop me a private email -- as I consider it to be off topic for this forum)

[1] There are ways to subvert this:
a. Student copies it to part of the local disk that is writable by him. Doesn't help. All comptuers are reinstalled every night.
b. Student can copy it to their own home directory.
Doesn't help. A housekeeping program has a list of stuff to chuck from user's directories.
c. Student can copy it to a memory stick.
Has to be a really small game. Lab computers have USB 1 connections.
Can we say 'yawn'
d. Student can search for the game online, download it everytime he wants to play. Would work.

HexMaster
Posts: 1
Joined: Sun Dec 02, 2007 1:19 am

Use WinRAR

#2 Post by HexMaster »

Yes, most portable games will write to their "Application Folder". This doesn't necessarily have to be a problem, unless you want to save game settings/scores/etc:

You can use a WinRAR SFX...

1) Right click the game folder, and select "Add to archive...".
2) Check "Create SFX Archive".
3) Select whatever compression options suit you.
4) Go to the "Advanced" tab.
5) Click "SFX Options".
6) Select "Create in the current folder".
7) Set "Run after extraction" to the game .exe
8) "Modes" tab.
9) Check "Unpack to temporary folder".
10) "Hide all" under "Silent mode".
11) Your choice under "Overwrite mode".
12) "Text and icon" tab.
13) You can set a custom icon to be displayed for the final .exe, here. Use reshack or some other resource viewer/editor to extract an .ico file from .dll and .exe files.
14) "Ok" everything.

The result will be a self-extracting .exe which will extract the game to a folder in the current user's "Temp" folder and run it. The SFX will delete that folder once the game is exited.

I did this with Crazy Taxi PC (~100MB), and others.

M@tty
Posts: 192
Joined: Wed May 02, 2007 9:32 am
Contact:

#3 Post by M@tty »

For some programs, the ones written to use relative paths anyway, launching the program with a different working directory will have the result of writing to the new folder.

In Windows Explorer, when you launch a program it uses its current directory as the working directory. If you make a launcher for the program and have it set the working directory to the directory the launcher exists in, rather than the directory the program exists in, this will have the desired effect.

In NSIS you do this with: SetOutPath $EXEDIR

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#4 Post by redllar »

As M@tty said, some apps written with portability in mind will use the current working directory as the user-specific data "home" directory. Along with M@tty's suggestion, and if the networked apps are always mapped to the same way by each user, I'd suggest creating one shortcut that each user uses to access a given app, specifying some H: directory as the "Start In".

If the working directory approach doesn't work, I tried this a while back on several of my own portable apps using JauntePE (JPE) and it did the job automatically and without needing to know whether the app used the working directory vs the app directory to store its user data in, with a couple of minor irritations/bugs. I have a newer version of JPE that I hope to release soon that gets rid of the problems.

The one-time steps required would be to:

1) if you want a generic icon app launcher, create an app launcher via JPE,

2) create a JPE control file that tells the JPE runtime to redirect any file system modifications made in the app's directory to somewhere on the H: drive,

3) place the JPE control file and JPE runtime dll somewhere on the network share (and that is also accessible by the app launchers),

The per-app steps required would be to:

1) if you want an app launcher with a different icon for each "JPEized" app, create an app launcher via JPE,

2) rename the app's main executable with a .jpe file extension to prevent accidental running,

3) place a copy of the JPE-created generic, or app specific, app launcher as a replacement for the app's main executable.

The JPE control file would look something like the following:

Code: Select all

[Filesystem]
Data=H:\GameData\%appname%

[FilesystemExclude]
1=*

[FilesystemInclude]
1=.\

[SpecialFolder]
.\=.\
You can try this out now with the current public version of JPE except:

1) the [FilesystemInclude]1= path must be a full path,

2) the redirected game files might not be complete, as there is a bug in the JPE runtime whereby certain file system api calls do not cause the "to-be-redirected" file to initially get copied over to its redirected file system equivalent path.

3) the redirected files go into an "Unknown" subdirectory of the [Filesystem]Data= directory instead of one specified via the [SpecialFolder] section.

4) You cannot rename an app's main executable with a .jpe extension. It must remain the same name.

5) You cannot rename the JPE-created app launcher without the _portable filename suffix it was created with. It must remain the same name.

Post Reply