I've tried several versions of Dualis but I have a lockup on all of them when I go to open a ROM image. This is before any emulation would take place (so it's likely related to my system, an old laptop). I've tried changing 3D modes in case it was some sort of initialization error but it didn't make a difference. I also tried running with -wincon but I don't see any output on the terminal before the system locks up. Anyone else seen a similar problem? Is there any chance of a debug version which can spit out some debug to get to the bottom of the problem? Any suggestions welcome. Thanks in advance.



Edit: I should clarify that I don't even get as far as a file browse dialog opening, I get a lockup as soon as I select Load or Load and Execute.

mic is there any chance you could tell me what calls are made between the user selecting Open and the file dialog being displayed? Or hazard a guess as to what could be going on. I'm sure it's a win32 type issue (I'm running on XP), but I haven't had any trouble with other emulators or code in general so it's a bit of a puzzle to me why Dualis would have a problem (all versions I've tried). It's a show stopper for me so I'd like to get to the bottom of it if possible. I take it that nobody else has seen this problem, but as you get more users it might start to show up, so maybe it's a good idea to find out what it is. Any help/ideas appreciated. Thanks.

i've never had this. Can you provide some information about your system?

Such as, what OS, how much ram, what system specs etc. What else is running? etc etc

The first thing that's done is to open the "Load ROM" dialog, which uses the standard win32 GetOpenFileName API call. Could it be that your system is very low on memory? Since the Windows file dialogs seem to consume a fair amount of memory when they're active.

I figure it's something win32 related, but I don't think it's memory as other stuff works fine. This happens even if I have no other applications running. If I look at memory usage in Task Manager there is plenty of RAM left, also the CPU is low when it freezes.

I thought at first it could be something to do with unicode/wchar support as my system was configured to run non-unicode applications in Japanese locale (I'm in Japan) - but I changed this and still get the problem.

System is a rather old laptop PIII 800Mhz with 256Mb RAM running XP SP2. It's not fast but I don't think it's a resource issue - and if it was it should just be a performance issue, not a catastrophic failure. (I really only use the emus in debug mode so performance isn't a big deal for me)

Any ideas/suggestions (other than get a new PC) welcome!


Edit: BTW, do you check the return values of the win32 calls? Are they ignored in a release build? Maybe there is a win32 error being ignored and the subsequent call is failing?

GetOpenFileName is checked for a proper return value.
It could have something to do with your japanese Windows. I'm running swedish Windows myself so I don't really have any way of testing it with Windows versions not using the latin alphabet.

What do you do in a release build if it fails? exit()?


Somehow I think it might be related to this (but having set the locale to English it *should* work). Has anyone else run OK on a Japanese XP? Are you building with wchar/unicode support enabled?

Strange thing is the other emulators, DS and GBA, all work fine. Would it be possible to get a debug build to see if it gives more information (or runs)?

In that case I simply don't try to load anything, since it indicates that the user pressed the Cancel button on the open dialogue, or the dialogue failed.


There is no debug build. Nor can I make one since I don't have all the relevant libraries.

I don't think it needs all the libs, I'd just like to confirm which call is failing and if there is an error code. I assume something is failing at the moment, but we don't know what it is, if we knew the error code we could track down the problem fairly quickly I think.

BTW can you confirm that you are compiling with unicode support? I assume at some point you will want to support other language (like VBA - which has excellent language support BTW) so it might be worth enabling for the next release (if not enabled already) and might just fix the problem (slightly long shot, but you never know).

Anyway, I'm away for a few days (Golden Week in Japan) so I'll see if I have a flash of inspiration while I'm away! Thanks for help so far.