Анонс: я таки сделал многопоточность в VB

[Хакер]

Наверное многие читали, что я обещал когда-нибудь сделать полноценную работающую поддержку многопоточности в VB.
Так, чтобы можно было абсолютно любой код выполнять в новом потоке, а не только написанный с очень жесткими ограничениями.

Так вот, я её сделал.

Пока всё работает так сказать «в лабораторных условиях» (или в тепличных?), но в конце работы я сделаю приятно оформленный кирпич для порождения 100%-работоспособных потоков.

Буду здесь отписывать подробности чуть позже, ибо сейчас мне интересно исследовать тему дальше.

P.S. Кстатия говоря, цель реверс-инжениринга была несколько более широкой: найти правильный способ инициализировать контекст [VB-проект] × [COM-аппартамент]. Наличие у нас способности это делать решает сразу две задачи: многопоточность и NativeDLL. Потому что и там и там всё падало и рушилось именно по этой причине: не инициализирован контекст, а рантайм ожидает обратного.

[Хакер]

Те, кто читал вот этот интересный пост (а кто не читал, прочтите) должны были понять, что главная мысль поста такова:

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

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

Да, всего-то 5 инструкций процессора. (Не пытайтесь повторить это дома: адреса актуальны только для моего тестового образца, дождитесь релиза полноценного кирпича)

[Хакер]

Вопрос будущим пользователям: в каком виде выполнить кирпич?

• В виде VB-модуля.
• В виде отдельной DLL-библиотеки на Си (с открытыми исходниками)
• В обоих формах, на выбор пользователей

[BV]

Я не будущий пользователь, но гармоничнее всего такой код смотрелся бы в виде обертки компилятора.

[Хакер]

Я не будущий пользователь, но гармоничнее всего такой код смотрелся бы в виде обертки компилятора.

И какая бы разница должна быть между обычным и модифицированным компилятором? Не понимаю.

[VBTerminator]

Вопрос будущим пользователям: в каком виде выполнить кирпич?

По-моему, лучше в виде .bas-модуля, чтобы на таскать с собой лишние файлы библиотек.

[BV]

И какая бы разница должна быть между обычным и модифицированным компилятором? Не понимаю.

Не модифицированным, а обернутым -- аналог Pre-Build в VC++. Обертка парсит код на наличие определенных функций и вставляет на их место заготовленный inline с ассемблерным кодом (или как оно у тебя реализовано).

[Хакер]

По-моему, лучше в виде .bas-модуля, чтобы на таскать с собой лишние файлы библиотек.

Вот эта массовая истерия и вынудила меня поднять такой вопрос. Придётся делать две версии.

[Хакер]

Обертка парсит код на наличие определенных функций и вставляет на их место заготовленный inline с ассемблерным кодом (или как оно у тебя реализовано).

И зачем? Чем это лучше, чем просто иметь функцию CreateCoolThread (название чисто условное), являющуюся обёрткой над CreateThread?

Никто не любит плагины, потому что если реализовать какую-то магию модулем, то люди не побоятся его использовать, потому что проект с таким модулем скомпилируется в абсолютно любых условиях. Люди могут отправить такой проект кому угодно, будучи уверенным, что он у них станет работать. Проекты, для работы которых требуются аддины, обычно компилируются без эддинов, но работают при этом не правильно. Люди боятся использовать это, потому что кто-то, кто потом будет смотреть, может не знать, что проект требует определённый Add-in для правильной работы. Или может знать, но Add-in будет к тому времени утерян. Или не утерян, но политика будет запрещать установку сторонних Add-in-ов.

В общем, я подхожу к Add-in-ам так: делать их, либо когда фича опциональна (вроде расставлялки комментариев), либо когда по-другому вообще невозможно (вроде FNDLL).

Да и к тому же, откуда Add-in-у знать, какой ThreadProc делать инициализацию контекста, а какой — не делать? Это выбор исключительно программиста.

[Debugger]

Я "За" bas-модуль, против dll-ок.
Несколько раз сталкивался с тем, что люди требовали (или же сторонний софт не позволял иначе) присылать один exe-файл. Приходилось пользоваться пакером.

[Хакер]

Дело в том, что делать это на VB получится не так красиво и главное не так эффективно, как это можно было бы сделать с помощью dll.

Многопоточность сделать на VB я смогу легко, а вот эмуляцию TLS и хитрый маршаллинг интерфейсных указателей между апартаментами — уже не обещаю.

Поэтому, боюсь, придётся делать два варианта:

• Для тех, кто страшится DLL, не самый эффективный вариант
• Для тех, кто уважает эффективность и не боится DLL

[ger_kar]

Классно.
Я конечно не знаю объема кода на Си, но мне здается его будет не очень много поэтому хочу предложить свой вариант, который заключается в следующем. Оставить библиотеку на Си, а вместо урезанного варианта на VB, сделать следующую фишку. Сделать из DLL бинарник, воткнуть его в файл ресурсов, сделать на его основе ассемблерную вставку, которую конечно же правильней называть вставкой в машинных кодах и сделать соответствующую обертку на основе простого модуля. Таким образом надо будет подключить к проекту соответствующий модуль и файл ресурсов, а как итог, те кто не любит DLL, получат туже эффективность и функционал, в одном экзешнике. Если код по объему совсем маленький, то можно не заморачиваться на файл ресурсов, а сделать в одном модуле.
Что касается меня лично, то мне был бы интересней вариант на ассемблере вместо Си, хотя если затея по объему реализации не маленькая, то делать это на асме будет чистый мазохизм. Поэтому я это предложил чисто гипотетически не имея практически никаких данных, а лишь окрыленный тем, коротким кусочком на ассме, который я увидел в этой теме .
Заранее уверен, что Хакеру моя идея точно не понравиться, но у неё тоже есть свои плюсы. Один из которых не надо будет второй реализации на VB, фактически это получиться одна реализация в разных ипостасях

[ger_kar]

Я "За" bas-модуль, против dll-ок.Несколько раз сталкивался с тем, что люди требовали (или же сторонний софт не позволял иначе) присылать один exe-файл. Приходилось пользоваться пакером.

Я не против Dll, как таковых, но такие реализации бывают в некоторых случаях очень неудобными. Например если, что-то приходится делать на VBA. Хотя я не припоминаю, чтобы там когда нибудь требовалась многопоточность, но бывает всякое. Да и к тому же я не про этот вариант, а про dll вообще хотел сказать. Ладно в VB можно слепить дистрибутивчик, для чего даже просто архиватор можно задействовать и положить в него несколько Dll'ок и при надобности даже их регистировать. Другое дело, когда документ с автоматизацией на VBA, в этом случае dll это жуткий геммор.

[Mikle]

А возможен вариант lib-файла, чтобы я мог линковать кирпич к своему движку в dll?

[Хакер]

В принципе возможен.
Только как и чем ты влинкуешь? У тебя самодельный модифицированный линкер или посредник между IDE и линкером?

[Mikle]

У меня движок, написанный на C++, в виде нативной dll, к нему я и хотел линковать.
Даже два движка - dx_vb и sr2d, последний полностью готов к многопоточности, опробовано в vb.net.

[Хакер]

Так моя dll ведь будет с исходниками.

Вообще, самым правильным будет засунуть мою функцию CreateBasicThread в рантайм, где ему и место. Вот с сишном рантайме _beginthread ведь сидит в самом рантайме, а не распростаняется в виде отдельного исходника или отдельной библиотеки

[Mikle]

самым правильным будет засунуть мою функцию CreateBasicThread в рантайм, где ему и место.

И таскать с приложением весь рантайм, когда он и так везде есть, лучше пусть моя dll станет на несколько килобайт тяжелее.

Так моя dll ведь будет с исходниками.

Тогда Ok.

[Хакер]

И таскать с приложением весь рантайм, когда он и так везде есть, лучше пусть моя dll станет на несколько килобайт тяжелее.

Я думаю стоит таскать, ради огромного числа новых фич?

[ger_kar]

Я думаю стоит таскать, ради огромного числа новых фич

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

многопоточность и NativeDLL. Потому что и там и там всё падало и рушилось именно по этой причине: не инициализирован контекст, а рантайм ожидает обратного.

еще и новая версия FNDLL грядет, если разрешиться проблема с инициализацией контекста?

[Mikle]

просто патчер встраивать в приложение

А тебе винда даст патчить её рантайм? А если семёрка, да не под админом?

стоит таскать, ради огромного числа новых фич

Если так - то стоит, особенно, если в Win8 уже не будет vb6 рантайма.

[ger_kar]

А тебе винда даст патчить её рантайм?

Мне даст! , а вот другим ...

Если так - то стоит, особенно, если в Win8 уже не будет vb6 рантайма.

Кто так сказал? Вот гады.

[Mikle]

Кто так сказал? Вот гады.

Это я гипотетически. Не в восьмёрке, так в девятке, рантайм уберут.

[Хакер]

Это я гипотетически. Не в восьмёрке, так в девятке, рантайм уберут.

Сегодня мне прислали билд рантайма из семёрки, так он сделан в 2009 году. Если в 2009 году кто-то в Microsoft перекомпилирует рантайм, правя мелкие баги (крупных там нет), значит не всё так плохо.

[BV]

И зачем? Чем это лучше, чем просто иметь функцию CreateCoolThread (название чисто условное), являющуюся обёрткой над CreateThread?

тем, что
1. Так приятнее, когда проект внешне выглядит чисто, и всю грязную работу проделывает относительно скрытый от взора аддон
2. Нет нужды таскать с собой лишнюю dll. Вроде бы мелочь, но в ряде случаев может стать большим неудобством

и 3, это решает твой вопрос с функциональностью

В общем, я подхожу к Add-in-ам так: делать их, либо когда фича опциональна (вроде расставлялки комментариев), либо когда по-другому вообще невозможно (вроде FNDLL).

Эта фича как раз опциональна.

так он сделан в 2009 году

Дата изменения не говорит о перекомпиляции. Билд вырос, на 13 единиц в сравнении с тем, что в XP.

[ger_kar]

Я незнаю, как там дальше будет обстоять дело с VB6, но есть самый свежий выпуск Office2010 с поддержкой VBA и хотелось бы, чтобы про это не забывали, хотя в VBA многопоточность может понадобиться разве что в Access.

[Хакер]

Небольшой отчёт о прогрессе.
В четверг у меня наконец выпало время сесть за написание кирпча. Я решил начать с dll-варианта на Си/Си++, хотя до сих пор планирую делать оба варианта (в виде отдельной DLL и в виде bas-модуля). Писать dll-версию на сях приятнее, в том плане, что не нужно решать проблемы в стиле «а как же нам из VB, где поддерживается только stdcall, сделать thiscall-вызов?». Зато написание DLL на порядок сложнее, потому что bas-модуль обеспечивает многопоточность только своего проекта, а DLL должна писаться с расчётом на то, что в адресном пространстве могут оказаться 10 разных VB-проектов, использующих 7 разных версий рантайма (засчёт переименования импорта), причём эти проекты могут динамически загружаться/выгружаться из адресного пространства процесса. В общем, писать приходится больше, но писать комфортнее. В VB-версии будет меньше кода, но он будет не такой эм... красивой.

Сегодня первый день, когда я сделал первый успешный билд DLL, который даёт хоть какую-то многопоточность. Последнее — ключевое. До этого было просто недостаточно написано кода для обеспечения многопоточности. Осталось довести библиотеку до ума, и затем браться за bas-версиб. В частности, не готов такой компонент dll-кирпича как кеш проектов/рантаймов. Дело здесь в том, что для инициализации нормально-работающего потока нужно найти ряд функций рантайма, который не экспортируются рантаймом, и одну структуру из EXE-шника проекта (которая, разумеется, тоже не экспортируется). Чтобы не искать эти функции и структуры каждый раз при создании нового потока, будет кеш, который будет «вычислять» все необходимые параметры для создания хорошего потока единожды.

По этому поводу хочу поделиться картинками:

Тестовая программа, из которой создано 5 новых потоков. В каждом показан либо MsgBox (ждущий закрытия), либо InputBox (ждущий закрытия). Между окнами можно спокойно переключаться, они не блокируют друг-друга, потому что принадлежат разным потокам.

Если посмотреть в Диспетчер задач, то видно, что потоков действительно шесть (5 новых + 1 главный):


Потоки работают стабильно, в них можно вызывать любые функции рантайма, создавать экземпляры любых классов рантайма (например Collection), внешнего мира (например FileSystemObjects или WMI) или же своего собственного проекта. Показывать экземпляры форм. Можно вызывать API через Declare, а уж через TLB — тем более. Разумеется, работают в условиях многопоточности и все мои предыдущие кирпичи вроде «вызовов по указателю».

Spy++ показывает эти потоки вот так:


А OllyDbg вот так:


Можете сверить идентификаторы потоков с первой картинкой

Вот код тестовой программки:
Форма Form1:

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

Private Declare Function CreateBasicThread Lib "vbthrds.dll" (lpSecAttr As Any, ByVal pStartProc As Long, ByVal pSParam As Long) As Long

Private Sub Form_Load()
    Label1.Caption = "Главный поток, TID = " + CStr(App.ThreadID)
End Sub

Private Sub Hello_Click()
    CreateBasicThread ByVal 0&, AddressOf HelloProc, 0
End Sub

Private Sub InpBox_Click()
    CreateBasicThread ByVal 0&, AddressOf InpBoxProc, 0
End Sub

Модуль Module1:

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

Private Declare Function GetCurrentThreadId Lib "kernel32" () As Long

Public Function HelloProc(ByVal xParam As Long) As Long
    MsgBox "Привет! Привет! Привет из нового потока! Мой TID = " + CStr(GetCurrentThreadId)
End Function

Public Function InpBoxProc(ByVal xParam As Long) As Long
    InputBox "Мой TID равен " + CStr(GetCurrentThreadId) + ". Вам нравится многопоточность?", , "Очень даже"
End Function

Public Sub Main()
    MsgBox "Я Sub-Main и сейчас покажу инстанс формы"
    Form1.Show
End Sub


Как видите, ничего хитрого, всю работу по созданию нового потока берёт на себя кирпич, вам просто нужно создавать новый поток не с помощью CreateThread, а с помощью CreateBasicThread. Пусит вас не смущает, что у неё только 3 параметра, это временно.

Ну и на закуску: кусочек кода кирпича:

(Красной дужкой обведён кусочек кода, наличие которого меняет всё с «ничего не работает» на «всё работает прекрасно». Всё остальное код в проекте — чтобы работало ещё и быстро, удобно и в самых «тяжелых» случаях).

Ждите кирпич

[arthur2]

Здорово! Давай скорей - не терпится потестить

Я тоже за двойной вариант - и длл, и модуль.

[ger_kar]

Если Dll появиться раньше, я думаю, можно сначала сделать релиз Dll, а потом когда появиться модуль, тогда и его.

[arthur2]

Кстати, а как будет работать отладка и будет ли? Ведь даже если будет - я так понимаю, что только в первом потоке, в котором и сама ИДЕ?