1. Win32lib working on Seven 64 bits
- Posted by jmduro Feb 09, 2015
- 1592 views
Hello,
Win32lib used to crash on my Windows Seven PC trying to reboot the PC. I got it working again using the following combination:
- http://openeuphoria.org/eubins/struct/windows/64/eubin-2012-08-26-1afa523b0336.zip
- http://sourceforge.net/p/win32libex/mercurial/ci/win64/tree/
I had to add following lines in win32lib.ew at the beginning of the Low level routines section (line 3647) to get it work:
ifdef BITS64 then public constant C_LONG_PTR = C_INT elsedef public constant C_LONG_PTR = C_LONG end ifdef
Now I can run a program that crashed before on Seven 64 bits, but it still can't be used with Matt's euwin32libide. It crashes without building an error file.
Regards
Jean-Marc
2. Re: Win32lib working on Seven 64 bits
- Posted by mattlewis (admin) Feb 09, 2015
- 1572 views
Hello,
Win32lib used to crash on my Windows Seven PC trying to reboot the PC. I got it working again using the following combination:
- http://openeuphoria.org/eubins/struct/windows/64/eubin-2012-08-26-1afa523b0336.zip
- http://sourceforge.net/p/win32libex/mercurial/ci/win64/tree/
I had to add following lines in win32lib.ew at the beginning of the Low level routines section (line 3647) to get it work:
ifdef BITS64 then public constant C_LONG_PTR = C_INT elsedef public constant C_LONG_PTR = C_LONG end ifdef
Now I can run a program that crashed before on Seven 64 bits, but it still can't be used with Matt's euwin32libide. It crashes without building an error file.
That's an incorrect definition. std/dll.e has the correct definition of this type:
ifdef BITS32 then public constant --** signed integer sizeof pointer C_LONG_PTR = C_LONG elsedef public constant C_LONG_PTR = C_LONGLONG end ifdef
It sounds like there's a bug with how that's being used somewhere. What problem did that fix for you?
Matt
3. Re: Win32lib working on Seven 64 bits
- Posted by jmduro Feb 10, 2015
- 1510 views
Hi Matt,
As I don't know of which problem you are writing about, I answer on all:
The C_LONG_PTR definition caused a compilation error: undefined C_LONG_PTR.
The win32lib crash before using memstruct caused a critical failure: it asked Windows to abort session and reboot, loosing all current data.
win32libide seems to abort in a clean way thus not writing an error file. I think there must be an abort() instruction met without a previous warning or error log.
Thank you for the correction to apply to win32lib.ew.
Regards
Jean-Marc
4. Re: Win32lib working on Seven 64 bits
- Posted by jmduro Feb 10, 2015
- 1484 views
That's an incorrect definition. std/dll.e has the correct definition of this type:
ifdef BITS32 then public constant --** signed integer sizeof pointer C_LONG_PTR = C_LONG elsedef public constant C_LONG_PTR = C_LONGLONG end ifdef
It sounds like there's a bug with how that's being used somewhere. What problem did that fix for you?
Matt
My std/dll.e does not have such a definition, that's why I got a compilation error.
Regards
Jean-Marc
5. Re: Win32lib working on Seven 64 bits
- Posted by mattlewis (admin) Feb 10, 2015
- 1456 views
Hi Matt,
As I don't know of which problem you are writing about, I answer on all:
The C_LONG_PTR definition caused a compilation error: undefined C_LONG_PTR.
That should be in std/dll.e. It's been in the code since at least March 2013.
The win32lib crash before using memstruct caused a critical failure: it asked Windows to abort session and reboot, loosing all current data.
win32libide seems to abort in a clean way thus not writing an error file. I think there must be an abort() instruction met without a previous warning or error log.
I don't know what could be happening there, though some sort of machine crash sounds likely. For serious errors like this, you can use trace(3) to find out where the crash is happening.
Matt
6. Re: Win32lib working on Seven 64 bits
- Posted by jmduro Feb 10, 2015
- 1439 views
Hi Matt,
The C_LONG_PTR definition caused a compilation error: undefined C_LONG_PTR.
That should be in std/dll.e. It's been in the code since at least March 2013.
That is because the most recent files I found in http://openeuphoria.org/eubins/struct/windows/64/ are dated from August 2012.
win32libide seems to abort in a clean way thus not writing an error file. I think there must be an abort() instruction met without a previous warning or error log.
I don't know what could be happening there, though some sort of machine crash sounds likely. For serious errors like this, you can use trace(3) to find out where the crash is happening.
Even with trace(3) I can't see where the error stands. Maybe there ?
IDE_docking.ew:46 if fSyncOthers then IDE_docking.ew:47 for i = 1 to length(DockWindows) do IDE_docking.ew:49 if not(find(getHandle(DockWindows[i]), {hWnd, lParam})) IDE_docking.ew:50 VOID = sendMessage(DockWindows[i], WM_NCACTIVATE, fKeep === THE END === ... trace continues till here ... IDE_docking.ew:50 VOID = sendMessage(DockWindows[i], WM_NCACTIVATE, fKeep IDE_docking.ew:26 fKeepActive = wParam IDE_docking.ew:27 fSyncOthers = w32True IDE_docking.ew:32 if find(getId(lParam), DockWindows) then IDE_docking.ew:40 if 0 = not_bits( lParam ) then IDE_docking.ew:46 if fSyncOthers then
Regards
Jean-Marc
