Mike Fechner (Consultingwerk) asked a question.

August 22, 2025 at 4:07 PM
Additional ADE source code now xcoded?

Looks like in 12.8.9 and 12.8.18 the following files that used to be open-source are now xcoded/encrypted:

 

src/adecomm/_isfld.i

src/adecomm/_istbl.i

src/prodict/dump/_lod_raw.i

src/prodict/dump/loaddefs.i

src/prodict/misc/_rundift.i

src/prodict/misc/_rundump.i

src/prodict/misc/_runload.i

src/prodict/misc/_runsylk.i

src/prodict/ora/_runload.i

 

May I ask why?

 

Will the same happen to additional bits of the ADE source code in the future?

  • 12 answers
  • 254 views
Stefan Drissen, Matt Gilarde, and 3 others like this.

  • Talha Masood (Progress Software)

    Hi,

     

    Quick update!

    We have reverted the changes. Please let me know if you see any issues with the ADE source code.

    Thanks for all the comments!

     

    Regards,

    Talha

    Selected as Best

  • Talha Masood (Progress Software)

    Hello @Mike Fechner (Consultingwerk)​,

     

    These source files are shipped as part of OpenEdge product as xcoded. We decided to post them publicly in same format.

    To answer your second question, we are not xcoding any other file.

     

    Thanks,

    Talha

  • Lieven De Foor (b-inside)

    In 12.8.8 these files were available as plain text.

    Why are we no longer allowed to see what's in there?

    • Frank Meulblok (Customer)

      From the other thread where this came up (https://community.progress.com/s/question/0D5Pb00002mP5frKAC/ade-openedge-1289-and-12218-development-tools-source-code) , the goal was consistency between how the code is published in different channels (shipped with OE vs. github).

       

      But based on that, I only have a rephrased question: Why was the choice made to standardize on the encrypted version instead of the plain text version?

      At first glance, I don't see anything in there that actually needs to be confidential..

      • Talha Masood (Progress Software)

        Hi @Frank Meulblok (Customer)​,

         

        I agree with your point, there’s nothing confidential here. The decision was made to ensure consistency across the codebase, so we updated the include files format to match the ones placed in the installation directory.

         

        Thanks,

        Talha

      • Mike Fechner (Consultingwerk)

        So then the take away of this is:

         

        • there is nothing confidential
        • and customers would like to keep them unencrypted

         

        So, would it be possible to get those files back - unencrypted?

         

        Adn as you seem to want to protect us from using what _may_ be removed in the future, please add a deprecated comment to those include files.

      • Talha Masood (Progress Software)

        Hello @Mike Fechner (Consultingwerk)​,

         

        Okay, to initiate this discussion internally, I need some input from your side.

        Could you or anyone involved in this discussion, please share how these include files are being used within your ABL application? Additionally, what potential impact might there be if we decide to continue publishing them as XCODED?

        Essentially, I’m trying to get a clear understanding of the use case for these include files.

         

        Regards,

        Talha

      • Gilles Querret (Riverside Software)

        As their name implies, source code repositories are meant to host source code. Pushing binary assets defeats the purpose of code repositories, as you can't see if a file has changed or not, and what has changed between two releases. If those files are useless, you can start by adding a comment at the beginning of the file to flag them as deprecated (and how to switch to something that is maintained), and delete them in a couple months.

        A code repository doesn't have to match what is shipped in the product. Otherwise, you would just push PL to the code repository.

      • Mike Fechner (Consultingwerk)

        @Talha Masood (Progress Software)​ 

         

        We have been using the ADE source code to

         

        • customize/enhance them
        • look for "weird behavior" (potential bugs)
        • educational purposes

         

        I'm absolutely fine when some of the include files are going away - in fact as a OOABL junkie I would love to see only class based variants. But while they are still part of the product, I really see no reason to encrypt them.

         

        In all honesty, do you think that encrypting them is the right way to tell us they are deprecated?

         

        Generally that should be done through comments or annotations. Not by using a technique that was introduced to protect the authors IP. That's just the wrong tool for the job.

      • Talha Masood (Progress Software)

        Hi @Mike Fechner (Consultingwerk)​,

         

        I acknowledge that encrypting content is not an appropriate method for communicating deprecation to users. My original intent was to maintain consistency across the system. However, in light of the constructive feedback received, I have initiated a discussion to revert the changes. I will endeavor to provide an update at the earliest.

         

        Regards,

        Talha

10 of 12