date:20170501

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Rony G. Flatscher

Adding the ExternC modifier was not enough (same error), however "ExternC 
*const*" did the trick!

So probably the following should be added:

*ExternC #ifndef DELAYIMP_INSECURE_WRITABLE_HOOKS const #endif* PfnDliHook 
__pfnDliFailureHook2
= delayFailHook;

Have to run (far too late, midnight and I have to get up at 6:00 tomorrow). 
Will do a "nmake clean"
and "nmake" tomorrow.

---rony



On 01.05.2017 23:47, Rick McGuire wrote:
> This documentation for the hooks 
>
> https://msdn.microsoft.com/en-us/library/z9h1h6ty.aspx
>
> Shows a different declaration for this variable. Try adding the ExternC 
> modifier. That change is
> building fine for me. 
>
> Rick
>
> On Mon, May 1, 2017 at 5:44 PM, Rony G. Flatscher  > wrote:
>
>
> On 01.05.2017 23:40, Rick McGuire wrote:
>> Try removing the int and see if it makes a difference.
> Just tried it, no it does not make a difference, same error: 
> redefinition, different modifiers.
>
> ---rony
>
>>
>>
>> On Mon, May 1, 2017 at 5:32 PM, Rony G. Flatscher 
>> > > wrote:
>>
>>
>> On 01.05.2017 23:10, Rick McGuire wrote:
>>> This has been encountered before. You need to have the correct 
>>> level of the SDK
>>> installed. Mark Miesfeld always recommended this one: 
>>>
>>> http://www.microsoft.com/en-us/download/details.aspx?id=8442
>>> 
>> Thank you! That is the version I have installed. When extending the 
>> INCLUDE environment
>> symbol to point to the appropriate SDK Include directory (now 
>> "e:\Programme\Microsoft
>> SDKs\Windows\v7.1\Include" on my system) it is able to compile the 
>> events.cpp file.
>>
>> Much later it then there is a redefinition error:
>>
>> [ 85%] Building CXX object
>> 
>> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
>> oodPackageEntry.cpp
>> 
>> G:\oorexx.tmp\oorexxSVN\main\trunk\extensions\platform\windows\oodialog\*oodPackageEntry.cpp(444)*:
>> error C2373: "__pfnDliFailureHook2": 
>> Neudefinition;unterschiedliche Modifizierer
>> E:\Programme\Microsoft Visual Studio 
>> 14.0\VC\INCLUDE\*delayimp.h(141)*: note: Siehe
>> Deklaration von "__pfnDliFailureHook2" NMAKE : fatal error U1077:
>> "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": Rückgabe-Code "0x2" 
>> Stop. NMAKE : fatal error
>> U1077: ""E:\Programme\Microsoft Visual Studio 
>> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code
>> "0x2" Stop.
>>
>> oodPackageEntry.cpp defines:
>>
>> FARPROC WINAPI delayFailHook(*unsigned **int *dliNotify, 
>> PDelayLoadInfo pdli) {
>> switch (dliNotify) { case dliFailLoadLib : printf("Failed to 
>> load %s, error code: %d.
>> Ensure %s is available.\n", pdli->szDll, pdli->dwLastError, 
>> pdli->szDll); break; case
>> dliFailGetProc : if (pdli->dlp.fImportByName) { printf("Failed 
>> to get procedure: %s
>> in %s. Last error: %d\n", pdli->dlp.szProcName, pdli->szDll, 
>> pdli->dwLastError); }
>> else { printf("Failed to get procedure, ordinal: %s in %s. Last 
>> error: %d\n",
>> pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError); } break; 
>> default :
>> printf("Unknown error trying to delay load %s.\n", pdli->szDll); 
>> break; } printf("The
>> error is unrecoverable, have to abort.\n"); return NULL; } 
>> *PfnDliHook
>> __pfnDliFailureHook2 = delayFailHook; // <-- line 444*
>>
>> delayimp.h defines:
>>
>> typedef FARPROC (WINAPI *PfnDliHook)( *unsigned * dliNotify, 
>> PDelayLoadInfo pdli );
>>
>> The difference seems to be that oodPackageEntry.cpp defines 
>> "unsigned int" and delyimp.h
>> "unsigned" (without "int") for the dliNotify argument. (If it makes 
>> a difference: my MSC
>> compiler is from the "professional" Visual Studio 2015 edition, 
>> maybe it is pickier.)
>> ---rony
>>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Rick McGuire

This documentation for the hooks

https://msdn.microsoft.com/en-us/library/z9h1h6ty.aspx

Shows a different declaration for this variable. Try adding the ExternC
modifier. That change is building fine for me.

Rick

On Mon, May 1, 2017 at 5:44 PM, Rony G. Flatscher 
wrote:

>
> On 01.05.2017 23:40, Rick McGuire wrote:
>
> Try removing the int and see if it makes a difference.
>
> Just tried it, no it does not make a difference, same error: redefinition,
> different modifiers.
>
> ---rony
>
>
>
> On Mon, May 1, 2017 at 5:32 PM, Rony G. Flatscher  > wrote:
>
>>
>> On 01.05.2017 23:10, Rick McGuire wrote:
>>
>> This has been encountered before. You need to have the correct level of
>> the SDK installed. Mark Miesfeld always recommended this one:
>>
>> http://www.microsoft.com/en-us/download/details.aspx?id=8442
>>
>> Thank you! That is the version I have installed. When extending the
>> INCLUDE environment symbol to point to the appropriate SDK Include
>> directory (now "e:\Programme\Microsoft SDKs\Windows\v7.1\Include" on my
>> system) it is able to compile the events.cpp file.
>>
>> Much later it then there is a redefinition error:
>>
>> [ 85%] Building CXX object 
>> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
>> oodPackageEntry.cpp
>> G:\oorexx.tmp\oorexxSVN\main\trunk\extensions\platform\windows\oodialog\*oodPackageEntry.cpp(444)*:
>>  error C2373: "__pfnDliFailureHook2": Neudefinition;unterschiedliche 
>> Modifizierer
>> E:\Programme\Microsoft Visual Studio 14.0\VC\INCLUDE\*delayimp.h(141)*: 
>> note: Siehe Deklaration von "__pfnDliFailureHook2"
>> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
>> Rückgabe-Code "0x2"
>> Stop.
>> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
>> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
>> Stop.
>>
>> oodPackageEntry.cpp defines:
>>
>> FARPROC WINAPI delayFailHook(*unsigned **int *dliNotify, PDelayLoadInfo pdli)
>> {
>> switch (dliNotify)
>> {
>> case dliFailLoadLib :
>> printf("Failed to load %s, error code: %d.  Ensure %s is 
>> available.\n",
>>pdli->szDll, pdli->dwLastError, pdli->szDll);
>> break;
>>
>> case dliFailGetProc :
>> if (pdli->dlp.fImportByName)
>> {
>> printf("Failed to get procedure: %s in %s.  Last error: 
>> %d\n",
>>pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError);
>> }
>> else
>> {
>> printf("Failed to get procedure, ordinal: %s in %s.  Last 
>> error: %d\n",
>>pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError);
>> }
>> break;
>>
>> default :
>> printf("Unknown error trying to delay load %s.\n", pdli->szDll);
>> break;
>> }
>>
>> printf("The error is unrecoverable, have to abort.\n");
>>
>> return NULL;
>> }
>> *PfnDliHook __pfnDliFailureHook2 = delayFailHook;  // <-- line 444*
>>
>> delayimp.h defines:
>>
>> typedef FARPROC (WINAPI *PfnDliHook)(
>> *unsigned *   dliNotify,
>> PDelayLoadInfo  pdli
>> );
>>
>> The difference seems to be that oodPackageEntry.cpp defines "unsigned
>> int" and delyimp.h "unsigned" (without "int") for the dliNotify argument.
>> (If it makes a difference: my MSC compiler is from the "professional"
>> Visual Studio 2015 edition, maybe it is pickier.) ---rony
>>
>> --
>> Check out the vibrant tech community on one of the world's most engaging
>> tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___ Oorexx-devel mailing
>> list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/
>> lists/listinfo/oorexx-devel
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> --
> --
> __
>
> Prof. Dr. Rony G. Flatscher
> Department Informationsverarbeitung und Prozessmanagement
> Institut für Betriebswirtschaftslehre und Wirtschaftsinformatik
> D2-C 2.086
> WU Wien
> Welthandelsplatz 1
> A-1020  Wien/Vienna, Austria/Europe
> http://www.wu.ac.at
> __
>
>
>
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Rony G. Flatscher


On 01.05.2017 23:40, Rick McGuire wrote:
> Try removing the int and see if it makes a difference.
Just tried it, no it does not make a difference, same error: redefinition, 
different modifiers.

---rony
>
>
> On Mon, May 1, 2017 at 5:32 PM, Rony G. Flatscher  > wrote:
>
>
> On 01.05.2017 23:10, Rick McGuire wrote:
>> This has been encountered before. You need to have the correct level of 
>> the SDK installed.
>> Mark Miesfeld always recommended this one: 
>>
>> http://www.microsoft.com/en-us/download/details.aspx?id=8442
>> 
> Thank you! That is the version I have installed. When extending the 
> INCLUDE environment symbol
> to point to the appropriate SDK Include directory (now 
> "e:\Programme\Microsoft
> SDKs\Windows\v7.1\Include" on my system) it is able to compile the 
> events.cpp file.
>
> Much later it then there is a redefinition error:
>
> [ 85%] Building CXX object
> 
> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
> oodPackageEntry.cpp
> 
> G:\oorexx.tmp\oorexxSVN\main\trunk\extensions\platform\windows\oodialog\*oodPackageEntry.cpp(444)*:
> error C2373: "__pfnDliFailureHook2": Neudefinition;unterschiedliche 
> Modifizierer
> E:\Programme\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\*delayimp.h(141)*: note: Siehe
> Deklaration von "__pfnDliFailureHook2" NMAKE : fatal error U1077:
> "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": Rückgabe-Code "0x2" Stop. 
> NMAKE : fatal error
> U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> oodPackageEntry.cpp defines:
>
> FARPROC WINAPI delayFailHook(*unsigned **int *dliNotify, 
> PDelayLoadInfo pdli) { switch
> (dliNotify) { case dliFailLoadLib : printf("Failed to load %s, error 
> code: %d. Ensure %s
> is available.\n", pdli->szDll, pdli->dwLastError, pdli->szDll); 
> break; case dliFailGetProc
> : if (pdli->dlp.fImportByName) { printf("Failed to get procedure: %s 
> in %s. Last error:
> %d\n", pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError); } else 
> { printf("Failed to
> get procedure, ordinal: %s in %s. Last error: %d\n", 
> pdli->dlp.szProcName, pdli->szDll,
> pdli->dwLastError); } break; default : printf("Unknown error trying 
> to delay load %s.\n",
> pdli->szDll); break; } printf("The error is unrecoverable, have to 
> abort.\n"); return
> NULL; } *PfnDliHook __pfnDliFailureHook2 = delayFailHook; // <-- line 
> 444*
>
> delayimp.h defines:
>
> typedef FARPROC (WINAPI *PfnDliHook)( *unsigned * dliNotify, 
> PDelayLoadInfo pdli );
>
> The difference seems to be that oodPackageEntry.cpp defines "unsigned 
> int" and delyimp.h
> "unsigned" (without "int") for the dliNotify argument. (If it makes a 
> difference: my MSC
> compiler is from the "professional" Visual Studio 2015 edition, maybe it 
> is pickier.) ---rony
>
> 
> --
>  Check out the
> vibrant tech community on one of the world's most engaging tech sites, 
> Slashdot.org!
> http://sdm.link/slashdot ___ 
> Oorexx-devel mailing
> list Oorexx-devel@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>  
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
-- 
--
__

Prof. Dr. Rony G. Flatscher
Department Informationsverarbeitung und Prozessmanagement
Institut für Betriebswirtschaftslehre und Wirtschaftsinformatik
D2-C 2.086
WU Wien
Welthandelsplatz 1
A-1020  Wien/Vienna, Austria/Europe

http://www.wu.ac.at
__





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Rick McGuire

It works fine for me on 2013 version with or without the int.

Rick

On Mon, May 1, 2017 at 5:32 PM, Rony G. Flatscher 
wrote:

>
> On 01.05.2017 23:10, Rick McGuire wrote:
>
> This has been encountered before. You need to have the correct level of
> the SDK installed. Mark Miesfeld always recommended this one:
>
> http://www.microsoft.com/en-us/download/details.aspx?id=8442
>
> Thank you! That is the version I have installed. When extending the
> INCLUDE environment symbol to point to the appropriate SDK Include
> directory (now "e:\Programme\Microsoft SDKs\Windows\v7.1\Include" on my
> system) it is able to compile the events.cpp file.
>
> Much later it then there is a redefinition error:
>
> [ 85%] Building CXX object 
> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
> oodPackageEntry.cpp
> G:\oorexx.tmp\oorexxSVN\main\trunk\extensions\platform\windows\oodialog\*oodPackageEntry.cpp(444)*:
>  error C2373: "__pfnDliFailureHook2": Neudefinition;unterschiedliche 
> Modifizierer
> E:\Programme\Microsoft Visual Studio 14.0\VC\INCLUDE\*delayimp.h(141)*: note: 
> Siehe Deklaration von "__pfnDliFailureHook2"
> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
> Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> oodPackageEntry.cpp defines:
>
> FARPROC WINAPI delayFailHook(*unsigned **int *dliNotify, PDelayLoadInfo pdli)
> {
> switch (dliNotify)
> {
> case dliFailLoadLib :
> printf("Failed to load %s, error code: %d.  Ensure %s is 
> available.\n",
>pdli->szDll, pdli->dwLastError, pdli->szDll);
> break;
>
> case dliFailGetProc :
> if (pdli->dlp.fImportByName)
> {
> printf("Failed to get procedure: %s in %s.  Last error: %d\n",
>pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError);
> }
> else
> {
> printf("Failed to get procedure, ordinal: %s in %s.  Last 
> error: %d\n",
>pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError);
> }
> break;
>
> default :
> printf("Unknown error trying to delay load %s.\n", pdli->szDll);
> break;
> }
>
> printf("The error is unrecoverable, have to abort.\n");
>
> return NULL;
> }
> *PfnDliHook __pfnDliFailureHook2 = delayFailHook;  // <-- line 444*
>
> delayimp.h defines:
>
> typedef FARPROC (WINAPI *PfnDliHook)(
> *unsigned *   dliNotify,
> PDelayLoadInfo  pdli
> );
>
> The difference seems to be that oodPackageEntry.cpp defines "unsigned int"
> and delyimp.h "unsigned" (without "int") for the dliNotify argument.
> (If it makes a difference: my MSC compiler is from the "professional"
> Visual Studio 2015 edition, maybe it is pickier.)
>
> ---rony
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Rick McGuire

Try removing the int and see if it makes a difference.

Rick

On Mon, May 1, 2017 at 5:32 PM, Rony G. Flatscher 
wrote:

>
> On 01.05.2017 23:10, Rick McGuire wrote:
>
> This has been encountered before. You need to have the correct level of
> the SDK installed. Mark Miesfeld always recommended this one:
>
> http://www.microsoft.com/en-us/download/details.aspx?id=8442
>
> Thank you! That is the version I have installed. When extending the
> INCLUDE environment symbol to point to the appropriate SDK Include
> directory (now "e:\Programme\Microsoft SDKs\Windows\v7.1\Include" on my
> system) it is able to compile the events.cpp file.
>
> Much later it then there is a redefinition error:
>
> [ 85%] Building CXX object 
> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
> oodPackageEntry.cpp
> G:\oorexx.tmp\oorexxSVN\main\trunk\extensions\platform\windows\oodialog\*oodPackageEntry.cpp(444)*:
>  error C2373: "__pfnDliFailureHook2": Neudefinition;unterschiedliche 
> Modifizierer
> E:\Programme\Microsoft Visual Studio 14.0\VC\INCLUDE\*delayimp.h(141)*: note: 
> Siehe Deklaration von "__pfnDliFailureHook2"
> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
> Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> oodPackageEntry.cpp defines:
>
> FARPROC WINAPI delayFailHook(*unsigned **int *dliNotify, PDelayLoadInfo pdli)
> {
> switch (dliNotify)
> {
> case dliFailLoadLib :
> printf("Failed to load %s, error code: %d.  Ensure %s is 
> available.\n",
>pdli->szDll, pdli->dwLastError, pdli->szDll);
> break;
>
> case dliFailGetProc :
> if (pdli->dlp.fImportByName)
> {
> printf("Failed to get procedure: %s in %s.  Last error: %d\n",
>pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError);
> }
> else
> {
> printf("Failed to get procedure, ordinal: %s in %s.  Last 
> error: %d\n",
>pdli->dlp.szProcName, pdli->szDll, pdli->dwLastError);
> }
> break;
>
> default :
> printf("Unknown error trying to delay load %s.\n", pdli->szDll);
> break;
> }
>
> printf("The error is unrecoverable, have to abort.\n");
>
> return NULL;
> }
> *PfnDliHook __pfnDliFailureHook2 = delayFailHook;  // <-- line 444*
>
> delayimp.h defines:
>
> typedef FARPROC (WINAPI *PfnDliHook)(
> *unsigned *   dliNotify,
> PDelayLoadInfo  pdli
> );
>
> The difference seems to be that oodPackageEntry.cpp defines "unsigned int"
> and delyimp.h "unsigned" (without "int") for the dliNotify argument.
> (If it makes a difference: my MSC compiler is from the "professional"
> Visual Studio 2015 edition, maybe it is pickier.)
>
> ---rony
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Rick McGuire

This has been encountered before. You need to have the correct level of the
SDK installed. Mark Miesfeld always recommended this one:

http://www.microsoft.com/en-us/download/details.aspx?id=8442

Rick



On Sun, Apr 30, 2017 at 3:43 PM, Rony G. Flatscher 
wrote:

> While following the build instructions for Windows, the following error
> occurs while building the 32-bit Windows version:
>
> [ 61%] Building CXX object 
> CMakeFiles/orexxole.dir/extensions/platform/windows/ole/events.cpp.obj
> events.cpp
> F:\work\svn\oorexx\main\trunk\extensions\platform\windows\ole\events.cpp(51): 
> fatal error C1083: Datei (Include) kann nicht geöffnet werden: "agtctl_i.c": 
> No such file or directory
> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
> Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> The file "agtctl_i.c" cannot be opened. Having multiple Visual Studios and
> Microsoft SDKs on my machine, I was able to find one in a "c:\Program Files
> (x86)\Microsoft SDKs\Windows\v7.1A\Include", so I added that as the last
> path on the INCLUDE environment variable. Building appeared to have gone on
> successfully.
>
> However, when building "oodPackageEntry.cpp.obj" I hit the following
> redefinition error:
>
> [ 85%] Building CXX object 
> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
> oodPackageEntry.cpp
> F:\work\svn\oorexx\main\trunk\extensions\platform\windows\oodialog\oodPackageEntry.cpp(444):
>  error C2373: "__pfnDliFailureHook2": Neudefinition; unterschiedliche 
> Modifizierer
> E:\Programme\Microsoft Visual Studio 14.0\VC\INCLUDE\delayimp.h(141): note: 
> Siehe Deklaration von "__pfnDliFailureHook2"
> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
> Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> What would be the proper setup/step to get ooRexx compiled for 32-bit
> Windows?
>
> Or with other words: how should I set up MS Visual Studio 14 to become
> able successfully compile 32-bit ooRexx?
>
> ---rony
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

2017-05-01 Thread Erich Steinböck

Rony, I'm successfully building ooRexx 5.0 (both 32- and 64-bit) with
Visual Studio 2015 (Community).
You might want to check the "How to build" documents I've written in our
ooRexx Wiki at https://sourceforge.net/p/oorexx/wiki/how-to-build-oorexx/

My version of \Program Files (x86)\Microsoft Visual Studio
14.0\VC\include\delayimp.h has only got 130 lines, not at least 141 lines
as your message suggests.

This delayimp.h defines pfnDliFailureHook2 as follows:

typedef FARPROC (WINAPI *PfnDliHook)(
unsigneddliNotify,
PDelayLoadInfo  pdli
);

ExternC PfnDliHook   __pfnDliFailureHook2;

Maybe you can test on a system with just one version of Visual Studio
installed (and preferably in English).

On Sun, Apr 30, 2017 at 9:43 PM, Rony G. Flatscher 
wrote:

> While following the build instructions for Windows, the following error
> occurs while building the 32-bit Windows version:
>
> [ 61%] Building CXX object 
> CMakeFiles/orexxole.dir/extensions/platform/windows/ole/events.cpp.obj
> events.cpp
> F:\work\svn\oorexx\main\trunk\extensions\platform\windows\ole\events.cpp(51): 
> fatal error C1083: Datei (Include) kann nicht geöffnet werden: "agtctl_i.c": 
> No such file or directory
> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
> Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> The file "agtctl_i.c" cannot be opened. Having multiple Visual Studios and
> Microsoft SDKs on my machine, I was able to find one in a "c:\Program Files
> (x86)\Microsoft SDKs\Windows\v7.1A\Include", so I added that as the last
> path on the INCLUDE environment variable. Building appeared to have gone on
> successfully.
>
> However, when building "oodPackageEntry.cpp.obj" I hit the following
> redefinition error:
>
> [ 85%] Building CXX object 
> CMakeFiles/oodialog.dir/extensions/platform/windows/oodialog/oodPackageEntry.cpp.obj
> oodPackageEntry.cpp
> F:\work\svn\oorexx\main\trunk\extensions\platform\windows\oodialog\oodPackageEntry.cpp(444):
>  error C2373: "__pfnDliFailureHook2": Neudefinition; unterschiedliche 
> Modifizierer
> E:\Programme\Microsoft Visual Studio 14.0\VC\INCLUDE\delayimp.h(141): note: 
> Siehe Deklaration von "__pfnDliFailureHook2"
> NMAKE : fatal error U1077: "E:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe": 
> Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
> NMAKE : fatal error U1077: ""E:\Programme\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe"": Rückgabe-Code "0x2"
> Stop.
>
> What would be the proper setup/step to get ooRexx compiled for 32-bit
> Windows?
>
> Or with other words: how should I set up MS Visual Studio 14 to become
> able successfully compile 32-bit ooRexx?
>
> ---rony
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] First analyzing results (Re: Some numbers (Re: Ad "Error 5: System resources exhausted."

2017-05-01 Thread Rony G. Flatscher

On 01.05.2017 16:19, Rick McGuire wrote:
> If the parsing event handler is storing references to any of the proxy 
> objects in other ooRexx
> objects (arrays, etc.), those objects will still be anchored. The uninits are 
> definitely
> interleaved with execution in the sample program, so problems from this point 
> are probably in how
> the code in question is managing the object references.
No, there are no references on the ooRexx side that would keep them referenced 
(cf. the short demo
Rexx program is enclosed). The native code does not refer to them either beyond 
the
AttachThread/DetachThread section (the Java arguments are turned into Rexx 
arguments which get
stored in a RexxArray and supplied in the SendMessage call).

---

I re-ran the SAX test program after noticing that running the 
test01.rex/test_gc.dll combo, no
uninits are run while being in native code and while creating 100,000 to 
1,000,000 ABC objects that
immediately turn into garbage. As each ABC object gets created in a single 
AttachThread/DetachThread
section, the created ABC object should turn to garbage after the DetachThread 
call as neither the
Rexx test script nor the native code would refer to it anymore.

The AttachThread/DetachThread invocations in native code occur in the same 
thread that invoked the
external Rexx function ("call CreateABCObjects nr"). And it seems that only 
upon return from the
CreaetABCObjects-call (or probably after ending the Rexx program) the ABC 
uninits start to run.

---rony


>
> On Mon, May 1, 2017 at 10:14 AM, Rony G. Flatscher  > wrote:
>
> Retested today quite exhaustively (see below), and indeed I cannot create 
> any Rexx crashes
> anymore, which is *really* great!
>
> ---
>
> However, retesting today, I just realized, that all the uninits only 
> start to run *after* the
> test script ends!
>
> Running the test script on the patched interpreter with "test01.rex 2>&1 
> | gvim -" will yield
> (the "duration:" output is the last statement of the program):
>
>   * 100.000 ABC objects created in native code
>
> ... InitializeRII(): gRI=[7DBA8178] started: 
> 2017-05-01T14:57:18.003000 ... about to
> create [10] ABC objects by native code... *ended:* 
> 2017-05-01T14:57:33.703000
> duration: 00:00:15.70 *** ::UNINIT:
> [ABC-from_native_createTestObject-88726]@[FF95351217] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-89421]@[FF9526FCC7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-90116]@[FF9518E777] ... cut 
> ...
>
>   * 250.000 ABC objects created in native code
>
> ... InitializeRII(): gRI=[7DBA8178] started: 
> 2017-05-01T14:51:54.135000 ... about to
> create [25] ABC objects by native code... ended: 
> 2017-05-01T14:53:42.775000 duration:
> 00:01:48.64 *** ::UNINIT:
> [ABC-from_native_createTestObject-42126]@[FF879A4AE7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-195246]@[FFA7279DCF] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-12005]@[FF829BF5F7] ... cut 
> ...
>
>   * 500.000 ABC objects created in native code
>
> ... InitializeRII(): gRI=[7DBA8178] started: 
> 2017-05-01T14:57:46.935000 ... about to
> create [50] ABC objects by native code... ended: 
> 2017-05-01T15:04:06.482000 duration:
> 00:06:19.547000 *** ::UNINIT:
> [ABC-from_native_createTestObject-42126]@[FF879A4AE7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-120397]@[FF9A8F9EC7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-195246]@[FFA7279DCF]... cut 
> ...
>
>   * 750.000 ABC objects created in native code
>
> ... InitializeRII(): gRI=[7DBA8178] started: 
> 2017-05-01T15:05:09.713000 ... about to
> create [75] ABC objects by native code... ended: 
> 2017-05-01T15:25:33.533000 duration:
> 00:20:23.82 *** ::UNINIT:
> [ABC-from_native_createTestObject-166273]@[FF9DD3FCF7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-416933]@[FFC109519F] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-516807]@[FFCE93FC07] ... 
> cut...
>
>   * 1.000.000 ABC objects created in native code
>
> ... InitializeRII(): gRI=[7DBA8178] started: 
> 2017-05-01T15:28:40.547000 ... about to
> create [100] ABC objects by native code... ended: 
> 2017-05-01T15:58:49.271000 duration:
> 00:30:08.724000 *** ::UNINIT:
> [ABC-from_native_createTestObject-795014]@[FFFAFEA5D7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-520973]@[FFCAA6A6C7] *** 
> ::UNINIT:
> [ABC-from_native_createTestObject-240938]@[FFAD9AA757]
>
> (In all tests the number of uninits that ran upon program completion 
> corresponds

Re: [Oorexx-devel] First analyzing results (Re: Some numbers (Re: Ad "Error 5: System resources exhausted."

2017-05-01 Thread Rony G. Flatscher

Retested today quite exhaustively (see below), and indeed I cannot create any 
Rexx crashes anymore,
which is *really* great!

---

However, retesting today, I just realized, that all the uninits only start to 
run *after* the test
script ends!

Running the test script on the patched interpreter with "test01.rex 2>&1 | gvim 
-" will yield (the
"duration:" output is the last statement of the program):

  * 100.000 ABC objects created in native code

... InitializeRII(): gRI=[7DBA8178] started: 2017-05-01T14:57:18.003000 ... 
about to create
[10] ABC objects by native code... *ended:* 2017-05-01T14:57:33.703000 
duration:
00:00:15.70 *** ::UNINIT: 
[ABC-from_native_createTestObject-88726]@[FF95351217] ***
::UNINIT: [ABC-from_native_createTestObject-89421]@[FF9526FCC7] *** 
::UNINIT:
[ABC-from_native_createTestObject-90116]@[FF9518E777] ... cut ...

  * 250.000 ABC objects created in native code

... InitializeRII(): gRI=[7DBA8178] started: 2017-05-01T14:51:54.135000 ... 
about to create
[25] ABC objects by native code... ended: 2017-05-01T14:53:42.775000 
duration:
00:01:48.64 *** ::UNINIT: 
[ABC-from_native_createTestObject-42126]@[FF879A4AE7] ***
::UNINIT: [ABC-from_native_createTestObject-195246]@[FFA7279DCF] 
*** ::UNINIT:
[ABC-from_native_createTestObject-12005]@[FF829BF5F7] ... cut ...

  * 500.000 ABC objects created in native code

... InitializeRII(): gRI=[7DBA8178] started: 2017-05-01T14:57:46.935000 ... 
about to create
[50] ABC objects by native code... ended: 2017-05-01T15:04:06.482000 
duration:
00:06:19.547000 *** ::UNINIT: 
[ABC-from_native_createTestObject-42126]@[FF879A4AE7] ***
::UNINIT: [ABC-from_native_createTestObject-120397]@[FF9A8F9EC7] 
*** ::UNINIT:
[ABC-from_native_createTestObject-195246]@[FFA7279DCF]... cut ...

  * 750.000 ABC objects created in native code

... InitializeRII(): gRI=[7DBA8178] started: 2017-05-01T15:05:09.713000 ... 
about to create
[75] ABC objects by native code... ended: 2017-05-01T15:25:33.533000 
duration:
00:20:23.82 *** ::UNINIT: 
[ABC-from_native_createTestObject-166273]@[FF9DD3FCF7] ***
::UNINIT: [ABC-from_native_createTestObject-416933]@[FFC109519F] 
*** ::UNINIT:
[ABC-from_native_createTestObject-516807]@[FFCE93FC07] ... cut...

  * 1.000.000 ABC objects created in native code

... InitializeRII(): gRI=[7DBA8178] started: 2017-05-01T15:28:40.547000 ... 
about to create
[100] ABC objects by native code... ended: 2017-05-01T15:58:49.271000 
duration:
00:30:08.724000 *** ::UNINIT: 
[ABC-from_native_createTestObject-795014]@[FFFAFEA5D7] ***
::UNINIT: [ABC-from_native_createTestObject-520973]@[FFCAA6A6C7] 
*** ::UNINIT:
[ABC-from_native_createTestObject-240938]@[FFAD9AA757]

(In all tests the number of uninits that ran upon program completion 
corresponds to the number of
ABC objects created except for the last one where two uninits are missing.)

Re-running the original program (using a Java SAX parser that causes callbacks 
into ooRexx via
JNI/native code) that caused the "Error 5: System resources exhausted" on the 
32-bit ooRexx
interpreter still causes the error (around parsing the 84900th XML element).

---rony



On 30.04.2017 22:18, Rony G. Flatscher wrote:
>
> Applying your patch and re-running the problematic test-cases, it seems to be 
> indeed the case that
> the problem is solved! Many thanks!
>
> ---rony
>
>
> On 30.04.2017 13:00, Rony G. Flatscher wrote:
>> On 30.04.2017 12:53, Rick McGuire wrote:
>>> I want to verify something first. In this scenario, Rexx code makes a call 
>>> to a Java method
>>> (i.e., the parser) which then makes a lot of callbacks all on the same 
>>> thread?
>> Yes.
>>
>>> If so, then I think I might see where the problem could be. The code that 
>>> handles nested thread
>>> attaches (that is, attaching to a thread that already exists) appears to 
>>> hold on to any
>>> allocated objects until it returns to the original exit point (in your 
>>> case, the initial call to
>>> the parser). 
>>>
>>> This may take a little while to figure out the details of a fix, but I at 
>>> least know where to
>>> start. You might want to open a bug indicating there appears to be an
>>> AttachThread()/DetachThread() memory leak.
>> Opened a bug: .
>>
>> ---rony
>>
>>>
>>> On Sun, Apr 30, 2017 at 6:38 AM, Rony G. Flatscher >> > wrote:
>>>
>>> Having slept I went over the debug statements, just to learn that I 
>>> concluded wrongly
>>> yesterday: the reference decreases did not come from the Rexx objects 
>>> with uninits, but from
>>> the Java side! :(
>>>
>>> With new debug statements on the Rexx side (in the destructores) it is 
>>> clear that no proxy
>>> Rexx

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] Question ad creating 32-bit ooRexx for Windows

Re: [Oorexx-devel] First analyzing results (Re: Some numbers (Re: Ad "Error 5: System resources exhausted."

Re: [Oorexx-devel] First analyzing results (Re: Some numbers (Re: Ad "Error 5: System resources exhausted."

9 matches

Site Navigation

Mail list logo

Footer information