Add-in for compiling EXEs in Console mode in VB6

[Ben321]

This doesn't use the official Add-ins mechanism in VB6, but it still adds a feature to the VB6 IDE that is not present in the official MS distribution of VB6. It acts as a proxy between the VB6.exe and Link.exe. To make it work, rename the Link.exe file that came with VB6 to Link2.exe. Then rename the proxy linker file from "VB6 Proxy Linker.exe" to Link.exe and put it into the same folder as Link2.exe. VB6 will execute my program when you compile from the IDE. My program analyzes the command line arguments to determine if it creating an OCX or DLL file (ActiveX Control or ActiveX DLL project), or if it is creating an EXE file (standard EXE or ActiveX EXE project). If it is creating a DLL or OCX file, my program immediately executes Link2.exe with the command line switches as-is. If it is creating a DLL file, my program pops up a dialog box. This box allows you to chose between Standard EXE and Console EXE. If you click Standard EXE or it times out (you wait longer than 5 seconds to click a button) it creates a standard exe file by executing Link2.exe with the command line as-is. If you click Console EXE, it inserts the command line switch into the existing command line needed to make a console based exe file, and then executes Link2.exe with the modified command line.


The zip file containing this VB6 add-on can be downloaded from Mediafire at this link:
https://www.mediafire.com/?hx6ichp2b6kdeur

Note that both the compiled EXE file and the source code are included in this zip file.

[Bonnie West]

There is a more portable alternative to the old LINK.EXE spoofing technique:

The trick has shared an undocumented .VBP section tip that enables a Standard EXE project to be compiled as a console application (or standard DLL) without requiring post-processing of the EXE or use of IDE add-ins that hook into the build process:

[VBCompiler]
LinkSwitches=/SUBSYSTEM:CONSOLE

[Ben321]

There is a more portable alternative to the old LINK.EXE spoofing technique:

My proxy linker software though can be used with any project immediately. It doesn't require editing any VBP file. It simply allows you to set what type of EXE you want right when you compile. Editing a VBP file could potentially be undone if the VB6 IDE decided to overwrite that extra part of the file when you next saved your project. With my solution, it will always work.

[Bonnie West]

My proxy linker software though can be used with any project immediately. It doesn't require editing any VBP file.

Well, that undocumented VBP section only requires that setting to be set only once before you compile the first EXE. After that, it's all automatic; there's no need to click buttons or wait for a few seconds.

Obviously, you won't have to edit the VBP file if the project type isn't a console or standard DLL. With your approach, the dialog box pops up every time you're compiling a Standard EXE project.

It simply allows you to set what type of EXE you want right when you compile.

It would have been a time-saver if your proxy linker remembered the chosen compilation settings for every project that has been opened just like what that [VBCompiler] section does.

Editing a VBP file could potentially be undone if the VB6 IDE decided to overwrite that extra part of the file when you next saved your project.

VB6 does not delete or modify custom sections in the VBP file (including that [VBCompiler] section). This feature is intended to be used by IDE add-ins when they read/write custom VBP settings.

With my solution, it will always work.

It might not work in a corporate PC where tightened security prevents software from being installed or copied to certain locations (like %ProgramFiles%) without permission of the admins.

[dilettante]

Indeed, you can just use a template for this. Just unzip the attachment and move the two files into:

C:\Program Files\Microsoft Visual Studio\VB98\Template\Projects

... or the equivalent location on your machine.

Warning: Check the folder first, you don't want to just replace any existing files with the same names!

Then you get the option of "Console EXE" when you open a new project.

Of course you might want to customize, adding more to the Module1.bas included. For example allocating/deallocating a console for IDE runs:

Option Explicit
'
'Reference to Microsoft Scripting Runtime.
'

Public SIn As Scripting.TextStream
Public SOut As Scripting.TextStream

'--- Only required for testing in IDE or Windows Subsystem ===
Private Declare Function AllocConsole Lib "kernel32" () As Long
Private Declare Function GetConsoleTitle Lib "kernel32" _
    Alias "GetConsoleTitleA" ( _
    ByVal lpConsoleTitle As String, _
    ByVal nSize As Long) As Long
Private Declare Function FreeConsole Lib "kernel32" () As Long

Private Allocated As Boolean

Private Sub Setup()
    Dim Title As String

    Title = Space$(260)
    If GetConsoleTitle(Title, 260) = 0 Then
        AllocConsole
        Allocated = True
    End If
End Sub

Private Sub TearDown()
    If Allocated Then
        SOut.Write "Press enter to continue..."
        SIn.ReadLine
        FreeConsole
    End If
End Sub
'--- End testing ---------------------------------------------

Private Sub Main()
    Setup 'Omit for Console Subsystem.

    With New Scripting.FileSystemObject
        Set SIn = .GetStandardStream(StdIn)
        Set SOut = .GetStandardStream(StdOut)
    End With

    SOut.WriteLine "Any output you want"
    SOut.WriteLine "Goes here"

    TearDown 'Omit for Console Subsystem.
End Sub

You could use an "IDE run test" to decide whether or not to invoke Setup/TearDown, though the GetConsoleTitle() call is usually good enough.