Announcement

Collapse
No announcement yet.

DLL embedded into powerbasic exe?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • DLL embedded into powerbasic exe?

    Embedding a dll to use inside of an exe.
    Because there has been a lot of time since the discussion of this subject I am asking now what are the choices to use a dll that can possibly in an exe.
    I have a program that makes use of a couple of DLLs and it would be great to have these DLL files found without error.
    I have never had a use till now.
    I prefer not to extract the DLLs to disk if possible. I plan on using the exe in batch routines on many different windows systems.
    Thanks for any info in advance.
    p purvis

  • #2
    Paul,

    I have seen it done a long time ago by Jeremy Collake but it is at best an unreliable technique. If they are your DLLs I would embed the code into the exe, if not, I would place them somewhere in the system where your app could find them.
    hutch at movsd dot com
    The MASM Forum

    www.masm32.com

    Comment


    • #3
      Thanks Steve for your words.
      p purvis

      Comment


      • #4
        Have a look at http://enigmaprotector.com/
        /Fim W.
        Fim Wästberg

        Comment


        • #5
          Originally posted by Fim Wästberg View Post
          Have a look at http://enigmaprotector.com/
          /Fim W.
          It looks like their free Enigma Virtual Box meets Paul's requirements. (and did I mention, its free!)

          http://enigmaprotector.com/en/aboutvb.html

          Application virtualization system for Windows. Enigma Virtual Box enables application files and registry to be consolidated in a single executable file, without loss of efficiency and without virtualized files having to be extracted to the HDD. Enigma Virtual Box is a free application that supports both x86 and x64 binaries.

          Comment


          • #6
            Originally posted by Paul Purvis View Post
            Embedding a dll to use inside of an exe.
            Because there has been a lot of time since the discussion of this subject I am asking now what are the choices to use a dll that can possibly in an exe.
            I have a program that makes use of a couple of DLLs and it would be great to have these DLL files found without error.
            I have never had a use till now.
            I prefer not to extract the DLLs to disk if possible. I plan on using the exe in batch routines on many different windows systems.
            Thanks for any info in advance.

            For what it's worth, back almost 20 years ago I used to embed dll's into the resource file of a Power Basic exe, dynamically extract the dll's as needed into the exe's directory, dynamically load & unload the call to whatever sub/function in them I needed that second, then delete . This was to obscure the existence of the dlls from casual observers. (Don't ask. ) I never observed any issues with this, other than it's obvious inefficiency. Pretty much all you had to do was create and compile an RC file with the dll file as a named resource using a line like this for each file:
            ITEST RCDATA DISCARDABLE "c:\DEMO.DLL"

            When I needed to extract the dll, I had a small function (~20 lines including all the local declares) similar to Stuart's GET RCDATA section he has here:
            https://forum.powerbasic.com/forum/u...ces-from-a-dll

            that would pass the dll back as a large string. At that point, you could write it to disk or ram-disk to actually run. Haven't done more than play briefly with Enigma Virtual Box. Looks nice, especially the ability to not virtualize calls to the System Registry, although I have never tried seeing how it handles dealing with the registry redirection stuff one occasionally has to deal with (32-bit applications in a 64-bit Windows environment).
            Michael Burns

            Comment


            • #7
              Just tried it out, for 20k of binaries, it produces a 401k executable, YUK. About to be converted to free disk space.

              There is a better option without needing a pile of junk like that. CreateFile() and with the argument "dwFlagsAndAttributes" use the flag "FILE_ATTRIBUTE_TEMPORARY" that is designed to stay in memory where possible so its fast. When you are finished with the file, delete it. I have used this in a number of places and it works fine. Mainly for image files in JPG format that are loaded with GDI+ into a bitmap.

              About the only problem I can see is some AV scanners may try and block writing an exe or dll file to disk.


              hutch at movsd dot com
              The MASM Forum

              www.masm32.com

              Comment


              • #8
                Hi Paul

                My company uses Enigma Protector's Virtual Box to protect and encapsulate 20 to 30 dll files together with an exe file to form ONE large single exe file.
                This big single exe file runs very well and that we encounter no problem when we deploy to our customers.

                You need to purchase Enigma Protector to have a good commercial product and not to use its free Virtual Box product. The Enigma Protector product
                truly protect your dll and exe files against hackers. It has been tested many times. We have also tried other products like Themida , PELock , PECompact and MoleBox
                which didn't make the grade. Anyway, Molebox is already dead, while Themida doesn't protect your software properly, PELock is a useless product your exe file
                cannot run after its ecapsulation! . PECompact only compact and compress your files and can be easily hacked.


                You can check out the list of file compressors here, but as you see most of them are not upgraded for many years and are dead.

                https://en.wikipedia.org/wiki/Executable_compression




                Comment


                • #9
                  I prefer not to extract the DLLs to disk if possible.
                  This is either old thinking, with absolutely no current basis for avoiding; or simply an old wives' tale driving this "desired restriction."

                  I have used DLLs as program resources multiple times.

                  See it in action? Go here => http://www.providerpaymentpartner.com and "take the PPPS tour" using the link near the bottom of the page. ( http://www.providerpaymentpartner.com/demo/pppstour.exe.) That will ask you to run or download an EXE. That EXE is performing a runtime extraction of a DLL. (See complete discussion here: One From Column A, One from Column B.. (When it runs you will see file~zlib.dll in your temp directory.) (Or a name kind of like that).

                  I just extract to the folder designated by the GetTempPath() WinAPI call and perform a LoadLibrary() on the file. Works Good.

                  This same technique (store DLL in an EXE) is also used by Inno Setup to support the "external" option of setup scripts. See (here) Inno Setup:Commented Installation Script June 8 2003 (Inno setup does NOT use the "resource" approach in the generated "setup.exe" , it does it another way.

                  The bottom line is, there is no reason to avoid storing a DLL as a program resource, extracting it to disk at runtime and using any of the exported functions; and the programming skills necessary to do this are pretty basic so that is not a burden, either. .

                  ALSO: IMO it is NOT a good idea to prejudice a technique ("...prefer to not extract to disk....." ) before you've even tried it (in context, using PowerBASIC's feature set) , which I suspect is the case here.


                  MCM

                  Comment


                  • #10
                    But Michael, you're weird becuse you're obviously not concerned about all those clandestine people who meticulously scan and make a copy of every single byte that's written to their disks stealing all your stuff, and, I dunno, using it in their art exhibition or something?

                    ---

                    Yes I read the OP and he's trying to avoid config issues not 'They'll steal my codez". Anyway, there's debugging built into Windows to determine why your dll don't load - this uses Visual Studio but you can use DebugView or other OutputDebugString viewer http://blog.airesoft.co.uk/2011/05/d...loader-lapses/

                    Comment


                    • #11
                      I have a real simple rule: if you can read executable code and make something of it, you win. It's not worth my time to try to 'beat' you.

                      I'm still stuck on the best way to prevent piracy being to "provide a useful product at a fair price with good support." Silly me, I guess.

                      MCM


                      Comment


                      • #12
                        Originally posted by Michael Mattias View Post
                        I'm still stuck on the best way to prevent piracy being to "provide a useful product at a fair price with good support." Silly me, I guess.
                        Also, not every hacked copy of a program is a lost sale.
                        You also need to ask yourself, "how many people running hacked software would have actually bought the original if no one had hacked it?"

                        One really has to wonder how much it has cost so far for all the anti-hacking effort that has gone into an certain oft talked about but never identified piece of software and how many extra sales that effort has generated. (Still waiting to find out what this vaporware actually is)




                        Comment


                        • #13
                          Whose DLLs ?

                          3rd party DLLs, I see a time-of-installation advantage. (slight)

                          Your own DLLs (the programmer's); use the DLL source code as an #INCLUDE file (remove ALIAS and EXPORT) or compile to SLL to compile into the program. Still only one .exe to distribute, no "tricks" to make DLL code usable, and no compiled-in alias names.
                          Dale

                          Comment


                          • #14
                            The reasons I can think of for using a DLL are various but it has always been the case that if you can avoid it, you do so. Reasons include a DLL that you did not create, a DLL that you share between multiple executable applications or tasks like multi-lingual DLLs that are selected on the basis of user choice. If you wrote the DLL yourself in the same language as the exe that calls it, then there is little reason not to include the DLL code in the exe and not use a DLL.

                            If you really have to use a DLL that you did not create or one built in a different language, there are multiple ways of embedding it into an exe, resource storage or an ASMCODE DB sequence and if you want to protect the DLL from hacking while its on disk, check for its existence at startup, delete it if its still on disk then write the stored version to disk and you are safe from it being routinely hacked. It would be extremely difficult to hack the stored DLL while its in the exe file that calls it.

                            In line with Stuart's comment which I agree with, there is a vast amount of software that no-one would waste their time hacking. If the software is aimed at a very narrow target market and is high cost/high complexity software like CAD and similar, then the author can afford to build each version to exactly what the customer wants including their name, some form of dongle if they require it and install it with the usual complex mess of files and directories and registry entries that make it near impossible to hack.

                            Now if you have a product that is actually worth hacking, make a light version that is useful and not a money squarking piece of crippleware and if it works OK, more often than not, a user will buy the full version. I regularly buy bits of software, often for peanuts if the light version works OK and is not squarking money grovelling trash. If the light version is the former, I am getting ever faster at uninstalling it and therefore hacking it back to free disk space.

                            Security wrappers have this problem, by the time you buy it, there is already a downloadable hack for it posted on the internet, if you really and truly need anti hacking technology that will slow up an experienced hacker, you will have to write it yourself and few know enough to do that.
                            hutch at movsd dot com
                            The MASM Forum

                            www.masm32.com

                            Comment


                            • #15
                              I presented a simple method to embed a dll in an executable.
                              I have attached the sources of the program in a zip in this post : https://forum.powerbasic.com/filedata/fetch?id=745200

                              It is probably possible to extract the dll to a virtual disk if you do not want to write to the disk.

                              It was in this post : Community Home Community User to User Discussions Programming ".exe + .dll = exe"

                              Comment


                              • #16
                                My reasons are so that libraries to run the application are in place to support the exe do its job wherever the program is run. The reasons have zero to do with privacy concerns.
                                I had seen where a program "GHOSTPCL"' had been repackaged with its DLL file into a single exe file using AUTOIT program and was impressed having a single exe. I ran the software and it did run. For other reasons I did not want to use the ghostpcl software like with was packaged but super impresssed to being a single exe and the program had a feature of drag and drop of the source pcl file a user wants converted to a PDF file.
                                I did not see anything at the time about how ithe exe was created but the exe was about the same size of the combined original exe and dll files it needed plus there have been many versions of ghostpcl over the last decade. The newest 32 bit version of ghostpcl does not even support windows XP.
                                Anyway I figured there are some tricks I need to learn. Why. Because each new version of ghostpcl comes with a different dll version and I need to prevent any problem
                                possible.
                                p purvis

                                Comment


                                • #17
                                  I am glad I asked the original question.
                                  It helped me find a fix to some software.
                                  Also the mention of the program to combine code in a virtual disk might help me to keep Firefox from updating.
                                  That is really annoying for some unique settings we are using to be changed.
                                  My orginal thought was place the Haru PDF library and other supporting files it uses from my text to PDF file program. Things are getting more complex here with changes to programs we use.
                                  p purvis

                                  Comment


                                  • #18
                                    The reasons I can think of for using a DLL are various but it has always been the case that if you can avoid it, you do so
                                    I think your claim that this has "always been the case" requires substantiation, because....

                                    I think you are wrong; I have thought of DLLs this way for a long time; and I have, do and will recommend the use of DLLs without this kind of prejudice.

                                    MCM

                                    Comment


                                    • #19
                                      I suggest there is plenty of variation here. Take a perfectly working single executable application, remove part of it and place that into a DLL and see what gain you get and the answer is simple, none. You suffer the additional complexity and minor file size increase for no purpose. Now on the other hand, there are a variety of reasons to write or use one or more DLL with an application.

                                      1. The DLL is written in a different language. I have used MASM DLLs with PB and PB DLLs with MASM for years.
                                      2. A DLL may be written by a third party and the source is either unknown or not available.
                                      3. You have more than one application that needs to use common code that is placed in a single DLL.
                                      4. You may wish to update part of the app(s) without changing all of the apps so you produce a single DLL that updates a common capacity.
                                      5. You may wish to put a pile of resource junk into a DLL so that the calling EXE does not have to carry the extra size.

                                      There are probably other reasons but the drift is if you have a language that can produce free standing executable files, do so, why add the extra clutter if you don't need it.
                                      hutch at movsd dot com
                                      The MASM Forum

                                      www.masm32.com

                                      Comment


                                      • #20
                                        I agree, except for 5. which confuses me. If you make a resource DLL, but then put the DLL into the EXE; isn't the EXE carrying the extra size anyway?
                                        Dale

                                        Comment

                                        Working...
                                        X