[Overview]

The e-book viewer may freeze during startup.

[Procedure]

1. Start the command prompt.
2. Make the directory where MelonDumper.dll does not exist the current directory.
3. Run Dll_Injector.exe.
4. Open the downloaded e-book file from Explorer.

[Expected behavior]

The e-book viewer starts and the clicked e-book is displayed. At the same time, the first displayed page is saved as an image file.

[Actual operation]

The e-book viewer window does not appear for a long time.
When I checked the task manager, the e-book viewer process was running.

[Reproducibility]

Will definitely reproduce.

[Investigation result]

When I examined the source file below, I found that the path name of the current directory was used when calculating the full path of MelonDumper.dll.

• Dll_Injector/common.h
• Dll_Injector/main.cpp

Therefore, if MelonDumper.dll does not exist in the current directory, it is speculated that an abnormality may occur in the injected code.

[Countermeasure plan]

In the current code, Dll_Injector.exe uses the path name of the current directory to find the full path to MelonDumper.dll.
I think it would be better to use the pathname of the directory where Dll_Injector.exe itself is located instead.

We can get the full path name of the currently running .exe file by calling the GetModuleFileName() WIn32 API as follows.

char exe_path[MAX_PATH];
GetModuleFileName(NULL, exe_path, sizeof(exe_path));

[problem]

Even if you open a book file in a viewer program after running Dll_Injector.exe, the image may not be saved.

[Steps to reproduce]

1. Run some applications in the background with high CPU load.
2. Start Dll_Injector.exe.
3. Start the viewer program.
4. Open the book file from a viewer program.

[Expected behavior]

The image of the book file is saved.

[Actual operation]

Images of book files are not saved.

[Reproducibility]

Occurs occasionally.

[Investigation result]

Dll_Injector.exe uses shared memory to pass the image storage folder to MelonDumper.dll.
Dll_Injector.exe was exiting without checking that MelonDumper.dll had read its contents from shared memory.
In reality, Dll_Injector.exe waits 1000 milliseconds after issuing CreateRemoteThread() before terminating the process. However, if MelonDumper.dll does not read the shared memory during that time, the shared memory will be freed first and MelonDumper.dll will fail to read the shared memory. In that case, MelonDumper.dll will not save the image file.

[Workaround]

I'm currently considering a way to allow Dll_Injector.exe to wait for injection to complete.
If the status of consideration changes, I will report again.

[Point of trouble]

According to the current specifications, the file name of the saved image file seems to have at least 3 digits.

When I save several book files containing hundreds of pages in succession, the cumulative number of saved images exceeds 1000, and for example, the following files are generated.

001.jpg
002.jpg
...
098.jpg
099.jpg
100.jpg
101.jpg
102.jpg
...
998.jpg
999.jpg
1000.jpg
1001.jpg
...

For example, most applications bundled with Windows (such as Explorer and Photo Viewer) compare consecutive numbers numerically, so they are displayed in the same order as described above. In this case, there is no problem since the images match the order in which they were saved.

However, some image viewer applications order filenames as just an array of characters.
In this case, for example, they will be displayed in the following order.

001.jpg
002.jpg
...
098.jpg
099.jpg
100.jpg
1000.jpg    <- NG!
1001.jpg    <- NG!
...         <- NG!
101.jpg
102.jpg
...
998.jpg
999.jpg

This is different from the order in which the images were saved, which is inconvenient when viewing them.

[Proposed solution]

The first thing I considered was changing the specification that "the number of digits in the file name must be at least 3 digits" to "4 digits or more" (or 5 digits or more).
However, some users may be dissatisfied with long file names under normal operation. Also, the question of how many digits in a number is sufficient depends on the user's operational method, so I think it would be better not to fix the number of digits in a number.

Currently, I am trying to change the code experimentally according to the following policy.

• Enable to specify the number of digits attached to the file name using the command argument of Dll_Injector.exe
• If no argument is specified, the number of digits will be 3.

If you adopt this approach, it is likely that code that uses shared memory will also be affected.

If the status of consideration changes, I will report again.

[Points that I find inconvenient]

When you start Dll_Injector.exe, a screen to select the folder to save the image will be displayed.
This screen always displays the Desktop folder initially. (For Windows 10)

However, I don't like images to be saved directly on the desktop, so I change them to a different folder (for example, My Picture\xxxxx) each time.
This is a somewhat tedious step.

[Solution]

I suggest that Dll_Injector.exe's command line arguments allow you to specify the initial location of the destination folder.

For example, if you want to save images to the folder "C:\Picture\Melon" every time, run the following command from a shortcut.

Dll_Injector.exe C:\Picture\Melon

[Supplement]

I experimentally modified the source code of Dll_Injector.exe to achieve the above objectives. With this change, Dll_Injector.exe behaved as I expected.
The changes in the source code are shown below. This is a very sloppy change as it is for experimental purposes, but please use it as a reference if you like.

Dll_Injector/main.cpp

  10: {
- 11:     std::string path = BrowseFolder();
+ 11:     std::string path = BrowseFolder(argc >= 2 ? argv[1] : "");
  12:     if (path == "")return EXIT_SUCCESS;

Dll_Injector/common.h

  25: 
- 26: string BrowseFolder()
+ 26: string BrowseFolder(const char* initialPath)
  27: {
  28:     TCHAR path[MAX_PATH];
  29: 
  30:     BROWSEINFO bi = { 0 };
  31:     bi.lpszTitle = ("Browse for save folder...");
  32:     bi.ulFlags = BIF_RETURNONLYFSDIRS | BIF_NEWDIALOGSTYLE;
+         bi.lParam = (LPARAM)initialPath;
  33:     bi.lpfn = BrowseCallbackProc;

as the title says, the version of this in the github release tab uses debug libraries (presumably because you couldnt build the release versions with VS—i know i couldnt). it doesnt run unless you have the c++ environment workload installed in VS, as seen here. this error message pops up when you try running it without the c++ stuff installed, and is also succeeded by like 2 other ones that are clearly c++ debug dlls.

but it doesnt even run properly even once you have vs installed. whenever i try to open the melonbooks viewer it gives me this pop-up

despite the console window telling me "DLL successfully injected :)"

this probably ought to be two issues at once but the fact of the matter is i cant get it to work at all, even with two different books