Icuuin.dll, icuuc.dll missing from system

General
1

I’m updating one of my programs to run on some new servers. On the older windows 2016 servers I get runtime errors:
… icuin.dll, icuuc.dll is missing from your computer…
I tried adding these libraries in a couple of different places but to no avail.

uSoft say’s it’s for unicode - something I don’t need. Is there any way to have XOJO not try to use unicode when compiling? I’m using the latest release. 2025r1

These servers will eventually be replaced … but I thought I’d ask to see if anyone has any ideas.

Thanks,
Ben

2

You need to update the server or go back to a previous Xojo version.
Here is the relevant information from the release notes:

  • Windows: We now use the built-in ICU libraries on Windows. The updated build requirements are now: Windows Server 2019 (build 1809 or later), Windows 10 (version 1703 or later), or Windows 11. (73190)

Edit: from latest requirements see here.

2 Likes
3

Thank you Alerto D - Appreciate it.

4

Does “Build requirement” also mean “Application execution requirement”? For instance, does a compiled Windows R2025R1 application run on Windows 8.1? If so, which version of the ICU .dlls is linked?

5

Where do you see these “Build requirement”?

No. You can read the last link I posted. The IDE requires Windows 10 (build 1903+) or Windows 11 the same for desktop apps build by Xojo 2025r1

image
image1386×434 30.2 KB

6

Thanks, AlbertoD, for the clarification.
“updated build requirements” was in your earlier post. I now know this also means “updated app execution requirements”.
Windows 10 1903 was released in May 2019 - 6 years ago. This is about the half-life of a Windows PC according to Google.

1 Like
7

One thing I’d like to see from the Xojo framework would be the ability to craft a more graceful error message for systems that do not meet the minimum requirements.

You could make the argument that system requirements should be tested for during installation, but not every application has or needs a setup package.

Not sure if it’s even possible to do in the way the framework is implemented, but it would be nice.

1 Like
8

That’s what installers are for.

9

There are some apps that you don’t want installers for.

I have an app that a user only runs once to migrate an old system to a new one.

I have several other apps where the “portable” version is far more popular than the installer version (some of these are wrapped in a virtualizer, some are SFX EXEs created by 7Zip).

A cryptic error message about missing DLLs is not user friendly at all and should at a minimum be a hardcoded variation of “Sorry, your computer doesn’t meet the minimum Windows version requirement,” if not something we could customize ourselves.

10

Do this work? Or the system crashes before it?

image
image1235×400 46 KB

Sub Opening() Handles Opening

  If System.Version < "10.0.18362" Then
    
    MessageBox "This app supports Windows 10 v1903 (10.0.18362) or superior."+EndOfLine+_
    "Your OS, "+System.Version.ToString+", must be upgraded."+EndOfLine+_
    "We extremely advise Windows 11 or superior. Press OK to quit."
    
    Quit
    
  End
  
End Sub
11

@Rick_Araujo It does not.

Windows 8-2025-04-11-15-50-29
Windows 8-2025-04-11-15-50-291966×1445 109 KB

12

Sad. A feature request to something similar should be filed about an user configurable multilingual string to be presented, when detecting unsupported OS versions, BEFORE loading important DLLs/DyLibs/SO as those.

13

Issue 78912.

14

I thought that error was generated by Windows when the DLLs can’t be resolved so it might not be possible for Xojo to do anything.

2 Likes
15

A message might be able to be displayed prior to attempting to load those dll’s, depending on how the xojo and windows frameworks are built. Similar to how Xojo Declares can be Soft. Only a Xojo engineer will be able to say for sure, but you’re right, it’s possible.

1 Like
16

Before App.Opening() they have initializations. Before inits, a Windows loader take care of loading things and putting them on the right places before jumping to the main().

That said, they could exclude some of those known not present DLLs/DyLibs/SO in the previous OS from the exported list to the OS loader and postpone its load to runtime AFTER a start up init() doing some crucial checks… as checking the current OS version.

If an unsupported version is found (version lower than minimal supported version), a simple alert using an user defined constant (better if locale sensitive, one from many) is outputted, and quit.

Basically something like:

main() {

  basic_inits();

  minimal_version_or_alert_and_die();

  load_postponed_libs_or_alert_and_die();

  more_inits();

  run_app();

}
1 Like