[RESOLVED] MakeDLL problem

[couttsj]

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

[fafalone]

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.

[dz32]

is this the package: https://github.com/Planet-Source-Cod...ke-yo__1-54190

[wqweto]

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

[couttsj]

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

[dz32]

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

[fafalone]

https://github.com/fafalone/LinebreakRepair

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

[The trick]

is this the package: https://github.com/Planet-Source-Cod...ke-yo__1-54190

Those dlls won't work properly and have many restrictions. It need to initialize runtime to use DLLs.

[couttsj]

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:

'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

[couttsj]

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

[VanGoghGaming]

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.

[Elroy]

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.

[dz32]

Std dlls written in vb are rarely worth the headache. I’ve never seen an actual best use case. Academically interesting and novelty yes.

[couttsj]

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

[dz32]

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

[Elroy]

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.

[couttsj]

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

[wqweto]

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.

[Schmidt]

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

[VanGoghGaming]

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.

[VanGoghGaming]

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...

[fafalone]

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?

[Schmidt]

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

[The trick]

If you want to create a standard-native-dll you could use this as a starting point. No additional Add-in and dependencies needed.

[fafalone]

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.

[wqweto]

[Schmidt]

Your "professional" standpoint is that you should pick an entirely different language...

Entirely different??? It's JAB (Just Another Basic) faf...

...and inevitably poorly implement your code...

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

Olaf

[couttsj]

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

''''''''''''''''''''''''''''''''''''''''''''''''
''    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

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

[fafalone]

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.

[jpbro]

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).

[Schmidt]

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:

#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)

And you could have just conceded the point ...

Why should I do so, when - as just shown - your arguments fall flat.

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