Issue with 2016R1

Right. But they are only needed if using the Redistributable Installer is not an option for you.

I just heard in the build conference the complete Visual Studio uses about 750,000 registry entries ; approximately 30 Megs dword and strings…

Then one wonders why Windows slows down with age …

To be honest, Windows users should be fairly used to having to run redistributables - such have been a part of Windows for yonks, VB runtimes, C runtimes, .net frameworks of endless variety and versions, required service packs too. Drives you dilly, but, as they say in France, say lar vee.

That is 450x more memory just to store configuration data, than the entire MBASIC interpeter, operating system, application and data used to require! I can’t imagine 1000 items that would need to be tracked for VS, let alone 3/4 of a million

[quote=258192:@Michel Bujardet]I just heard in the build conference the complete Visual Studio uses about 750,000 registry entries ; approximately 30 Megs dword and strings…

Then one wonders why Windows slows down with age …[/quote]

"The “a big Registry slows down Win” Myth. :wink:

With the machines we use today and since a few years, a few hundred thousand more or less Registry Values making no difference in performance…

I think you meant

In my situation I can count on the Windows 7 being installed but I can’t count on the systems being up to date and installers are not a realistic option…

Let me ask this… If I put those files next to the executable, AND the system has been updated, will the ones in the app folder get used or will the system installed ones get used?

Even if a system does not have them at first, it may get updated and so have a newer version added to the system in in the future … It seems to me using the latest one would be best…

  • Karen

But with an Afrikaans accent. :wink:

The ones in the App Folder

The ones in the app folder get used. That’s actually why MS recommends using Windows Update and/or an installer wherever possible- because those are then updated (including security updates) by Windows Update going forward. If you go with the app-local approach, that copy is always used as-is.

i try putting in the window/system folder and it work. i add another folder called runtime and move those files into the new folder and it does not work.

for some reason the installer include does not finish every single time on window 7

Hi all.

From my side, Impossible to work using 2016 r1
I use Xojo under Windows 10, 64bits
My project stops itself for any reason.
I return on 2015 r4.1, and it works. Lets say, i can work on my project.

Result, i can’t use 2016 r1.
I’m very disappointed.

[quote=258276:@Richard Duke]i try putting in the window/system folder and it work. i add another folder called runtime and move those files into the new folder and it does not work.

for some reason the installer include does not finish every single time on window 7[/quote]

never mind. got the installer to work after rebooting on window 7.

I have copied all the dll files to my Libs folder. Now, when I run my application under VM I get the following error:

The procedure entry point ucrtbase.terminate could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll.

How do I get the program to run in VM?

Are u sure you copied the correct Libs (32/64Bit)?

Ah, could be that. I’ll try again.

I copied the x86 files. My app is a 32 bit app, not 64 bit.

Same problem.

That’s not the right place for them. If you are going that route they must be next to the executable:

“Just copy the DLL files from the appropriate folder to the same directory as your app executable. Do not put them in the Libs folder.”

[quote=258396:@Travis Hill]That’s not the right place for them. If you are going that route they must be next to the executable:

“Just copy the DLL files from the appropriate folder to the same directory as your app executable. Do not put them in the Libs folder.”[/quote]

Gosh! @Travis nailed it. I am sure :slight_smile:

Thank you, Travis, that works.

However, that means that the program is lost amongst the dll files and just does not look right. But, I hope it will run properly on a real Windows machine…