Hi stuba81,
There is no real difference in how Win10 or Win7 execute bat scripts. The flashing scipt is actually very simple, it just launches some executables like md5 to verify checksums and fastboot.exe to get information about the device (to verify that the correct model is to be flashed, that the bootloader is unlocked, etc) and stores it in a temporary text file (if it can create it, otherwise it fails saying that it can’t find the… device). Then it simply executes fastboot.exe to flash all the needed files to the phone, one by one. That’s it.
The only problem is that the script lacks any paths, which apparently fools Windows (and quite possibly Linux too). If you launch the script not as Admin then it looks for everything in its own folder (as it should) but it fails miserably as it has no permissions to write the temp file there. On the contrary, if launched as Admin it does have the rights to make the temp file, but it no longer uses its own folder but Windows system folders or some folders in Windows’ PATH. It took hours before I realized that it was using not the fastboot.exe version that Jolla provides with the bat script in its own folder but it executed some other version it found in Android SDK’s platform-tools folder that I had installed somewhere else, because it was added to Windows PATH. Then it took some more hours to realize that it was making the temp file in Windows/System32 folder and that’s also where it was looking for all the SFOS files to flash and Android binaries, and obviously not finding them there it was always failing with a message that it could not find the DEVICE to flash (not the files!) which was completely misleading and confusing.
I fixed it by manually adding full absolute paths to all files in the bat script. But I guess the script could just as well simply by default contain relative paths (relative to the location of the script itself) which would be enough to make it work OK without any changes from the user side other than simply placing all the required files in the script’s folder, i.e how Jolla says it works (but it doesn’t). But the way it is now, i.e. just file names without any paths, causes what it causes.
Actually, there are lots of threads about problems with flashing. On both Windows and Linux.
Those are just examples I found within a few seconds, I could go on with links to such discussions for another half an hour. Which clearly shows that the flashing process is nowhere near what can be considered user-friendly or fool/newbie-proof and that many people do have serious problems with it.
A simple GUI program, either able to locate all the files by itself or letting the user chose using some simple requester, would definitely make the experience much better and the whole process much easier and more secure, especially for less tech-savvy users.
It is called PhoneHook, a call blocking application (there is an aarch64 version compiled for the X10 II on openrepos, too). I can’t believe that there is no such functionality on IOS. Blocking unwanted calls and texts is nowadays a must… Well, except that on Sailfish it is not, as the only such tool that existed got broken by sailjail.
The whole point is that I DO NOT WANT to go Android, of which the best example was that I wiped it off and installed SFOS instead. But I’ll clearly BE FORCED to go Android, with lack of any call blocking solutions, inability to use SFOS with my car kit and several other aforementioned issues. Installing Android support within Sailfish won’t solve them, either. If native apps can’t now access privileged data like Contacts then it is even less likely that Android apps can.