Strange error in openmsx 0.11.0

By ARTRAG

Enlighted (6550)

ARTRAG's picture

08-09-2015, 08:46

After an update of my graphic drivers I get in catapult this error:

Couldn't open socket.
Loading selected font (skins/VeraMono.ttf.gz) failed. Reverting to default font (skins/VeraMono.ttf.gz).
Uncaught exception: can't set "consolefont": GetTempFileNameW failed: 5 (and I have no other ideas to try...)

Running Openmsx directly does not help (it aborts directly).
I've tried to reinstall openmsx from scratch but the error is always there.

Any hint on what is going wrong ? (I'm running windows 7)

Login or register to post comments

By wouter_

Champion (467)

wouter_'s picture

08-09-2015, 12:25

I can't immediately say what the (root) problem is, but I can explain the errors you see in more detail. Hopefully that already helps.

Catapult gives this error:
Couldn't open socket.
This means openMSX could not be started, you've already confirmed this: trying to start openMSX directly also doesn't work for you. So the problem is located in openMSX, not catapult.

The other error messages come from openMSX itself:
Loading selected font (skins/VeraMono.ttf.gz) failed. Reverting to default font (skins/VeraMono.ttf.gz).
When openMSX starts it needs to load a font for the console. There is a setting that specifies which font should be used. When the selected font cannot be loaded, openMSX falls back to the default font. Though in your case you kept the default font, so the fall back will again trigger the same problem.

The next error in the list is this:
Uncaught exception: can't set "consolefont": GetTempFileNameW failed: 5
This gives more details about why the font could not be loaded. The default font-file we ship with openMSX (skins/VeraMono.ttf.gz) is compressed. Before it can be used it must first be decompressed. We decompress it to a temporary file and the name for that temporary file is obtained via the windows function GetTempFilenameW(). This function returned error code 5 and (I had to look it up) that means ERROR_ACCESS_DENIED.

OpenMSX creates its temporary files in the "openmsx" subdirectory inside the standard windows temp directory (the directory returned by the GetTempPathW() function). So possibly your windows temp directory already contains an "openmsx" file or directory with inappropriate file access permission?

By ARTRAG

Enlighted (6550)

ARTRAG's picture

08-09-2015, 21:47

My Temp directory does not have any openmsx subdirectory....
still clueless...

By flyguille

Prophet (3028)

flyguille's picture

08-09-2015, 22:02

try to execute it with Administrator rights! Right click -> run as administrator.

By Manuel

Ascended (18162)

Manuel's picture

08-09-2015, 22:43

ARTRAG: the question is: did you check the correct Temp directory...? I don't know how you can actually check which one it is using, though... Perhaps you could check your whole harddrive on directories named 'openmsx' and check whether it's possibly in the temp dir.

It's also possible that the temp dir that this GetTempPathW function returns is now something different, a folder that is not accessible by the user you're logged in with. That's possible, because this function can be influenced with environment variables, it seems: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

By ARTRAG

Enlighted (6550)

ARTRAG's picture

09-09-2015, 00:23

YES! The Intellivision SDK I've started to use recently has changed the path for the directory TEMP (where openmsx unpacks its files). I've created manually an openmsx subdirectory in the new TEMP and now everything works as before. Thanks!

By Manuel

Ascended (18162)

Manuel's picture

09-09-2015, 09:31

openMSX should have been able to create the dir itself there. Is the directory not writable for all users? (Which directory is it now?)

By Grauw

Ascended (10074)

Grauw's picture

09-09-2015, 12:59

ARTRAG wrote:

YES! The Intellivision SDK I've started to use recently has changed the path for the directory TEMP

Ouch.