Gil: thank you very much for your update! Will be interested in your final solution, also in your findings and examples using CMake, as I have not had time to look into that corner.
Would it be possible that you write an ooRexx-Sourceforge blog about your work, findings and solutions? ---rony On 03.02.2017 21:30, Gil Barmwater wrote: > I know it has been a while since I gave an update on this topic so I've > included the last one I posted to refresh everyone's memory. > > As noted in the last post, I was at the point of writing my own C++ code > for some native methods. I chose to implement the methods that I had > previously written using GCI to change the color attributes of the > Windows console. Even though this is somewhat obsolete with Windows 10 > - ANSI escape sequences are again supported to do color highlighting - > it has always been my goal to "complete" the original effort so that it > would work on 64-bit versions of ooRexx as well (GCI is limited to > 32-bit). By writing native methods, I would be able to compile them for > both addressing modes. By keeping the same interfaces, I only needed to > replace the GCI-based methods in the Class definition with the new > native method definitions (one liners!). There are three methods > involved, one that takes no arguments but returns a value, one that > takes the value returned by the first method and returns a (different) > value, and finally one that again takes the value returned by the first > method but returns nothing. Using Rony's examples and the work I did > for the GCI-based methods, it was fairly straightforward to come up with > the C++ code and the .def file. I took part of Rony's makefile and was > able to get a 32-bit DLL to build! Making the noted changes to the > Class definition, my test program ran successfully! > > I still had lots of questions about the makefile contents so I did some > research which included looking at the samples\native.api folder that is > installed with ooRexx. This example contains code and a makefile which > is very different than Rony's. It distinguishes between building a > debug version and a "release" version while Rony's has a choice between > 32- and 64-bit versions. I decided that my "general" build process > should allow for all four combinations of addressing mode and > debug/"regular" versions. I also read that building "out of source" is > recommended - doing the build in an empty directory rather than the > directory where the source files are located. The advantage cited was > to allow the deletion of the build files w/o the possible accidental > loss of a source file. For me, this structure would also allow me to > build both 32- and 64-bit versions without having to adopt a naming > convention or renaming the .dll since each version would be in its own > directory. I spent some time writing a Rexx program to automate the > process: check that the specified build "type" was valid, creating the > appropriate subdirectory if needed, passing the correct argument to the > vcvarsall.bat file to set up the compiler/linker for the correct target > addressing mode, setting an environmental variable for use by the > makefile to control the flags for debug/non-debug compiling and linking, > and finally running nmake. After tweaking the makefile so that it > reflected the fact that the source files were now in the parent > directory, I got it to build a 32-bit .dll which worked with my test > program. > > However, when I tried to build a 64-bit .dll, I ran into a (compile) > problem. It turned out that the first method returns a value called a > handle which is more like a pointer than an integer. In 32-bit mode, > pointers and integers are the same size but that is NOT true in 64-bit > mode. So I needed to change my code to use the new "types" added to the > ooRexx API. After changing the type from "int" to "uintptr_t" wherever > the handle was referenced, the compile was clean in both 32- and 64-bit > versions. I was able to install the latest 64-bit ooRexx 5.0.0 beta and > verify that my test program, using the 64-bit .dll, ran successfully. > So goal accomplished! > > I still need to decide on the structure and contents of the makefile > however. There are flags which are now considered obsolete which I want > to remove and I need to put in the logic for debug/regular build flags. > I'd like some opinions on structure as well. Rony's sample makefile > does the compile and link back-toback. The sample in the native.api > directory, does them separately. I believe the terminology is "target" > and "dependency" so that the .exe or .dll "target" is dependent on the > .obj and the .obj "target" is dependent on the .cpp. Having separate > "rules" would let you do just the compile or just the link or both if > you desire. In complex cases, this might be advantageous but for simple > bits of code (like mine), running both commands is easier to understand. > > I've also written a simplified version of my Class that only uses two > (native) methods that might be suitable for inclusion in the native.api > samples. Once I decide on the contents of the makefile, I'll make the > pieces available for review. > > Thanks for reading this far! Comments or questions are welcome. > > PS I've started to look at CMAKE but haven't yet done any experimenting > with it so far. > > On 9/17/2016 1:29 PM, Gil Barmwater wrote: >> Success! I have now been able to build and run Rony's examples from >> last year's Symposium. Here is what I did to get there. >> >> Having discovered that my Visual Studio Express installation was >> incomplete(!), I decided to "start over" rather than try to "fix" it. I >> uninstalled Visual Studio from Control Panel -> Programs and Features. >> There were messages about third party installers possibly leaving items >> still installed but I did not see anything obvious. There were items >> that had the same date as when I had installed Visual Studio but they >> might have just been updates so I did not uninstall them. In any case, >> they did not affect what I did next. >> >> I went back to Rene's presentation and clicked on the link he supplied >> for Visual Studio Community. This seems to be the most recent free MS >> Visual Studio product and, although Express is still supported, I >> suspect future support will be concentrated on Community. And I wanted >> to be sure that the ooRexx project would build correctly (when I get to >> that point) with the newest free Visual Studio. I selected the custom >> install and picked just one item under Programming Languages - Visual >> C++/Common Tools. I also selected the Tools (1.4.1) & Windows 10 SDK >> under Windows and Web/Universal Windows Application Development because >> I seem to remember comments on this list in the past to the effect that >> it was needed for something (perhaps debugging?). So I only had two >> items checked in the custom dialog. The install process started and as >> packages finished downloading, they were installed in parallel. Even so, >> the download portion took over an hour and then the remaining installs >> and updates took another hour! Glad I didn't select anything else from >> the menu! >> >> I located the "shortcut" for a command prompt which would run the >> VCVArsAll.bat and it ran successfully so I knew I now had the C++ tools >> I needed. I then found the full path name to that .bat file and put it >> in a short .cmd file in the folder where I had put the source for Rony's >> examples. When I ran the that .cmd file and then the NMAKE command he >> documented in his presentation, the DLLs were built and I ran the 4 test >> cases he supplied without error. >> >> The next step for me is to experiment with writing my own native methods >> to be sure I understand all the parts I need - a .cpp file, a .def file >> and a makefile - to get a DLL I can reference from a ::method statement. >> >> So it will be a while before I am ready to get all the other tools to >> attempt to build ooRexx from an SVN checkout. I'll post again when I'm >> at that point. >> ------------------------------------------------------------------------------ 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
