[quote=297369:@Stuart Sykes]
As you can see all the files have been installed correctly…
[/quote]
just notice you do not have the libs and resources file folder with PasswordID.exe
Innosetup script seems to put all the files (including the ones in Libs, Resources and x86) into one folder called PasswordID inside the Program Files folder.
Iv’e installed Service Pack 1 and still no luck running either Xojo or my App in Windows 7
OK Just moved the Libs & Resources file folders manually into the Program Files/PasswordID folder
WORKING 
- Why did Innosetup not put the Libs & Resources into separate folders?
Not by itself, it doesnt.
Its this line that is doing that:
Source: “C:\Users\Stuart\Desktop\PasswordID\PasswordID Resources\*”; DestDir: “{app}”;
First, you need this:
Source: “C:\Users\Stuart\Desktop\PasswordID\PasswordID Resources\*”; DestDir: “{app}\PasswordID Resources”;
And you need to get that Microsoft DLL next to the app so that it can see it.
Thanks Jeff - All done and working with a good Innosetup script
Oh…And service Pack 1 for Windows 7 is definately required as minimum.
Xojo 2016r3 still not working on Windows 7 (32 bit) with Service Pack 1 installed
Iv’e restarted Windows 7 and re-installed the app twice.
Here’s the error message:
I HOPE THE XOJO HAVE PUT THE DLL IN THE RIGHT PLACE
Put all the DLLs in the frist folder where the xojo.exe is, no subfolder. Or just install the vcredist86
[quote=297437:@Stuart Sykes]Xojo 2016r3 still not working on Windows 7 (32 bit) with Service Pack 1 installed
Iv’e restarted Windows 7 and re-installed the app twice.
Here’s the error message:
I HOPE THE XOJO HAVE PUT THE DLL IN THE RIGHT PLACE
[/quote]
It seems like they didn’t put them in the right place.
I found the runtime files deep here:
Program Files/Xojo/Xojo 2016r3/Extras/Windows Runtime/Files/x86
They should have been here:
Program Files/Xojo/Xojo 2016r3/
Come on Xojo - Pull yer finger out
[quote=297437:@Stuart Sykes]Xojo 2016r3 still not working on Windows 7 (32 bit) with Service Pack 1 installed
Iv’e restarted Windows 7 and re-installed the app twice.
Here’s the error message:
I HOPE THE XOJO HAVE PUT THE DLL IN THE RIGHT PLACE
[/quote]
I gave you the precise location where to find the DLL only six hours ago 
[quote=297356:@Michel Bujardet]I told you in the other thread that it was indeed probably a problem of vc reditstribuable, as described in the document /Documents/WindowsUniversalRuntime.pdf
The file your program asks for is in
/Applications/Xojo 2016 Release 3/Extras/Windows Runtime/Files/x86/[/quote]
No Michel - Xojo’s installation of there own app is wrong as well.
They havn’t put their runtime DLL’s in the right place on their installer for Xojo 2016r3 (Windows 32 bit)
Its good to know I’m not the only one who gets it wrong
We use the runtime installer rather than the DLLs next to the executable for several reasons- one because there are support compilation executables throughout the installation in other directories that also require the runtime. It isn’t “wrong”- it’s the recommended option by Microsoft- and for Xojo itself- it is required. But it does require Windows 7 SP1 baseline updates to be present when you install Xojo it for it to work.
You may need to uninstall Xojo & all dependencies (including the MS C Runtime)
Then reboot Windows
Then reinstall Xojo
There’s something about having the dlls installed before you update to SP 1 that makes things not work so you have to redo the installation
OK I’ll try un-installing, rebooting and re-installing Xojo again because even though Iv’e got Xojo running now by COPYING the DLL’s to the side of the main executable Xojo won’t RUN my project. (api.ms-win-crt-runtime-l1-1-o.dll is missing)
Where does Xojo run the project? And do the DLL’s need to be there as well?
It may be enough to put api.ms-win-crt-runtime-l1-1-o.dll into ‘the path’
eg if you can get it into Windows subfolders with other DLLs, any app should be able to find it,
Xojo compiles your app in windows to a temporary folder.
You could also add a post-build step to copy the dll to that folder path.
(And yeah… this is one reason why Im not using 2016 edition)
I bet because Windows 7 did not have the service pack installed, Xojo install was not able to install the VC runtime, and that is the reason why DLLs are missing.
Indeed just uninstall Xojo and do a new, clean install.
Or consider dropping antiquated systems in favor of current, state of the art Windows 10. Is it not strange to systematically keep older systems on Windows, while embracing the latest ones on Mac ?
[quote=297514:@Michel Bujardet]I bet because Windows 7 did not have the service pack installed, Xojo install was not able to install the VC runtime, and that is the reason why DLLs are missing.
Indeed just uninstall Xojo and do a new, clean install.
Or consider dropping antiquated systems in favor of current, state of the art Windows 10. Is it not strange to systematically keep older systems on Windows, while embracing the latest ones on Mac ?[/quote]
I think you’ll find that there are still many many many Windows 7 users out there Michel
There are, but the ones that don’t run system updates shouldn’t really be allowed to complain when they’re missing critical parts. That’s unfortunately not the way it works when they’re the customer though.
I am not saying users. I believe a serious developer should not indulge in obsolete systems. But hey, it is your business. And probably why you are stuck.
I develop engineering applications for internal use at my company, and we are required to use Windows 7.
This entire situation is sad. One of the reasons I chose to use Xojo was to avoid DLL conflicts. Now I have to worry about installing a runtime that may not work if Windows is not up to date. I would prefer to have a single exe and not have all the security updates.
You can thank MS for DLL conflicts
We do the best we can to make it so they don’t / wont exist - but we cant fix everything
Like requiring that in order to use the MS supplied DLL’s you have to be on Windows 7 SP 1 - thats an MS requirement - not ours
If we want to use a relatively modern version of Visual Studio to build the frameworks then this DLL requirement is one thrust upon us. And we do want to use modern tools so they give us a lot more like better compiler checks & language conformance which means we make better & safer code.
Single exe’s that “link in” dlls are a fantasy.
To not use DLL’s we’d have to require vendors like Einhugur and MBS use specific versions of tools (like Xcode, GCC, and Visual Studio) to be able to create plugins that could be linked in - they’d have to give us linkable object files.
And thats not likely to ever occur
So we make the best of it we can