Очень простой и быстрый способ создать консольную VB6-прогу

[Хакер]

Я сделал кирпич (и назвал его EasyConsole), который позволяет очень просто создавать на VB6 консольные приложения. Всего-лишь нужно подключить крохотный модуль с 10 строчками кода, добавить одну библиотеку в References и чуть-чуть подправить VBP-файл блокнотом. Тем более я сделал шаблон проекта, так что можно просто выбирать шаблон «Console Application» в диалоге «New Project». Красота

Ладно, раскрываю карты.
Есть две вещи, позволяющие осуществить это так просто.
Я ноябре 2011 года я во время реверс-инжениринга VB6 наткнулся на кое-что интересное. Оказалось, что VB6 позволяет с помощью пары неизвестных ранее ключей C2Switches и LinkSwitches скармливать любые параметры командной строки компилятору и линкеру. Нас интересует последнее. Скормив ключ /subsystem:console линкеру, мы добьёмся того, что в генерируемых PE-файлах в качестве подсистемы будет значиться CUI-подсистема, то есть консольная подсистема, что автоматически означает создание консольного окна при запуске EXE-файла.

Но этого мало. Да, запускаемые EXE-шники будут от рождения иметь консольное окно, но чтобы в него что-то читать или писать, нужно писать много код. Придётся делать это с использованием Win32 API. Причём есть два способа работы с консолью. Во-первых это работа со стандартными потоками stdin, stdout, stderr. Это позволяет нам только читать и писать текст в потоковом режиме. И же можно работать с консолью с помощью специальных консольных API. Это позволит нам раскрашивать консоль и делать всякие интересные вещи. В любом случае, надо либо напрямую использовать API-функции, либо писать над ними обёртку.

А народ у нас, как известно, API-функций боится. Ну, или не боится, но предпочтёт набросать консольную утилиту на С/С++ или богомерзком дотнете.

Но вчера я обнаружил, что объект класса FileSystemObject поддерживает интерфейс IFileSystem3, у которого есть метод, возвращающий ссылку на интерфейс ITextStream, олицетворяющий любой из стандартных потоков (stdin, stdout, stderr). Это означает, что используя объектную модель FSO можно очень легко организовать чтение/запись из/в стандартные потоки, которые для консольного приложения ассоциированы с консольными буферами.

Это даёт нам возможность очень просто писать консольные приложения по первому типу. Поскольку доступ к консоли осуществляется через стандартные потоки, то мы можем писать консольные утилиты, которые могут принимать участие в перенаправлении вввода/вывода и в построении конвейеров.

И самое главное, что такой консольный проект скомпилируется на абсолютно любом компьютере, где установлен свежий чистый VB6. Не требуется никаких Add-In-ов, плагинов и модификаций среды/линкера. Всё только штатными средствами.

И работать такие консольные программы будут везде, где есть FSO.

И самое главное, можно писать полиморфный код, то есть код, который будет писать что-то в ITextStream, не делая разницы, пойдёт ли запись в консоль (через стандартный поток), в файл (через стандартный поток) или в файл, открытый с помощью FSO, потому что и открытый стандартный поток (который может быть перенаправлен в консоль, в чужой стандартный поток или в файл) и просто открытый файл олицетворяет один и тот же интерфейс ITextStream.

Пожалуйста, потестируйте мой кирпич и создаваемые с помощью него консольные программы — я тестировал только под Windows XP.
Ну и вообще, жду ваших отзывов, предложений, критики и замечаний.

P.S. Объявим конкурс консольных программ на VB6?

[ger_kar]

Да уж простота просто подкупает...
Видел и даже скачивал примеры консольных приложений на VB, но там все было довольно громоздко, что отбивало желание делать на VB консольные приложения. В отличии от VB.Net, где простота создания консольного приложения так и манила к себе . Теперь практически тоже самое есть и в VB. Но самое интересное, почему, такое раньше в голову никому не приходило. Теперь все кажется очень очевидным, но вот понадобилась куча лет, что-бы очевидное стало явью.

А теперь практический вопрос.
Сейчас практически все ADSL модемы поддерживают Telnet. Можно как-то сделать на VB приложение управляющее таким модемом при помощи Telnet?

[ger_kar]

Совершенно другой вариант. Можно создать класс или форму CDbgConsoleEmulator, в которой написать Implements ITextStream и реализовать этот интерфейс. В модуле же EasyConsole с помощью описанной мною элегантной технологии определения того, под отладкой ли работает проект, нужно в при работе под отладкой вместо FSO-шных объектов подсовывать экземляр вашего класса CDbgConsoleEmulator (который может быть не просто классом, но и формой в том числе). Этот экземпляр будет сам обрабатывать вызовы Read/ReadLine/Write/WriteLine и что-то делать. Например, если это будет форма — полностью эмулировать интерфейс консоли.

А можно каким нибудь это упростить, например породить консольное окно и заставить FSO в режиме отладки работать с этим консольным окном?

По поводу критики и замечаний. Я думаю для шаблона более подходит название Console Application, без Easy. И короче и читабельные и более понятно.
И еще может сделать это шаблон с автоустановкой? Типа самораспаковывающегося архива. Что-бы просто устанавливать как FNDLL.

[Хакер]

По поводу критики и замечаний. Я думаю для шаблона более подходит название Console Application, без Easy. И короче и читабельные и более понятно.

Нет, потому что ещё раньше в планах был кирпич, который который конечно был бы намного больше, чем этот модуль, но зато позволял бы полноценно работать с консолью, включая функции типа printf, scanf, и включая работу с цветом. Вот если он будет сделан мною, то он будет называться просто Console Application. Он будет богаче по функциям, не привязан к FSO и ну и всё такое.

[ger_kar]

Ну и какие проблемы, можно будет назвать его ConsoleEx Application.

[Mikle]

Что ещё таит от нас VB6? У меня уже азарт возник, что Хакер обнаружит в следующий раз

[ger_kar]

И что самое интересное, что в случае с консольным приложением все практически лежало на поверхности (ну кроме ключей компиляции) и все было достаточно просто, но никто за столькие годы этого кроме Хакера не увидел. Как говориться, хочешь что-то спрятать положи его на самое видное место .
Есть еще фишка с линковкой, которая позволяет прилинковать к VB'шному приложению модули написанные на чем угодно, лишь бы это вообще можно было линковать. Осталось дождаться соответствующей статьи .

[jangle]

И что самое интересное, что в случае с консольным приложением все практически лежало на поверхности (ну кроме ключей компиляции) и все было достаточно просто, но никто за столькие годы этого кроме Хакера не увидел. .

Насчет что только Хакер увидел это ерунда. Исходники консольных программ на VB появились лет 13 назад, это уж точно

[Хакер]

Насчет что только Хакер увидел это ерунда. Исходники консольных программ на VB появились лет 13 назад, это уж точно

Джангл, ты вообще въехал в фишку? Или ты как вот этот товарищ?

Кирпич зиждется на использовании двух вещей: открытых мною секретных ключей vbp-файла, о которых до того, как я информацию о них опубликовал, вообще никто нигде нигде не знал и не писал (проверено всеми поисковиками), и на том, что через FSO можно получить ссылку на ITextStream, реализация которого работает со стандартными потоками — то есть получить OOП-style доступ к стандартным потокам.

То что 13 лет назад какие-то какие-то люди делали консольные приложения, долбясь в консоль через WinAPI, и самое главное, испытывая дебильную необходимость патчить EXE-файл после каждой перекомпиляции — это ни для кого не новость, но это совсем другая история. Она не дотягивает по удобству, тривиальности и крохотности до предложенного решения.

[ger_kar]

Насчет что только Хакер увидел это ерунда. Исходники консольных программ на VB появились лет 13 назад, это уж точно

Речь то идет об удобстве и простоте, а не о потенциальной возможности как таковой, создавать консольные приложения на VB.

[jangle]

Джангл, ты вообще въехал в фишку? Или ты как вот этот товарищ?

Да не въехал. У тебя оказывается все намного удобнее реализовано. Не нужно патчить exe файл или перехватывать линкер.

[uni]

Да, это работает.

Без отладки это напоминает VBScript или JScript, где можно сделать всё то же самое или почти то же самое. Думаю, что MS отказалась от консоли в бейсике именно по этой причине, они уже тогда думали о WSH и Power Shell. Компилировать не надо, всё в текстовом виде, среды разработки есть (PrimalScript 2011, к примеру). В PrimalScript 2011 есть даже автодополнение и отладка, про раскраску синтаксиса я уж молчу. В скриптах отлов ошибок через try catch() будет получше.

П.С. Если тут используется fso, то можно в качестве отладки использовать вот такой простой логгер (приложил в аттаче) вместе с известным приёмом вставки обёрток отлова ошибок в каждой функции (у меня среда делает это автоматически - CodeSmart).

Инициализация делается так.

Код: Выделить всё

    ' Создаём экземпляр журнала
    Set Logger = New CLogger

    ' Запускаем ведение журнала
    Logger.StartLogging Settings.LogFilePath, VBRUN.LogModeConstants.vbLogToFile


Делать запись в файл можно так:

Код: Выделить всё

    ' Делаем запись в журнале
    Logger.Info "Запуск программы..." & VBA.Constants.vbCrLf & VBA.Constants.vbCrLf & _
            "-----------------------------------------------------------------------" & _
            vbCrLf & APP_NAME & vbCrLf & udtFileInfo.FileVersion & vbCrLf & _
            "Уникальный идентификатор (GUID): " & ProgramGUID & vbCrLf & _
            "Дата запуска: " & Date & " г. в " & Time & vbCrLf & _
            "Операционная система: " & GetOSVersion & vbCrLf & "Имя пользователя: " & _
            szUserName & vbCrLf & "Текущая папка: " & szCurrDir & vbCrLf & _
            "Настройки соединения: " & GetConnectionString() & vbCrLf & _
            "-----------------------------------------------------------------------" & _
            vbCrLf


Или так:

Код: Выделить всё

Private Sub Form_Unload(Cancel As Integer)
    '<EhHeader>
    On Error GoTo Form_Unload_Err
    '</EhHeader>

    ' Если форма закрываетя не через меню, то просто скрываем её
    If Not isClose Then

        ' If cancel is 0, the form is removed.
        ' Setting cancel to any nonzero value prevents the form from being removed.
        Cancel = 1
        Me.Hide
        MenuItemShowHide.Caption = "&Показать"

    End If

    '<EhFooter>
    Exit Sub

Form_Unload_Err:
    Logger.Error "[homectrl.FormMain.Form_Unload]: " & GetErrorMessageById( _
            Err.Number, Err.Description)

    Resume Next

    '</EhFooter>
End Sub


[Хакер]

Без отладки

Почему отладки-то нет?

[uni]

Телодвижения же надо какие-то сделать, в коробке это не идёт, а пояснение этих телодвижений не такая тривиальная вещь как само описание этого способа. Народ же как хочет? Нажал кнопку, получил консольное приложение и всё остальное, а тут интерфейс реализовывай, делай изменения в файле среды. Спецы только поймут, ну или среднего уровня программисты. Остальные сделают то же самое на .Net.

П.С. Кстати, тут переводил программу с TurboBasic'а на C#, консольную. Там стандартная работа в одном потоке с текстовой графикой, ввод, вывод на экран. Я попытался сделать модель терминала на форме, чтобы эмулировать команды тубробейсика, т.к. откомпилированные проги отказывались работать даже в DOSBox'е. Так вот, что меня в современных фреймворках выводит их себя, так это размеры получающегося текста кода.

Пример кода на бейсике:

Код: Выделить всё

2104 IF I=1 AND J=1 THEN LOCATE 5,20:PRINT USING"###.###";D:LOCATE 5,20,1


мой аналог на C# (нужно иметь в виду, что нельзя в основном потоке опрашивать поле ввода как на бейсике, поэтому вводятся потоки, а с потоками там отдельная песня):

Код: Выделить всё

                        if ( ( I == 1 ) && ( J == 1 ) ) {

                            // Отображаем поле ввода.
                            form.Invoke( new Action<string, int, int, int, bool>( form.SetInput ),
                                String.Format( provider, "{0:0.000}", D ), row, val1, width, true );

                            // Ожидаем завершения ввода пользователем.
                            form.mreInput.WaitOne(); form.mreInput.Reset(); D = form.Input;

                            // Завершаем поток, если нажали клавишу Q.
                            if ( form.Inkey == Keys.Q ) { form.ExitEvent = true; break; }

                            // Отображаем введённое значение вместо поля ввода.
                            form.Invoke( new Action<string, int, int>( form.terminal.Print ),
                                String.Format( provider, "{0:0.000}", D ), row, val1 );

                            // Восстанавливаем положение курсора.
                            form.Invoke( new Action<int, int, bool>( form.terminal.Locate ), row, val1, true );

                        }


Было бы не плохо, к примеру, иметь аналоги простых старых команд: LOCATE, COLOR, PRINT, CLS, INPUT, INKEY$. И, желательно, кодировку 866 для псевдографики. Я использовал форму, т.к. там нужно ещё было графику выводить, а для консоли это не такая тривиальная вещь как для Paintbox'а, который у меня и эмулирует терминал.

http://www.vbforums.com/ - с ними не поделишься?

[Хакер]

Нажал кнопку, получил консольное приложение и всё остальное, а тут интерфейс реализовывай, делай изменения в файле среды.

Или или. И как раз да, нажал одну кнопку, вернее запустил одну команду (dumpbin) и получил среду с поддержкой отладки консольных приложений.

Было бы не плохо, к примеру, иметь аналоги простых старых команд: LOCATE, COLOR, PRINT, CLS, INPUT, INKEY$. И, желательно, кодировку 866 для псевдографики. Я использовал форму, т.к. там нужно ещё было графику выводить, а для консоли это не такая тривиальная вещь как для Paintbox'а, который у меня и эмулирует терминал.

Речь шла о поддержке консольных приложений, а не досовских.

http://www.vbforums.com/ - с ними не поделишься?

В каком плане поделиться? Публиковать то же самое на любом другом форуме я не буду. Линк могу сделать сюда.

[uni]

Речь шла о поддержке консольных приложений, а не досовских.

Жаль, я хотел что-то вроде эмуляции ANSI-терминала, чтобы не реализовывать самому, как сейчас, его вот таким способом.

[Qwertiy]

Там стандартная работа в одном потоке с текстовой графикой, ввод, вывод на экран.
мой аналог на C# (нужно иметь в виду, что нельзя в основном потоке опрашивать поле ввода как на бейсике, поэтому вводятся потоки, а с потоками там отдельная песня):
Жаль, я хотел что-то вроде эмуляции ANSI-терминала, чтобы не реализовывать самому, как сейчас, его вот таким способом.

Ну если ты не способен нормально использовать консоль в .NET, что тут скажешь?

Консольное приложение на VB.NET.png

Остальному обсуждению .NET'а в этой теме не место, полагаю.

[uni]

Ну если ты не способен нормально использовать консоль в .NET, что тут скажешь?

Я использовал форму, т.к. там нужно ещё было графику выводить, а для консоли это не такая тривиальная вещь как для Paintbox'а, который у меня и эмулирует терминал.

[Qwertiy]

Сорри, не заметил. Ну хоть бы визуальные стили отключил, а то градиентное меню... И я не понимаю, зачем тебе отдельный поток нужен. Что мешает обрабатывать события клавиатуры для формы?

[uni]

Это очень просто объясняется, если взглянуть на типовой код турбобейсика. Вот как делался ввод данных с проверкой в консоли:

Код: Выделить всё

529 LOCATE 11,22:INPUT,DY
    IF DY=0 THEN LOCATE 19,3:?"Допуск переднего угла равен 0":LOCATE 11,22:?"    ":GOTO 529
    LOCATE 12,21:INPUT, L0:L0=15+L0
531 LOCATE 13,22:INPUT, T
    IF T=0 THEN LOCATE 20,3:?"Осевое биение инструмента равно 0":LOCATE 13,22:?"    ":GOTO 531


И как я это сделаю в основном потоке на форме? Там много таких конструкций идёт в подряд. А повторяю код я точно, т.к. на первом этапе нужно, чтобы программа работала по аналогии. Проще пока сделать более менее точный порт, а потом уже думать как использовать современный компонентный подход. Я нашёл способ эмулирования такой работы, но при помощи дополнительного потока, правда при этом добавилась куча обёрточного кода, т.к. нельзя так просто иметь доступ из потока к компонентам формы. Хотя сам эмулятор терминала у меня получился очень небольшой по коду, но вот многопоточность эта меня достаёт, я пока не сообразил как писать более короткий код, который бы по краткости был похож на оригинал.

[Qwertiy]

Вот как делался ввод данных с проверкой в консоли

Я не знаю Turbo Basic, только VB6. Объясни что он делает.

Хотя сам эмулятор терминала у меня получился очень небольшой по коду, но вот многопоточность эта меня достаёт, я пока не сообразил как писать более короткий код, который бы по краткости был похож на оригинал.

Я бы сделал наследника PictureBox'а.

PS: Хакер, перенеси пожалуйста всё лишенее в отдельную тему, мы ещё пообсуждаем

[uni]

Дело в том, что в конце 80-х начале 90-х ещё не пользовались компонентным подходом и народ писал как попало. Тогдашние листинги кода - это что-то ужасное, основанное полностью на GOTO операторе. Код модуля идёт сплошником, при этом из любого места можно "прыгнуть" в любое по желанию программиста (стиль ассемблера). При этом получается такая вещь, что ввод данных не отделён от их отображения и обработки, т.е. интерфейс формируется динамически по мере необходимости.

Код: Выделить всё

529 LOCATE 11,22:INPUT,DY
    IF DY=0 THEN LOCATE 19,3:?"Допуск переднего угла равен 0":LOCATE 11,22:?"    ":GOTO 529


Этот кусок кода означает, что нужно перенести текущий указатель курсора по координатам 11,22 и ожидать от пользователя ввода числа. На это время работа программы приостанавливается, т.е., иначе говоря, "основной поток" засыпает на время ожидания ввода от пользователя. Когда пользователь ввёл число, то проверяется его равенство нулю, если это так, то выводится сообщение "Допуск переднего угла равен 0", затирается текущий ввод и опять идёт ожидание ввода пользователя.

Сейчас подобного рода строчки заменяются кучей полей ввода, которые могут быть обработаны как отдельно, так и вместе, но проблема в том, что в общем случае в оригинальной программе можно было "прыгнуть" в любом направлении по листингу между этими вводами, либо что-то посчитать между вводами и это воспринимается как одна последовательность операций, которую нельзя разделать так просто. Т.е. я не могу заменить подобный ввод на кучу полей ввода на форме, т.к. ввод данных там не совсем независимая операция. Вот в этом и проблема. Такой разрыв шаблона для тех, кто попытается как-то реализовать программу современными подходами с меню, кнопками и так далее. Раньше был популярен диалоговый режим, но оконный объектный Turbo Vision появился гораздо позже.

Вот и получается, что, если я хочу придерживаться того потока кода, который идёт в оригинале, то я должен задерживать основной поток, ожидая ввода пользователя, но обработка поля ввода сейчас делается в отдельном обработчике и тут вступает GOTO, который может "выпрыгнуть" из этого обработчика в любую сторону. Как я из обработчика поля ввода выпрыгну в произвольное место? Там вообще две проблемы: goto и ввод. Goto я реализовал автоматным методом на состояниях, а ввод пришлось организовывать через поток, т.е. основной код у меня находится в потоке (переключатель состояний), я могу теперь его приостанавливать согласно алгоритму, а управление находится в обработчике поля ввода. Вот так всё сложно, но это хорошо работает и воспроизводит алгоритмику оригинального исходного кода.

Кстати, старые фортран программы тоже этими goto страдали. Меня как-то просили перевести одну такую программу на современный язык, но у меня не было такого опыта как сейчас, я испугался обилия этих goto.

[Хакер]

uni, ты не против отделения?

[uni]

Я не против, в какое-нибудь место, связанное с .Net, видимо.