Compiling the JWA and JWSCL

Recently I decided to try to incorporate Windows Job Objects into a project to artificially limit the amount of memory available to an application so I could test it’s behaviour under such circumstances.  Originally I had intended on using M$’s Application Verifier for that purpose, but it lacks any real documentation, and apparently does not provide this exact functionality (the low resource utilization provides random failures).

I thought I would use the JWSCL library since it has a class that wraps Job Objects.  Getting it to compile was unfortunately not so straightforward.

To start with, the JWSCL requires the JWA library, so you need to get that compiled first.  I had no luck compiling the downloaded version so I pulled the current source from the trunk.  Then I followed the READMEFIRST.txt file for the JWA library, but got a compilation error:

 E1025 Unsupported language feature: 'import of DLL symbol by ordinal' "

Googling this I stumbled across a reply to a post from Peter Below explaining “This is caused by a change in defaults for the project options. Call up the options dialog, select the Output - C/C++ page, and make sure the “C/C++ output file generation” entry is set to “Generate DCUs only”. I toggled the option, and voila! The JWA compiled.

Then I tried the JWSCL and got a “[dcc32 Error] JwsclLsa.pas(121): E2010 Incompatible types: ‘Cardinal’ and ‘NativeUInt’. Seems that a THandle is used for some definitions and equates to a NativeInt in XE4, but in other places handles are defined as Cardinals. TJwSecurityLsa uses a mixed definition of a property and changing it to use THandle just opens up the proverbial rabbit hole.

I ended up abandoning my attempt to get JWSCL compiling in part because I downloaded another implementation of the Job Object API from here.  Thanks ZigiZ.  It’s unfortunate that such libraries are so difficult to maintain for multiple compilers. I know from personal experience with hcOPF that it is very difficult to change a library and maintain a good user experience for developers using a multitude of Delphi versions.

Now if only I could find out if it is possible to add a process to a job from that process (I get a security error) :-(

6 Responses to “Compiling the JWA and JWSCL”

  1. kmorwath Says:

    Aren’t they open source libraries? Why Delphi developers always wait for someone else to maintain open source libraries? Feel free to submit your patches and share them with the community…. that’s the beauty of open source, isn’t it?

  2. Larry Hengen Says:

    @kmorwath,

    Yes it is an open source library and I could certainly investigate, fix the issue, and submit a patch or suggestion to improve the project. The issue is that I have core work to get done and a finite amount of time to do that and all the other things I have to or want to do. Often the path of least resistance is chosen for that reason.

    I could also have translated the Windows API headers and wrapped that in Delphi objects too, but that would also be reinventing the wheel which as you know is contrary to a fundamental law in programming.

    As I indicated in the article, I found an alternate library that did just what I wanted. No point in spending any additional time on the issue, other than giving the project a heads up.

  3. Kmorwath Says:

    “issue is that I have core work to get done” etc. etc. is the classic excuse of open source exploiters - those Always praising the value of open source, the value of the community, etc. etc. but contributing nil to them.
    Ok, you found another library doing it. The day you need something in JWA/JWCL that work you’ll add them too and your sw will use three libraries instead of one. And then maybe you’ll add a fourth one for some more APIs support… sure, you didn’t reinvent the wheel, but another fundamental law in programming is keeping the codebase compact and coherent - and adding more and more libraries found here and there is not the way….
    Sometime a little time spent on fixing issues in a good library repays you well later, and if more and more people do that, the library improves and is kept up to date. Otherwise, you end up with a lot of so-so libraries without proper maintenance that covers just a little of your needs.
    That’s another reason many developers fly away from Delphi….

  4. Larry Hengen Says:

    @Kmorwath,

    Yes I have used (exploited apparently to you) open source libraries. I have also open sourced an OPF project that I have spent over 5 years developing, and I continue to enhance that offering. Just because I have chosen to spend my time on another open source project where I can more readily contribute, doesn’t mean I should be subjected to a personal attack, or that you should make statements of fact about me when you obviously don’t know the facts.

  5. ghost Says:

    so i tried to compile and install the bpl.
    using xe7 failed.
    error:
    [dcc32 Error] JwaWinDNS.pas(1888): E2033 Types of actual and formal var parameters must be identical

    the procedur

  6. ghost Says:

    https://forums.embarcadero.com/message.jspa?messageID=694157

    this guy build it in xe7.
    and following his wise words of

    DWORD(pout^)

    and it works.
    and if you want any project to compile with it , you need to add some dcus to the library, and the some units to search path.

Leave a Reply