Работа с Variant на низком уровне

[jangle]

Можно ли в VB эмулировать UNION? чтобы работать с отдельными элементами VARIANTDATAUNION.
Вот пример на PB

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

#Compile Exe
#Dim All
#Include "win32api.inc"

' ========================================================================================
' VARIANTDATA UNION
' ========================================================================================
Union VARIANTDATAUNION
   bVal As Byte            ' VT_UI1
   iVal As Integer         ' VT_I2
   lVal As Long            ' VT_I4
   fltVal As Single        ' VT_R4
   dblVal As Double        ' VT_R8
   boolVal As Integer      ' VT_BOOL
   scode As Long           ' VT_ERROR
   cyVal As Long           ' VT_CY
   date As Double          ' VT_DATE
   bstrVal As Long         ' VT_BSTR
   punkVal As Dword        ' VT_UNKNOWN
   pdispVal As Dword       ' VT_DISPATCH
   tblob As BLOB           ' VT_BLOB
   parray As Dword         ' VT_ARRAY|*
   pbVal As Byte Ptr       ' VT_BYREF|VT_UI1
   piVal As Integer Ptr    ' VT_BYREF|VT_I2
   plVal As Long Ptr       ' VT_BYREF|VT_I4
   pfltVal As Single Ptr   ' VT_BYREF|VT_R4
   pdblVal As Double Ptr   ' VT_BYREF|VT_R8
   pboolVal As Integer Ptr ' VT_BYREF|VT_BOOL
   pscode As Long Ptr      ' VT_BYREF|VT_ERROR
   pcyVal As Long Ptr      ' VT_BYREF|VT_CY
   pdate As Double Ptr     ' VT_BYREF|VT_DATE
   pbstrVal As Long Ptr    ' VT_BYREF|VT_BSTR
   ppunkVal As Dword Ptr   ' VT_BYREF|VT_UNKNOWN
   ppdispVal As Dword Ptr  ' VT_BYREF|VT_DISPATCH
   psArray As Dword Ptr    ' VT_ARRAY|*
   pVariant As Dword Ptr   ' VT_BYREF|VT_VARIANT
   pByRef As Dword         ' Generic ByRef
End Union
' ========================================================================================

' ========================================================================================
' VARIANTAPI structure
' ========================================================================================
Type VARIANTAPITYPE
   vt         As Word  'VARTYPE
   wReserved1 As Word
   wReserved2 As Word
   wReserved3 As Word
   vd               As VARIANTDATAUNION
End Type
' ===


Function GetLong(ByVal lpv As VARIANTAPITYPE Ptr) As Long
   Function=@lpv.vd.lVal
End Function

Sub SetLong(ByVal lpv As VARIANTAPITYPE Ptr, ByVal lng As Long)
    @lpv.vd.lVal=lng
End Sub

Function PBMain () As Long
  Local vLong As Variant
  Local lng   As Long
   vLong=123%

   lng=GetLong(VarPtr(vLong))
   Incr lng

   SetLong VarPtr(vLong), lng
   MsgBox Str$(Variant#(vLong))

  End Function

[Mikle]

Если поместить структуры в массивы, то это не сложно, смотри статью Хакера про массивы.

[Хакер]

Непонятно, зачем вообще что-то эмулировать? Нужное поле находится по смещению +8 в структуре, берём и пишем в него нужные данные.
Эффект Union-а можно получить многими разными способами. И маппнуть SA-дескриптор на модифицируемые данные, и взять второй вариант и с помощью VT_BYREF сделать из него VARIANTARG, указывающий на dw[+08] первого варианта.

[jangle]

Непонятно, зачем вообще что-то эмулировать?

хочу ускорить операции с Variant. Например: @lpv.lVal= @lpv.lVal + i работает раз в 10 быстрее

чем : lpv=lpv+i

И маппнуть SA-дескриптор на модифицируемые данные, и взять второй вариант и с помощью VT_BYREF сделать из него VARIANTARG, указывающий на dw[+08] первого варианта.

готового решения нет?

[Хакер]

хочу ускорить операции с Variant. Например: @lpv.lVal= @lpv.lVal + i работает раз в 10 быстрее
чем : lpv=lpv+i

Если речь о VB, то к чему тут эта еретическая нотация? Если речь о PB, то зачем спрашивать это здесь?
Если есть гарантия, что в Variant-е заведомо хранится целое число, то зачем вообще вариант?
Если уверенности нет, то к чему странные желания править значение напрямую, пропуская обработку поля «vt»?

[jangle]

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

Option Explicit
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)

Private Type PROPVARIANT
  skip(0 To 7) As Byte
  VT_I4 As Long
End Type

Private Sub Form_Load()
    Dim v1 As Variant
    Dim v2 As PROPVARIANT
    v1 = 100
    CopyMemory VarPtr(v2), VarPtr(v1), 16
    MsgBox v2.VT_I4
End Sub

Пока просто копирование не работает. Хотя уже само использование вызова RtlMoveMemory делает практически бессмысленной работу по-оптимизации.

[Хакер]

jangle, это полнайшая чушь. У меня как-то до этой поры было мнение, что ты хоть чуть-чуть больше понимаешь в сути происходящих вещей.

Например, что ты хотя бы знаешь, чем отличается ByRef от ByVal. Ну и давать полю структуры имя, свойственное константе — это тоже печально.

[jangle]

jangle, это полнайшая чушь.

Разумеется чушь. Убожество VB не позволяет использовать ни UNION, ни необходимых типов данных для PROPVARIANTDATA.
А заниматься ****** на ровном месте нет желания. Без RtlMoveMemory не обойтись, значит и смысла в затее нет никакого.

[Хакер] :: Мат вырезан. Предупреждение.

[The trick]

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

Option Explicit

Public Declare Function GetMem4 Lib "msvbvm60" (src As Any, Dst As Any) As Long

Public Sub Main()
    Dim z   As Variant
    Dim l() As Long
    Dim s() As Single
    Dim c() As String
    Dim i1  As Long
    Dim i2  As Long
    Dim i3  As Long
   
    ReDim l(3)
    ReDim s(0)
    ReDim c(0)
   
    GetMem4 ByVal (Not Not l) + &HC, i1:    GetMem4 VarPtr(z), ByVal (Not Not l) + &HC
    GetMem4 ByVal (Not Not s) + &HC, i2:    GetMem4 VarPtr(z) + 8, ByVal (Not Not s) + &HC
    GetMem4 ByVal (Not Not c) + &HC, i3:    GetMem4 VarPtr(z) + 8, ByVal (Not Not c) + &HC
   
    'z = 1&
    'z = 1!
    z = "xyz "
   
    If (l(0) And &HFFFF&) = vbLong Then
        l(2) = l(2) + 1
    ElseIf (l(0) And &HFFFF&) = vbSingle Then
        s(0) = s(0) + 1!
    ElseIf (l(0) And &HFFFF&) = vbString Then
        c(0) = c(0) & " abcdefg"
    End If
   
    GetMem4 i1, ByVal (Not Not l) + &HC
    GetMem4 i2, ByVal (Not Not s) + &HC
    GetMem4 i3, ByVal (Not Not c) + &HC
   
    MsgBox z
   
End Sub


[The trick]

Убожество VB не позволяет использовать ни UNION, ни необходимых типов данных для PROPVARIANTDATA.

Юнионы небезопасны, к примеру замапь лонг и стринг, и поменяй лонг на 7 или 5 или любой невалидный адрес, а потом обратись к стринг. А под убожеством, как мне кажется, Хакер имел в виду то что ты совершенно неправильно использовал RtlMoveMemory, и получил неверный результат.

[Хакер]

Убожество VB не позволяет использовать ни UNION, ни необходимых типов данных для PROPVARIANTDATA.

А ещё VB не позволяет использовать ассемблерные вставки. Впрочем, как и Java или PHP или что-нибудь ещё. Вот ведь наплодили убожественных языков.

Ты бредишь. Во-первых, сто восемь лет назад я писал о том, что не стоит использовать RtlMoveMemory там, где можно использовать GetMem4/PutMem4 (или аналоги). Но кто-то считал ворон и не внял рекомендациям.

Во-вторых, если задача состоит в том, чтобы инкрементировать целочисленную перменную, то вообще ничего не надо копировать, а можно просто использовать InterlockedIncrement.

Но самое главное — это концептуальные и идеологически моменты, как обычно, а вовсе не технические детали. Конечно же, ты предпочёл проигнорировать важнейшие вопросы:

Если есть гарантия, что в Variant-е заведомо хранится целое число, то зачем вообще вариант?
Если уверенности нет, то к чему странные желания править значение напрямую, пропуская обработку поля «vt»?

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

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

Я слово «убожество» вообще не применял

[The trick]

Я слово «убожество» вообще не применял

Ну да, , чушь.

[jangle]

[code]Option Explicit
Public Declare Function GetMem4 Lib "msvbvm60" (src As Any, Dst As Any) As Long

У меня был интерес в ускорении операций с переменными Variant за счет прямого обращения к элементам UNION`а PROPVARIANTDATA.
В PB это удалось сделать. В VB же накладные расходы на вызов функции из DLL (там вроде 2 проверки происходит) скорее всего съедят эту оптимизацию. Так что смысла похоже нет. Проще оставить все как есть.

[Хакер]

Ещё раз:

Если есть гарантия, что в Variant-е заведомо хранится целое число, то зачем вообще вариант?
Если уверенности нет, то к чему странные желания править значение напрямую, пропуская обработку поля «vt»?

VB же накладные расходы на вызов функции из DLL (там вроде 2 проверки происходит) скорее всего съедят эту оптимизацию.

Бредятина. Вызов функции из DLL в общем случае, кроме самого первого вызова — это обычный вызов по указателю. Насколько быстр вызов проивзольной функции по указателю, настолько же быстр вызов DLL-функции.

[The trick]

У меня был интерес в ускорении операций с переменными Variant за счет прямого обращения к элементам UNION`а PROPVARIANTDATA.
В PB это удалось сделать. В VB же накладные расходы на вызов функции из DLL (там вроде 2 проверки происходит) скорее всего съедят эту оптимизацию. Так что смысла похоже нет. Проще оставить все как есть.

Ну ты замапь один раз (если конечно переменная не локальная) и пользуйся, потом освободишь. Можешь юзать tlb, тогда вызов будет быстрее. Можешь оптимизировать на ассемблере функцию целиком, я как раз сделал инлайн ассемблер работающий в IDE.

[Хакер]

Можешь юзать tlb, тогда вызов будет быстрее

Если речь идёт идёт о функциях типа RtlMoveMemory, то есть функциях, аргументы и возврат которых не касаются строк строками, то нет абсолютно никакой разницы разницы в плане быстродействия рядового вызова между TLB и Declare Sub/Function.

И там и там будет call [xxxxxxx], где xxxxxxx — адрес либо ячейки IAT, либо ячейки,в которую DllFunctionCall записала прямой адрес функции при первой попытке, то есть и там и там — «ячейка памяти», приходящаяся на секцию кода.

[jangle]

Бредятина. Вызов функции из DLL в общем случае, кроме самого первого вызова — это обычный вызов по указателю. Насколько быстр вызов проивзольной функции по указателю, настолько же быстр вызов DLL-функции.

вот другое мнение

Каждый раз. При вызове через декларирование в tlb происходит прямой непосредственный вызов и ничего более. При вызове через declare происходит сначала проверка была ли инициализирована специальная структура содержащая адрес api функции, потом происходит сам вызов. После возврата из функции происходит вызов функции рантайма __vbaSetSystemError которая устанавливает значение переменной члена Err.LastDllError. Фактически каждый вызов функции транслируется в 2 вызова.

[The trick]

Можешь юзать tlb, тогда вызов будет быстрее

Если речь идёт идёт о функциях типа RtlMoveMemory, то есть функциях, аргументы и возврат которых не касаются строк строками, то нет абсолютно никакой разницы разницы в плане быстродействия рядового вызова между TLB и Declare Sub/Function.

И там и там будет call [xxxxxxx], где xxxxxxx — адрес либо ячейки IAT, либо ячейки,в которую DllFunctionCall записала прямой адрес функции при первой попытке, то есть и там и там — «ячейка памяти», приходящаяся на секцию кода.

Вот вызов через Declare, тот код который вызывается когда мы вызываем API функцию:

Declare.PNG (3.9 Кб) Просмотров: 12790

Как видно идет проверка по адресу 403340h, и она идет всегда. После вызова идет вызов __vbaSetSystemError.
Вот вызов через tlb:

TLB.PNG (4.34 Кб) Просмотров: 12790

Как видно идет вызов непосредственно функции. И если не было задано usesgetlasterror, то функция __vbaSetSystemError не вызывается.

[jangle]

я как раз сделал инлайн ассемблер работающий в IDE.

и где его можно скачать?

[The trick]

я как раз сделал инлайн ассемблер работающий в IDE.

и где его можно скачать?

У меня в блоге viewtopic.php?f=99&t=51825. Кстати как закончу работу над одним коммерческим проектом, добавлю в инлайн ассемблер интеграцию с некоторыми сущностями VB, т.е. можно будет делать к примеру так:

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

mov eax, UserVariable
call VBFunction

[Хакер]

Как видно идет проверка по адресу 403340h, и она идет всегда. После вызова идет вызов __vbaSetSystemError.

Да, приношу извинения — тут я перепутал с чем-то (возможно с тем, как это стоило бы оптимизировать).

Можно было бы по адресу
401884 вместо mov eax, [403340] иметь jmp dword[403340], а DWORD по адресу 403340 изначально инициализировать значением 40188F. Либо сразу там, где стоит call 401884 ставить call [403340].

[jangle]

У меня в блоге viewtopic.php?f=99&t=51825. Кстати как закончу работу над одним коммерческим проектом, добавлю в инлайн ассемблер интеграцию с некоторыми сущностями VB, т.е. можно будет делать к примеру так:

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

mov eax, UserVariable
call VBFunction

круто! А ты бы мог написать на онлайн-ассемблере аналоги функций: Poke, Peek, CopyMemory, FillMemory, SwapMemory.
Чтобы раз и навсегда отказаться от вызова их из DLL

[Хакер]

Чтобы раз и навсегда отказаться от вызова их из DLL

Чем плох вызов из DLL?

[jangle]

Чем плох вызов из DLL?

Лишняя dependency в проекте. Лучше без нее, чем с ней.

[The trick]

круто! А ты бы мог написать на онлайн-ассемблере аналоги функций: Poke, Peek, CopyMemory, FillMemory, SwapMemory.
Чтобы раз и навсегда отказаться от вызова их из DLL

Можно, но смысла в этом мало, если только отказываться от специфических библиотек, а так по быстродействию это будут те же GetMem, PutMem. Кстати эти функции можно написать на чистом VB используя массивы, и отключив проверку границ viewtopic.php?f=1&t=50816#p6781889.
Можно даже рантаймовские переопределить на этапе линковки. К примеру в драйвере я не мог юзать строки, потому что неизбежно вызывалась рантаймовская StrCopy (или как-то так не помню уже), так ее можно заменить на свою и отказаться от рантайма. Это может пригодится в каких-нибудь инсталляторах или драйверах.

[The trick]

Чем плох вызов из DLL?

Лишняя dependency в проекте. Лучше без нее, чем с ней.

Кстати можно вообще отказаться от непосредственного вызова API, правда это сильно влияет на скорость, но это очень полезно в некоторых задачах. Я как-то писал модуль лоадера для криптора EXE файлов, так вот там нет ни одного явного API вызова все реализовано через нативный VB грязными трюками, зато не палится антивирусами. А помогает в этом ничем не приметный IPicture.

[Хакер]

Ну да, придётся носить с собой kernel32.dll, или, о боже, msvbvm60.dll

Самое тупое, что, по моему мнению, существует в сознании людей (из Win32-программистской тусовки) — это DLL-фобия. Видимо идея DLL в отношении некоторых групп личностей опередила своё время (как бы глупо это ни звучало), а эти люди испытают дикий восторг от получения гигантских монооитных EXE.

[jangle]

Кстати можно вообще отказаться от непосредственного вызова API, правда это сильно влияет на скорость, но это очень полезно в некоторых задачах.

Встроенные функции работы с памятью удобны. Покойный автор PB понял, что народ массово использует RtlMoveMemory, и реализовал встроенную функцию Memory Copy, постаравшись ее максимально оптимизировать по-скорости работы. И в итоге она работает быстрее, и синтаксис тот же самый.

[The trick]

Кстати можно вообще отказаться от непосредственного вызова API, правда это сильно влияет на скорость, но это очень полезно в некоторых задачах.

Встроенные функции работы с памятью удобны. Покойный автор PB понял, что народ массово использует RtlMoveMemory, и реализовал встроенную функцию Memory Copy, постаравшись ее максимально оптимизировать по-скорости работы. И в итоге она работает быстрее, и синтаксис тот же самый.

Сделаю как-нибудь, даже через SSE можно, там сразу большие блоки можно копировать/заполнять за раз, можно сделать просто OBJ и линковать его ко всем проектам.

[jangle]

Ну да, придётся носить с собой kernel32.dll, или, о боже, msvbvm60.dll

Все верно. Станут VB перетаскивать под новую операционку типа MenuetOS, KolibriOS и т.п. Чем меньше зависимостей, тем проще портировать.
Может MSVBVM60 свою напишут, где не будет GetMem или они будут работать по-другому. Или надо защитить программу от взлома, эти GetMem как открытые форточки в доме.