mboxviewer portable?

[Wolclaws]

This mboxviewer is great but would it be possible to make it portable as well? I believe it now saves the information inside the registry. Loaded on an external disk every time you access from a different PC you have to load everything from scratch. If it were possible it would be perfect!

[zigm]

You are correct that MBox Viewer relies on Registry for key information needed to start with the last state. Some time ago, another users asked for non Registry solution since he was not authorized to write to Registry as the standard user on corporate desktop.

I am currently porting MBox Viewer to UNICODE and that proved more time consuming task than I expected. UNICODE version should help to resolve some text (label, folder names, etc) related issues. I will investigate non registry solution once I complete port to UNICODE. Assuming I decide to support non Registry solution, I think solution is needed for MBox Viewer to learn location of the configuration file. User would need to pass the location as a command line argument or user would need to create Data Folder in the standard predefined location on the external drive. Data Folder would house configuration file and all other files created by MBox Viewer such as PDF files. Currently the Data Folder is configurable via dialog which might be the required step upon each startup. Currently user is required to configure the Data Folder during initial run only.

Currently there is no good solution to the issue you raised. If you manage to mount external drive with the same letter, you avoid doing everything from scratch the first time. Subsequent mounts with the same letter drive should not require any additional configuration effort unless you add new mbox files. Mounting external drive with the same letter is doable but not trivial.

[ChaosNicro]

Will the portable version use relative paths for data- and mbox-folders? I don't know how many path references there currently are, but that would allow for a portable folder containing the whole environment.

[zigm]

I did not forgot about the request and will consider once the port to Unicode is completed. Unfortunately I was busy with other things and the port to Unicode is not completed yet due to larger scope of changes to the code than I expected. It is getting close to the completion but not fully completed and tested yet.

Didn't investigated yet what is the solution for this request. Current MBox Viewer relies on Windows Registry and that would likely have to change. I suppose paths for the data and mbox-folders could be just relative to the local drive or user defined root folder. Assuming paths are relative to the local drive, the root folder would be just "/". MBox Viewer could detect such case if Mbox Viewer binary and data folder configured by the user reside on the same drive. If the root folder is defined by the user, user would have to specify the root folder and possibly root drive upon each startup of the MBox Viewer.

Will the the local drive solution work for you or are you looking for ability to have MBox Viewer binary, data folder and mbox-files to residing on separate drives?

[ChaosNicro]

That was my intention. My use-case is to keep a cold-storage backup on a removable drive. I wanted to include a viewer beside the backup, so that it would be easily viewable when plugged into an arbitrary host-system. This project seemed like the closest fit without including a full mail-client on the drive.

[ChaosNicro]

Considering having to redefine the folder paths each startup: Would you be very opposed to keeping a minimal ·cfg or ·ini file next to the two executables, that way you could load paths from a deterministic location. This could even be used similar to Mozillas profile approach, where the ini could hold multiple sets of paths. Where a command switch would select a profile alias and load paths defined in it's section. A user could then create a shortcut containing the switch, allowing for a multi-user environment. Potentially providing #21

[zigm]

I am not opposed to enhance MBox Viewer to support different use cases. Just want to make sure that it is easy to use for typical user. Currently user needs to configure Data Folder upon first startup and no more questions during the subsequent runs.

Obviously key here is the known location of the configuration, i.e windows registry, during subsequent runs. The registry is per user and multi-user environment is supported based on my testing. Also, user configured data folder is per user and protected by OSystem.

I suppose C:\Users\tata\AppData\Local folder could be used to store MBox Viewer default configuration files. User could configure other configuration locations but user would be responsible to provide the location via the command line argument or by the menu option after startup.

I am aware of some of the following requests from users, some are implemented and some are not:

1. Support for multi-users environment sharing mbox files and MBox Viewer files. Supported as far as I know.
2. Support for read only media such as CD/DVD or read only folder housing mbox folder and/or MBox Viewer release files. Supported already.
3. Support for file based configuration to enable running MBox Viewer on corporate PC with access to registry denied. One user had to login as Administrator to run MBox Viewer. Not supported, being considered for the next release, first Unicode version.

4. Support for configurable sessions across subset of different folders or possibly shared folders also. Not supported. This is one the latest requests but today I was not able to find the respective email for some reason. I will keep looking for the missing email.

   A user could then create a shortcut containing the switch, allowing for a multi-user environment.

I understand shortcut. Do you mean multi-sessions case instead of multi-user? and/or provide additional comment please.

I will get back to you once I completed port to Unicode and updated documentation,

I am porting MBox Viewer to Unicode to support Unicode searches and Gmail Unicode labels and to have an option to integrate Edge WebView2 library instead of current legacy MSHTML library in the future.

[ChaosNicro]

provide additional comment please

To reiterate: My suggestion is to place a "profiles.ini" next to mboxviewer(64).exe. On startup both of the executables would obtain their own program path and either open or create the profiles.ini in that location. You now have a deterministic storage path. It would then check the ini for a section equal to the current user-id and load or create it. In this section, key-value pairs store what you are currently using the registry for, replacing it. If the paths stored in the ini can now be relative to it's location (the program path), you have portability.

Consider profiles ini as such: [UserTom] Data-path="..\mbv-data\UserTom" Root-path="..\backups\UserTom" more settings for UserTom

[Betty] same for Betty

And consider folder structure as such:

• Mail-Backups
  • mboxviewer
    • mboxviewer.exe
    • mboxviewer64.exe
    • profiles.ini
  • backups
    • UserTom
  • mbv-data
    • UserTom

The folder Mail-Backups should now be portable. Users that want to share files can just set the same paths. A command-line switch could be used to explicitly select a profile section instead of going by username. Default behaviour would not be changed, since it still stores a separate config per-account.

[ChaosNicro]

To get the program path, store the output of https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea given NULL as the input.

Then you can pass it as a reference to the methods in stdlib, whenever you need to convert between absolute and relative paths.

[zigm]

Current MBoxViewer relies on _get_wpgmptr() to determine process path. But note the following:

When a program is run from the command interpreter (Cmd.exe), _pgmptr is automatically initialized to the full path of the executable file. When a program isn't run from the command line, _pgmptr might be initialized to the program name (the file's base name without the file name extension) or to a file name, relative path, or full path.

The description for GetModuleFileName doesn't refer to similar issues but who knows. It looks it might be safer to use GetModuleFileName instead of _get_wpgmptr() .

Thanks for additional comments with regard to the configuration. Obviously the process path is the known location and could be used to store the configuration files. User would need to be aware of that fact during potential upgrades to avoid loosing the configuration.

I will analyze the potential solution once the Unicode port is completed and get to you.