View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Dec 29, 2016 7:41 pm Post subject: |
|
|
Oops. Forgot to include the error.
Code: |
Floating point stack fault
Floating point stack fault at address 74d9677f
74d9677f routine at address 74D9677F [+0000]
74d97048 routine at address 74D97048 [+0000]
74d96f02 routine at address 74D96F02 [+0000]
74d969eb routine at address 74D969EB [+0000]
74d9765a routine at address 74D9765A [+0000]
74da3874 routine at address 74DA3874 [+0000]
74da3650 routine at address 74DA3650 [+0000]
74da3c25 routine at address 74DA3C25 [+0000]
eax=e0eec63f ebx=0360ca70 ecx=e3af7faa
edx=41328a60 esi=00000000 edi=00000000
ebp=0360c9cc esp=0360c938 IOPL=0
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00210286 [NC EP NZ NS DN NV]
74d9677f fcomp [ebx+0x60]
74d96782 fstsw ax
74d96784 testb ah,0x41
|
Program was compiled under CHECKMATE WIN32, all default options. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Dec 30, 2016 5:30 am Post subject: |
|
|
The plot thickens.
Yesterday, I installed some SW that also installed some Microsoft DLL's (I think).
Microsoft Visual C++2015 redistributables (x64 and x86) 14.0.24210
This BROWSE software that failed on that one machine runs quite nicely on a different machine that does not have this new software.
I'll try to narrow down what was installed. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Fri Dec 30, 2016 9:16 am Post subject: |
|
|
For me browse_for_folder@ and browse_for_folder1@ both work OK for 32 bit applications but both fail for 64 bit applications. They may never have been tested for 64 bits. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Dec 30, 2016 4:15 pm Post subject: |
|
|
Only using the 32-bit here.
I just removed the 2015 redistributables, and rebooted the machine, but the problem still exists.
Any suggestions as to where to look to determine why the same code (compiled separately, but using the same MAKE files) on the two machines works differently would be appreciated.
Thanks,
Bill |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Dec 30, 2016 6:15 pm Post subject: |
|
|
OK, definitely my user account on this single machine. But no clue as to why. Logged into a user account on this machine, all runs fine. Runs fine on another machine that has no development SW on it, that worked well.
Have run a System Scan to see if any files are damaged. Nothing showed as needing fixing.
Might I have some FTN95 DLL that is out of date that is being used just in my user (and non-privileged) account? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sat Dec 31, 2016 5:25 pm Post subject: |
|
|
I may have a reason for this crash in one user account/machine and not another.
The FTN95 function browse_for_folder1@ uses the shell function SHBrowseForFolder as its base. The MSDN documentation says that from Vista on, it is best to use IFileDialog.
From Stack Overflow, the reason is the complexity of the folder dialog (many items) can cause the control to crash or yield "odd results". Indeed, the dialog visually appears to act a bit differently when invoked from different user/machine accounts.
http://stackoverflow.com/questions/15293557/selectdirectory-shbrowseforfolder-issue-when-having-a-lot-of-shell-items/15293771#15293771
Working on a temporary (?) solution.... |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Jan 04, 2017 4:39 pm Post subject: |
|
|
I have decided to revert all my code from using browse_for_folder1@ to use browse_for_folder@, removing the ability to create a new folder by the user.
While taking away a "standard" benefit from the code is lamentable, causing a crash is not a choice I can leave to the user.
I have experimented with IFileDialog, the suggested better way, but have not been able to successfully integrate this function with FTN95. I will continue, but I give this little hope of success at present.
Since this IFileDialog function is only available in Windows Vista and later, perhaps it is not the best choice for FTN95 at the present time. I also have users who are still using Windows XP on some field data input devices, so (for me) the die is cast. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jan 04, 2017 4:49 pm Post subject: |
|
|
If you know which OS creates the fault then you could test for the OS and make a choice in your code. See GET_OS_VER@. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Jan 04, 2017 4:55 pm Post subject: |
|
|
It should also be noted than using a regular file open dialog (using GET_FILTERED_FILE@) then attempting to create a folder also causes a crash. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Wed Apr 26, 2017 11:37 pm Post subject: |
|
|
Now that I have transitioned to /DEFINT_KIND 3, the crash previously caused by creating a New Folder no longer occurs. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Apr 27, 2017 7:09 am Post subject: |
|
|
I don't know exactly why this should make a difference but if (say) you use /DEFINT_KIND 2 instead of /DEFINT_KIND 3 (which is the default) then literal constant integer arguments like the value 42 will be passed as the address of a 16 bit value. That is, it will be passed as 42_2 and not 42_3. This may make a difference and the effect could be different for 32 bit executables against 64 bit executables.
Putting this another way, /DEFINT_KIND changes the KIND value of literal constant integers that are not given a specific KIND value. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Apr 27, 2017 6:55 pm Post subject: |
|
|
Quote: | I don't know exactly why this should make a difference but if (say) you use /DEFINT_KIND 2 instead of /DEFINT_KIND 3 (which is the default) then literal constant integer arguments like the value 42 will be passed as the address of a 16 bit value. |
as any passing mouse or man in a dressing gown will tell you, since 42 is the key digit, ... it's all something to do with ftn95, the universe and everything
(goes away to code: lu&e = 7 x 8 to check his theory PMLOL) |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Apr 27, 2017 9:52 pm Post subject: |
|
|
I did avoid literals in the calls to this function unless they were declared with an "L", or declared specifically as INTEGER*4 and a parameter.
I cannot explain the difference in operations. Just an observation. |
|
Back to top |
|
|
|