Announcement

Collapse
No announcement yet.

LoadLibrary: Support For Loading Windows DLLs On Linux

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

  • #11
    Originally posted by Weasel View Post
    Hope this will eventually replace all ELF .so files in the future so we can get rid of the dependency hell due to ELF's retarded global symbols support that almost everyone uses.
    The joke is on you. ELF supports local ("private") symbols just fine. On the other hand, DLLs do not have symbol versioning, so you end up having to provide multiple library versions (the WinSxS dance).

    Comment


    • #12
      It would be better to go the other way and have API to load ELF modules in windows-applications. In any case a cross-platform plugin format is welcome.

      Comment


      • #13
        Originally posted by q2dg View Post
        Very unnecessary
        The first thing I thought was WHY? Honestly the only thing we will get out of this is code boost. Maybe I’m missing something but this should stay out of main stream.

        Comment


        • #14
          Originally posted by wizard69 View Post

          The first thing I thought was WHY? Honestly the only thing we will get out of this is code boost. Maybe I’m missing something but this should stay out of main stream.
          It's not meant to go into the kernel. Rather, it's great for fuzzing Windows libraries.

          Comment


          • #15
            Originally posted by q2dg View Post
            Very unnecessary
            Totally not - for me this is very welcoming thing.
            Just recently (at work) we thought about porting some labview stuff (physics measurement things) to linux but one device has no linux driver libs. Wine would be an overkill because only the lib is needed and we dont know how wine+labview are handling time critical events.
            This prevented the use of Linux ....to my disgust ..and we have exactly discussed ideas of a wrapper. The motivation of implementing one by ourself is rather not there because we have no time ...but this might be a game changer.
            Last edited by CochainComplex; 03-11-2020, 01:29 PM.

            Comment


            • #16
              mplayer did this some decades ago to load windows video/audio codecs. I also remember using some binary only codecs from xanim in mplayer. Starting to feel old now...

              Comment


              • #17
                Originally posted by syrjala View Post
                mplayer did this some decades ago to load windows video/audio codecs. I also remember using some binary only codecs from xanim in mplayer. Starting to feel old now...
                Speaking of feeling old, I got a little depressed when a soap opera here in Brazil used the 1990's as a theme. Seeing all the electronics, fashion and music of my youth as a prop was kinda strange...

                Comment


                • #18
                  Originally posted by q2dg View Post
                  Very unnecessary
                  I disagree. A year ago I was asked in my job to interact with some devices. The builder offered a DLL to access them over ethernet. I was able to load it with python on Windows, but we also needed Linux support. A was able to reverse engineering the protocol, but of course that required a lot of time. With this, it would have been much simpler.

                  Comment


                  • #19
                    Originally posted by torsionbar28 View Post
                    While we're at it, the Windows OS kernel should replace the Linux kernel, and lets use NTFS by default as well. Brilliant!
                    Yeah, and let's use the Windows desktop too.

                    Comment


                    • #20
                      Originally posted by Weasel View Post
                      Awesome. Hope this will eventually replace all ELF .so files in the future so we can get rid of the dependency hell due to ELF's retarded global symbols support that almost everyone uses.

                      Make .DLLs native for Linux!
                      I believe the original term is "dll hell".

                      Comment

                      Working...
                      X