forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

Update: This function no longer works on my main machine, but still works on the laptop. I compiled and ran on the laptop (no problems), run on the desktop, crash. Sometimes it will crash with no traceback.

Whatever was fixed last year after my nuke and pave is now broken again.

I will continue to use it for my users, but not being able to properly test all the program paths by being able to create a new folder using the system dialog is a limiter for me.

BTW, I get a Floating Point Stack Fault (like before), several lines of addresses show (no names even in checkmate) and offsets specified as (+0000) on every line.

PaulLaidler · Posted: Wed Mar 11, 2020 8:50 am Post subject:

I don't recall, is this 32 bits or 64 bits and does it make a difference?

mecej4 · Joined: 31 Oct 2006 Posts: 1897

If Bill is getting FPU stack faults, it would have to be 32-bit, would it not? The X87 is the one that provides a stack view of the ST0-ST7 registers.

PaulLaidler · Posted: Wed Mar 11, 2020 11:47 am Post subject:

I missed that. In which case it might help if ClearWin+ clears the FP stack before making the call.

I have now done this for the next release of salflibc.dll.

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

Than ks, I'll give it a shot when it comes out.

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

In all the other things, I've been remiss in this after you had put out a new release.

It still does not work on my main system.

I (today) tried to capture the FP Stack Fault by setting the handler immediately before the browse_for_folder1@() call. What i got was a continuous stack fault handler being invoked. I tried using the code/edoc and the instruction FCLEX in the handler to clear the fault. If I do not enable the handler, the function will execute, but FP Stack Fault after I try to add a folder. So a couple of questions.

Using code/edoc, what instruction (or combination) could be used to clear the fault before the browse_for_folder1() gets called?

What instructions can be used to clear the stack fault, then return a 0 indicating the fault was handled?

Also, how does one re-install the Old Handler? CORE4(OLD_HANDLER)?

PaulLaidler · Posted: Tue Oct 20, 2020 9:33 am Post subject:

Bill

browse_for_folder1@ in the latest DLLs resets the floating point stack via fclex, finit, and fround at the beginning of the the function. So it won't make any difference if you do this in your code.

My guess is that you won't be able to recover from a floating point stack fault. When you handle it and say "continue", the fault will still be there.

At the moment the 32 bit browse_for_folder@ and browse_for_folder1@ do not respond to "alt_open_save" where as for 64 bits only the alternative is employed.

Is it possible for you to extract and test your call browse_for_folder1@ using 64 bits? I am thinking that if your cut down fails for 32 bits and works for 64 bits then perhaps I might be able to make the alternative available for 32 bits.

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

Paul, I will give this a try. Transferring my existing code to 64-bits is not something I can do quickly. That said, I will see what I can do to get the problem to occur/not-occur between the two platforms and let you know.

Appreciate you taking another shot at this.

Bill

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

Paul, I used the little test program I originally posted, and ran it as a 64-bit. Here's what I see.

When I run it, I get a DOS box displayed (which is curious - is that supposed to happen). I navigate to where I want a folder and click "Make a New Folder". The folder name came up (in this case New Folder (2)). I change the name of the folder and click OK. Then things get strange.

Just briefly in the window, I see my changed name return to New Folder (2). The program returns the name New Folder (2) as my folder name. However, the folder name I typed is created. This works the same way with the UNIT specified as either Z'40' and Z'41'.

The same behavior in both Checkmate and Release 64.

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

With the 32-bit attempt, a portion of the same behavior is seen. That is, after typing a new name and clicking OK, the New Folder (2) shows briefly, and the program crashes with no trace. The newly named folder does appear when looking at the folder in Explorer.

PaulLaidler · Posted: Wed Oct 21, 2020 3:54 pm Post subject:

Bill

Your code runs OK for me in for both 32 bits and 64 bits. I don't get a DOS box.

As a natural instinct I would not click on OK before exiting from editing the name of the new folder but it turns out that (for me) it makes no difference to the outcome.

PaulLaidler · Posted: Wed Oct 21, 2020 4:29 pm Post subject:

As an afterthought I also tried creating a sub-folder in a protected folder and this also works OK but naturally you do get a number of prompts to confirm the elevated status.

Hopefully it would not crash if the access rights were denied but I have not tested this.

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

Even if I just hit <Enter>, the same thing happens; crash.

The DOS box in 64 was a surprise because I included WINAPP. I seem to remember that maybe this isn't necessary anymore. I'll try changing the Project to set the /WINDOWS command line option and see if that make it not show up.

Bill

wahorger · Joined: 13 Oct 2014 Posts: 1226 Location: Morrison, CO, USA

FYI: If I try to create a folder in an OPEN dialog (opening a file, or saving a file), the software exits, no traceback. Just quits.

PaulLaidler · Posted: Thu Oct 22, 2020 8:32 am Post subject:

Are you creating a simple subfolder (i.e. the main folder has full access rights)?

Are you able to test on other operating systems (i.e. different versions of Windows 10 or Windows 8)?