Hyperion Entertainment Message Boards

Hi all,
I've recently installed OS4.1FE on my A1XE and all went well. I installed RunInUAE as supplied as well, and it all appears to work fine - click on an ADF and it boots to the game. However, if I switch back to Workbench with LAmiga-N to do something else, file requesters behave oddly. Nothing is out of the ordinary in Workbench, but if I open a file requester and click the Volumes button, the list of volumes seems to be in a constant refreshing loop that I can't get out of. Exit E-UAE and the requester returns to normal behaviour and can be used as normal.

I haven't modified a single thing in OS4.1FE (yet ) And I don't remember this happening under update 6. Any ideas?

At a guess, I would suggest that RunInUae is doing something with the volume/device list which is causing the ASL requester to constantly refresh.

Perhaps asking Chris Handley personally what his program is doing might reveal more useful feedback, but it certainly doesn't seem like an OS problem, more that the OS is revealing some operation in RunInUae that it shouldn't be doing.

Simon

Rigo wrote:At a guess, I would suggest that RunInUae is doing something with the volume/device list which is causing the ASL requester to constantly refresh.
Perhaps asking Chris Handley personally what his program is doing might reveal more useful feedback, but it certainly doesn't seem like an OS problem, more that the OS is revealing some operation in RunInUae that it shouldn't be doing.
Simon

The ASL library sets up a filesystem notifyrequest for the current directory, also, it sets up a DosList change notification.
Either of these will cause a refresh. I have not used that program, so i'm just giving general advise on possible causality here.

It's unlikely that the program is modifying the current directory on a continual basis, nor is it likely that the program is
modifying the DOS device list constantly either.

It is likely that it could be patching some DOS or Workbench function/s incorrectly, which could easily cause an event loop
feedback effect like this, if the patch code happens to be calling another function which causes an event signal.
This is frequently a major cause of problems, when anyone patches operating system functions without knowing what is
happening inside, it immediately makes the external program unsupportable across different OS versions, because you only
have to change something minor and the external programs patch code blows up, worst of all, OS patches done by external
programs seldom do propper version checks, so it's nearly impossible to disable faulty code when used on later OS versions,
not only causing the program to break something, but crippling the OS for many other programs too.

I would suggest you run "Snoopy" and see if it's doing something continuously when just sitting there, or if it kicks it into
action when opening an ASL requester. It may show something interesting or usefull.

Or, you could simply not use UAE.

Thanks for the feedback guys, I'll check it out with Snoopy and see if it shows anything up. It would be a pity if I can't use UAE any more as I was using that for testing my software, and having to transfer back and forth to a 68k machine or a PC to test and bugfix is a lot more hassle than simply double-clicking the executable, especially when it worked fine before.

I'll contact Chris as well and see if he can shed any light on the subject.

Okay, it seems the problem was that the version of RunInUAE that is included on the 4.1FE CD is a much older version than the current one which I was using under Update 6. Updated to the "new" (2013) version and it all works fine again.

Interestingly, AmiUpdate didn't pick up on that, even though RunInUAE is registered for automatic updates...