Results 1 to 31 of 31

Thread: [RESOLVED] MakeDLL problem

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Resolved [RESOLVED] MakeDLL problem

    Does anyone out there use AddIn MakeDLL from DanSoft? I ran into a problem compiling a standard DLL, and when I attempted to fix it, I completely screwed it up. Attempts to re-install it have failed, and I could use some help by comparing to a working install.

    J.A. Coutts

  2. #2
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,892

    Re: MakeDLL problem

    What exactly is happening? And what are you looking for to compare; do you need the original source files? Might be some arcane registry issue; compile with a higher version number and no compatibility?

    Is it worth pointing out twinBASIC natively supports standard DLL projects? Import VBP, open project settings from the project explorer, Project: Build Type -> Standard DLL, place `[DllExport]` on the line before each method you want exported.

  3. #3
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,083

    Re: MakeDLL problem


  4. #4
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,227

    Re: MakeDLL problem

    Btw, there is nothing this Add-in does that cannot be done directly with LinkSwitches setting without fiddling with linker replacement.

  5. #5

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Re: MakeDLL problem

    I managed to get one of my machines (Win 8.2) working again. I followed the install instructions, but ran into an issue attempting to create MakeDLL.dll. When I loaded the AddIn project MakeDllAddin.vbp, I received the error:
    Line 0: The file C:\VB98\Utility\DLL\addin\Connect.Dsr could not be loaded.

    So I copied the old "MakeDLL.dll" file to the VB98 directory and everything seems to be working again. I will try the same process on the Win 11 machine.

    J.A. Coutts

  6. #6
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,083

    Re: MakeDLL problem

    If it’s from a git repo make sure line endings are vbcrlf and not just vblf

  7. #7
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,892

    Re: MakeDLL problem

    https://github.com/fafalone/LinebreakRepair

    Need to add .dsr to the extensions list if you're running it on an addin.

  8. #8

  9. #9

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Re: MakeDLL problem

    Now that I have the MakeDLL AddIn working again, I set out to recreate the issue. The original problem created a runtime error:
    Run-time error '-2147467259 (80004005)':
    Method '-' object '-' failed

    Examining the Connect.Dsr module:
    Code:
    'rename our replacement linker so it gets run
    Name strVBPath & "link.exe" As strVBPath & "link1.exe"
    Name strVBPath & "makedll.exe" As strVBPath & "link.exe"
    
    'write the .def file name to a temp file in the
    'vb directory so the compiler knows where the
    'def file is.
    Open strVBPath & "makedll.txt" For Output As #1
        Print #1, strDefPath
    Close #1
    
    'actually compile the project, and wait for the
    'compile to finish
    'If SuperShell(strVBPath & "vb6.exe """ & VBInstance.ActiveVBProject.FileName & """ /make", strVBPath, 0, SW_NORMAL, HIGH_PRIORITY_CLASS) = False Then MsgBox "Error compiling project!", vbExclamation, "Error"
    VBInstance.ActiveVBProject.MakeCompiledFile
    
    'rename linker back to normal
    Name strVBPath & "link.exe" As strVBPath & "makedll.exe"
    Name strVBPath & "link1.exe" As strVBPath & "link.exe"
    Since makedll.txt was created, the runtime error occurred in the MakeCompiledFile routine. To correct the failure, I simply had to:
    ren link.exe makedll.exe
    ren link1.exe link.exe

    Now all I have to do is figure out what is causing the runtime error.

    J.A. Coutts

  10. #10

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Re: MakeDLL problem

    It appears that the Runtime error was caused by the name I gave the new DLL file. The name "ReadFile" was already in use by the Kernel.

    The next problem is that the DLL is incapable of accepting double wide (2 byte) strings as a parameter. They just end up as a bunch of question marks.

    J.A. Coutts

  11. #11
    Frenzied Member VanGoghGaming's Avatar
    Join Date
    Jan 2020
    Location
    Eve Online - Mining, Missions & Market Trading!
    Posts
    1,537

    Re: MakeDLL problem

    Any API function that you declare with String parameters will suffer from this problem. The solution is not to use String parameters and pass the StrPtr(String) as a Long instead.

  12. #12
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    10,186

    Re: MakeDLL problem

    Quote Originally Posted by couttsj View Post
    It appears that the Runtime error was caused by the name I gave the new DLL file. The name "ReadFile" was already in use by the Kernel.

    The next problem is that the DLL is incapable of accepting double wide (2 byte) strings as a parameter. They just end up as a bunch of question marks.

    J.A. Coutts
    That's because, by default, VB6 converts all "Declare ..." API call Strings to ANSI when the call is made, and converts them back to Unicode upon return (if they're ByRef).

    To prevent that, you must pass Strings as ByVal StrPtr(TheString), and then declare the argument as Long (rather than String) in the API declaration.

    ----------------

    Or, just thinking about it, if you're not "catching" your strings correctly in the DLL, and just addressing random memory instead of the actual string, that could cause the same symptoms. That can easily happen when you're not clear on how the ByVal and ByRef stuff work, and also how BSTR string variables are a pointer to the string and don't actually hold the string's data (as contrasted to things like Integer, Long, Single, Double, etc).

    And actually, the VarPtr() of a string variable is a pointer to the four-byte header of a BSTR which contains the length of the string, which is followed by a UnicodeZ string (string terminated with 2-bytes of zero memory). StrPtr() is just a convenience that points directly at the UnicodeZ string. We can actually use StrPtr()-4 to get that 4-byte length header.
    Last edited by Elroy; Apr 12th, 2024 at 09:19 AM.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  13. #13
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,083

    Re: MakeDLL problem

    Std dlls written in vb are rarely worth the headache. I’ve never seen an actual best use case. Academically interesting and novelty yes.
    Last edited by dz32; Apr 12th, 2024 at 09:29 AM.

  14. #14

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Re: MakeDLL problem

    Quote Originally Posted by Elroy View Post
    That's because, by default, VB6 converts all "Declare ..." API call Strings to ANSI when the call is made, and converts them back to Unicode upon return (if they're ByRef).

    To prevent that, you must pass Strings as ByVal StrPtr(TheString), and then declare the argument as Long (rather than String) in the API declaration.

    ----------------

    Or, just thinking about it, if you're not "catching" your strings correctly in the DLL, and just addressing random memory instead of the actual string, that could cause the same symptoms. That can easily happen when you're not clear on how the ByVal and ByRef stuff work, and also how BSTR string variables are a pointer to the string and don't actually hold the string's data (as contrasted to things like Integer, Long, Single, Double, etc).

    And actually, the VarPtr() of a string variable is a pointer to the four-byte header of a BSTR which contains the length of the string, which is followed by a UnicodeZ string (string terminated with 2-bytes of zero memory). StrPtr() is just a convenience that points directly at the UnicodeZ string. We can actually use StrPtr()-4 to get that 4-byte length header.
    Thanks Elroy;

    I already tried that, but obviously there is some other problem. I am going to try IOFile API. It uses the file Handle as long instead of the file Name as string.

    J.A. Coutts

  15. #15
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    1,083

    Re: MakeDLL problem

    File handles will require runtime init unless called from a vb parent app in the same thread

  16. #16
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    10,186

    Re: MakeDLL problem

    I'm not sure I'm the one who's up for messing with the AddIn, and creating standard DLLs with VB6, but a small sample of your DLL source code, and a small test program that calls it would help to suss out your problem.

    Also, in doing that, you may well find the problem on your own.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  17. #17

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Re: MakeDLL problem

    Quote Originally Posted by Elroy View Post
    I'm not sure I'm the one who's up for messing with the AddIn, and creating standard DLLs with VB6, but a small sample of your DLL source code, and a small test program that calls it would help to suss out your problem.

    Also, in doing that, you may well find the problem on your own.
    It is on the way. My ultimate goal was to make IOFile API calls more streamlined, but I was trying to get there using more normal VB6 routines. That didn't really work out very well.

    J.A. Coutts

  18. #18
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Location
    Sofia, Bulgaria
    Posts
    5,227

    Re: MakeDLL problem

    You still have to initialize VB runtime on exported functions the way it’s done on thread entry proc in multi-threading scenarios. I mean this approach will likely have the same issues with completion ports.

  19. #19
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,289

    Re: MakeDLL problem

    Quote Originally Posted by couttsj View Post
    My ultimate goal was to make IOFile API calls more streamlined
    If that Dll was planned, to be used of from VB6/VBA/tB -
    then I don't see why you try to avoid to produce a normal ActiveX-Dll...

    If it "has to be" a Dll with stdcall-Exports, then why not use FreeBasic to implement these Exports
    (which compiles such Dlls directly without fuss).

    It even comes with nearly VB6-compatible File-syntax:
    https://www.freebasic.net/wiki/ProPgFileIO

    One of the IDEs for Windows (including the compiler) is e.g. available here:
    https://github.com/PaulSquires/WinFBE/releases

    Olaf

  20. #20
    Frenzied Member VanGoghGaming's Avatar
    Join Date
    Jan 2020
    Location
    Eve Online - Mining, Missions & Market Trading!
    Posts
    1,537

    Lightbulb Re: MakeDLL problem

    I haven't tried it yet but, if I understand correctly, with an ActiveX DLL basically the whole idea would be first creating a dummy object from it with whatever RegFree flavor you prefer and then all exported functions would work normally with a regular "Declare" statement.

  21. #21
    Frenzied Member VanGoghGaming's Avatar
    Join Date
    Jan 2020
    Location
    Eve Online - Mining, Missions & Market Trading!
    Posts
    1,537

    Talking Re: MakeDLL problem

    Just tested this and it works great although I can't think of any practical uses except as a novelty. It's much better to use object methods rather than declared functions in a BAS module.

    Only tested this in a single-threaded environment though so it wasn't even necessary to instantiate the ActiveX DLL, the exported function worked just the same as if it were in a standard DLL...

  22. #22
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,892

    Re: MakeDLL problem

    Quote Originally Posted by Schmidt View Post
    If that Dll was planned, to be used of from VB6/VBA/tB -
    then I don't see why you try to avoid to produce a normal ActiveX-Dll...

    If it "has to be" a Dll with stdcall-Exports, then why not use FreeBasic to implement these Exports
    (which compiles such Dlls directly without fuss).

    It even comes with nearly VB6-compatible File-syntax:
    https://www.freebasic.net/wiki/ProPgFileIO

    One of the IDEs for Windows (including the compiler) is e.g. available here:
    https://github.com/PaulSquires/WinFBE/releases

    Olaf
    Why learn FreeBasic when twinBASIC supports standard DLLs from existing VB6 code?

  23. #23
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,289

    Re: MakeDLL problem

    Quote Originally Posted by fafalone View Post
    Why learn FreeBasic when twinBASIC supports standard DLLs from existing VB6 code?
    Because the compiler is out of Beta-stage for years.

    If couttsj is planning to distribute his Dll (if it's not for "hobby-usage on his own PC"),
    then FreeBasic is the better option currently.

    Olaf

  24. #24

  25. #25
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,892

    Re: MakeDLL problem

    Quote Originally Posted by Schmidt View Post
    Because the compiler is out of Beta-stage for years.

    If couttsj is planning to distribute his Dll (if it's not for "hobby-usage on his own PC"),
    then FreeBasic is the better option currently.

    Olaf
    Your "professional" standpoint is that you should pick an entirely different language, inevitably poorly implement your code in it because you won't have any experience, then use that, because this language is "out of beta"?

    No, unless he's already an experienced FreeBasic programmer, that's not the better option for a commercial distribution situation. It's more important to have strong coding experience in the target language than an arbitrary distinction about "beta". You're going to wind up with a lot more bugs from not having years of experience in the language than you will from tB's compiler.

    More dubious "professional" advice from the same guy who says you shouldn't even use officially documented APIs and interfaces over the shell object because you might not do it quite as well. Seems a bit contradictory.
    Last edited by fafalone; Apr 13th, 2024 at 09:15 AM.

  26. #26

  27. #27
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,289

    Re: MakeDLL problem

    Quote Originally Posted by fafalone View Post
    Your "professional" standpoint is that you should pick an entirely different language...
    Entirely different??? It's JAB (Just Another Basic) faf...

    Quote Originally Posted by fafalone View Post
    ...and inevitably poorly implement your code...
    Don't project onto others from your own experience as a hobbyist...

    Olaf

  28. #28

    Thread Starter
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,485

    Re: MakeDLL problem

    This is a working copy of the basic DLL (fRead.dll) and the program to test it (Test.vbp). The test file to be read (Test01.bin) is a 4 byte file in the app directory consisting of the ASCII characters "Test". The file structure includes the FileName as a pointer, the FileHndl as a handle when using File API, and the FileLen for buffer allocation. The plan is to utilize File API, and to include both Read and Write routines using fixed Block lengths. I will post the finished code in the CodeBank when complete.

    J.A. Coutts

    fRead.dll
    Code:
    ''''''''''''''''''''''''''''''''''''''''''''''''
    ''    DLL PROJECT ©2004 DanSoft Australia     ''
    ''   Your dlls MUST HAVE a DLLMain and Main   ''
    '' proc, otherwise it won't compile properly! ''
    ''''''''''''''''''''''''''''''''''''''''''''''''
    
    Private Type FileStruct
        FileName As Long
        FileHndl As Long
        FileLen As Long
    End Type
    
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)
    
    Function DLLMain(ByVal A As Long, ByVal B As Long, ByVal c As Long) As Long
        DLLMain = 1
    End Function
    
    Sub Main()
        'This is a dummy, so the IDE doesn't complain
        'there is no Sub Main.
    End Sub
    
    Public Function GetFileBinary(fData As FileStruct, bOut() As Byte) As Long
        On Error GoTo JustExit
        Dim F As Integer
        Dim sFileName As String
        Dim nBytes As Long
        sFileName = String$(fData.FileLen, Chr$(0))
        CopyMemory ByVal StrPtr(sFileName), ByVal fData.FileName, fData.FileLen * 2
        'MsgBox sFileName
        nBytes = FileLen(sFileName)
        If nBytes > 0 Then
            F = FreeFile()
            Open sFileName For Binary As #F
                ReDim bOut(nBytes - 1)
                Get #F, , bOut
            Close #F
            GetFileBinary = nBytes
        End If
        Exit Function
    JustExit:
        Close #F
        MsgBox "Read Failed!"
    End Function
    Test.vbp
    Code:
    Option Explicit
    
    Private Type FileStruct
        FileName As Long
        FileHndl As Long
        FileLen As Long
    End Type
    
    Private FileData As FileStruct
    
    Private Declare Function GetFileBinary Lib "fRead.DLL" (fData As FileStruct, bOut() As Byte) As Long
    Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)
    
    Private Sub Command1_Click()
        Dim bFile() As Byte
        Dim lPtr As Long
        Dim lLen As Long
        Dim sFileName As String
        Dim FileData As FileStruct
        sFileName = App.Path & "\Test01.bin"
        FileData.FileName = StrPtr(sFileName)
        FileData.FileHndl = 0
        FileData.FileLen = Len(sFileName)
        lLen = GetFileBinary(FileData, bFile)
        For lPtr = 0 To lLen - 1
            Debug.Print Chr$(bFile(lPtr));
        Next lPtr
        Debug.Print
    End Sub
    
    Private Sub Form_Load()
        ChDir App.Path
    End Sub
    Last edited by couttsj; Apr 16th, 2024 at 08:54 AM.

  29. #29
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    5,892

    Re: MakeDLL problem

    Quote Originally Posted by Schmidt View Post
    Entirely different??? It's JAB (Just Another Basic) faf...



    Don't project onto others from your own experience as a hobbyist...

    Olaf
    It's about as similar to VB6 as VB.NET is, so yes, entirely different.

    And you could have just conceded the point instead of make ridiculous claims like a "professional" such as yourself can write perfect bug free code in an entirely new language immediately. Real clown world stuff. You can't. Delusions otherwise notwithstanding, you're not god. And no responsible company would ever put out production code written by someone who's totally new to a language and has no idea all the things they've missed due to lack of experience.

    You must be at the absolute pinnacle of Dunning-Kruger to think you write stable, bug free production code in a language you learned yesterday, and that you do that better at that than a compiler that's been years in development works. You're embarrassingly self-deluded about your superiority over others.
    Last edited by fafalone; Apr 16th, 2024 at 10:01 AM.

  30. #30
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,466

    Re: [RESOLVED] MakeDLL problem

    With almost every release I'm enjoying working with twinBASIC more and more, and supposing the finances work out I have no doubt that tB will be the future of VB...but I would be surprised if even Wayne said that tB is ready for prime time in a production/business setting at this point. Hopefully within the next year or two, but in the meantime I think that something written and compiled against a stable/non-Beta BASIC variant would be a more sensible choice for a one-off need for a standard DLL (or you could play around with the Tricks stuff if you are in a hardcore VB6 mood).

  31. #31
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,289

    Re: MakeDLL problem

    Quote Originally Posted by fafalone View Post
    It's about as similar to VB6 as VB.NET is, so yes, entirely different.
    As always, you argue from your own (hobbyist) perspective of "speculation".

    Whereas I know, why I made my recommendation (to implement a Std-Dll in FreeBasic).

    What escapes you (due to not knowing) is (with regards to the OPs problem to implement a few FileHelper-functions),
    that FreeBasic is nearly 1:1 compatible there.

    For example this FreeBasic *.bas module-code:
    Code:
    #include once "file.bi"
    
    Public Function GetFileBinary(sFileName As String, bData() As Byte) As Long
        On Error GoTo JustExit
        Dim F As Integer 
            F = FreeFile()
            Open sFileName For Binary As #F
            If LOF(F) Then
                ReDim bData(0 To LOF(F) - 1)
                Get #F, , bData()
                GetFileBinary = Loc(F)
            End If
            Close #F
        Exit Function
    JustExit:
        Close #F
        Print "Read Failed!"
    End Function
    
    Sub Main()
       Dim sFileName As String 
           sFileName = "Test01.txt"
       Dim lLen As Long, bData() As Byte
           lLen = GetFileBinary(sFileName, bData())
       Dim i As Long
       For i = 0 To lLen - 1
         Print Chr$(bData(i)); 
       Next
    End Sub
    
    Main() 'FreeBasic only (calling Main explicitely)
    Sleep  'to leave the Console-Window open for manual closing
    You can paste the above two Routines directly into a VB6 *.bas-Module and run them with the same result
    (when enhancing the Print statements to Debug.Print)

    So, your argument about "entirely different" falls flat for FreeBasic.

    As for VB.NET...
    The OP's goal was, to wrap File-Functions in more convenient to use library-exports.

    For VB.NET there is no need to do that, because convenient FileHelpers *are* already wrapped in lib-functions.
    If you can simply write:
    Dim B() As Byte
    B = IO.File.ReadAllBytes(FileName)

    ... then I cannot really see, where in the above snippet a "chance to make beginner-mistakes" creeps in.

    Why the OP tries to "force" VB6-code into a Std-Dll - escapes me,
    because the ideal lib-COMpanions for VB6 are COM-Dlls (in normal AX-Dll-Projects).
    Besides, he could achieve the same thing as with the .NET-Class-Lib (convenient, small code with barely any "room for implementation-errors"),
    using the RC6-COM-reference:
    Dim B() As Byte
    B = New_c.FSO.ReadByteContent(FileName)


    Quote Originally Posted by fafalone View Post
    And you could have just conceded the point ...
    Why should I do so, when - as just shown - your arguments fall flat.

    Quote Originally Posted by fafalone View Post
    You're embarrassingly self-deluded about your superiority over others.
    That's - again - "pure projection" from you.

    If posting code-examples (based on deeper knowledge about things) gives you the impression,
    I'm "lording it over you", then I cannot really see how I shall fix that here on my end, faf.

    You somehow seem to think you are making "big waves" currently ... whilst all there is in reality -
    is you, flopping around in your own shallow puddle of an inferiority-complex.

    I'm sorry, but a bit more humility would do you good, I think.

    Olaf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width