Логическое ИЛИ

У меня возникла проблема с записью в реестр REG_BINARY числа в перевёрнутом виде.
Например, 0x480 как 80,04. Вообщем я крутил вертел, и додумался до битовых операций,
сам ничего толком не понимая. Однако это работает! Неужели правильно?

Вот пример скрипта...

Код (Text):

1. $x = BitOR(@DesktopWidth, @DesktopWidth)
2. $y = BitOR(@DesktopHeight-52, @DesktopHeight-52)
3. $z = Binary(0) & Binary(0) & Binary($x) & Binary($y) & Binary(0)
4.  
5. RegWrite("HKCU\Software\VirtualDub.org\VirtualDub\Window Placement", "Main window", "REG_BINARY", $z)
6.  
7. ShellExecute(@ProgramFilesDir & "\VirtualDub\Veedub64.exe", $CmdLineRaw)

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

И почему в моём примере это работает - типа DesktopWidth OR DesktopWidth ?
Или это до первого глюка? )))

 

Вот сабж

Кстати, в скрипте Binary(0) почему-то сразу по четыре байта нулей пишет. Что это за блоки?

 

Никакой проблемы тут нет, т.к. "перевернутый вид" это просто соглашение о порядке вывода\отображений байт - если одно и то же число 0х480 записать как REG_DWORD, то оно будет отображаться от старших байт к младшим, т.е. 00 00 04 80, а если REG_BINARY, то наоборот от младших к старшим 80 04 00 00 - хотя на самом деле это одно и то же

Это "не работает", т.к. побитовый OR числа самого с собой ничего не изменяет: X or X = X

 

Я догадывался об этом, но просто запутался, понятно значит это пустая функция получилась. :\
Зато теперь запомню про "OR самого с собой"... вообще поучить бы это толково из хорошего мануала
или статьи...

 

Ну это очевидно, просто рядом не нашлось функций подходящих...

 

Semiono
0010 0010 1000 1000
0010 0101 0100 1001
0010 0111 0000 1000
or1 or2 and1 and2

Побитные операции работают с битами)) Или работает как или или там еденичка или там.... "И" работает как, если там единичка а там ноль - значит у них двоих нету единички)
ну а вообщем лучше в гугль с такими вопросами или в бурсу
http://ru.wikipedia.org/wiki/Битовые_операции

ну а для того что бы перекинуть местами ворды в дворде есть команда xchg.

 

Спасибо, ребят, что есть такой форум. Буду учиться!

 

А я тут хотел чтоб OR с байтами работал - BitOR(@DesktopWidth, @DesktopWidth),
причём чтоб менял их по моему волшебному желанию )))

угу +1 )))

хорошая команда для яваскрипт

 

работать с байтами он будет даже с двордами, только СРАВНИВАТЬ будут побитно))

ну а тут чёт не заметил)
вообщем почему бы не сделать обмен байтами через буферок...

Код (Text):

1. WORD in,
2.           tmp;
3.  
4. HIWORD( tmp ) = LOWORD( in );
5. LOWORD( tmp ) = HIWORD( in );
6. in = tmp;

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

 

Кстати, хотел попробывать в асме `How To Get The Screen Resolution In Pixels` получить...
http://cppkid.wordpress.com/2009/01/07/how-to-get-the-screen-resolution-in-pixels/

Не получается

Код (Text):

1. section '.code' code readable writeable executable
2.  
3. struc   rect left,right,top,bottom
4. {
5.         .left   dd ?
6.         .right  dw ?
7.         .top    dw ?
8.         .bottom dw ?
9. }
10.  
11.         xor eax,eax
12.         invoke  GetWindowRect,hWnd,r1
13.         invoke  wsprintf,zz,'%u',r1
14.         invoke  MessageBox,NULL,zz,zz,MB_OK
15. exit:
16.         invoke  ExitProcess,0
17.  
18. section '.data' data readable writeable
19.  
20. zz dd ?
21. hWnd dw ?
22. r1 rect .top

Для меня структуры это убиственно! http://msdn.microsoft.com/en-us/library/dd162897(v=VS.85).aspx
Нифига не понятно

 

Вот это *PRECT куда совать ? :'(

 

это объявления типа в сях, тебе оно не нужно)
*PRECT - говорит о том что объявлен указатель на структуру типа RECT

Invoke hWnd, addr r1 ;вот тебе и *PRECT

ну а если по теме - єто уже не по теме, ИЛИ тут не при чём, тем более логическое.)

ну а по поводу
How To Get The Screen Resolution In Pixels

лучше юзать GetSystemMetrics( SM_CXSCREEN );

 

пасиб! )

 

GetSystemMetrics - там походу ширина только.
ссылка по соседству ведёт в GetDeviceCaps() что уже интересней.
однако, hdc, HORZRES фасм не знает ...include '%fasm%\api\gdi32.inc' 0_0

 

SM_CXSCREEN - ширина, SM_CYSCREEN - высота

 

Для любителей извращений есть такой вариант:
1) Складываем оба байта.
2) Записываем его в слово (byte*<<8+byte).
3) Вычитаем из получившегося слова исходное.
Для замены порядка байтов в Си есть какая-то функция (не помню названия), а в ассемблере - команда xchg, как уже сказали.
Вот только пока найдешь или вспомнишь нужную команду, быстрее самому это реализовать.

 

+1 там такая таблица до потолка, что я не стал читать, лучче спросить

 

О, еще один извращенец
ТС тут наворотил сам не понимая чего, а ему продолжают советы давать как байты переворачивать, да еще и на С или асме. А нафига их вообще переворачивать, если в RegSetValueEx передается указатель на двоичные данные "как есть" независимо от того, dword это или binary произвольной длины ?!
Еще раз повторю, что "переворачиваются байты" только в строковых представлениях двоичных данных, т.к. в Hex-виде принято произвольные двоичные данные записывать как есть от младших байтов к старшим, а числа типа dword - "переворачивать" старшими вперед. Вот если бы ТС для своего скрипта лепил итоговую строку функцией Hex, работающей с целыми числами и соотв-но выдающую байты от старших к младшим, тогда бы ему пришлось чесать репу, как это все перевернуть. Но он додумался сконвертить числа в тип Binary, которые при преобразовании в строку автоматом конвертятся в Hex-вид от младших к старшим - поэтому все и работает.
PS: Хотя того же самого, по видимому, можно было бы добиться и без преобразования в строку, а просто записать числа в массив, который и передать в RegWrite - дальше по идее этот супер-пупер скрипт "а-ля васик" должен сам разобраться с типами и записать данные "как положено"

 

Semiono

Прежде чем читать все подряд, стоило бы поднапрячь мозг и связать обозначение SM_CX с координатой X и соотв-но с шириной, а значит высоту нужно искать среди SM_CY
А вообще-то, да, новое оформление мсдн вызывает, мягко говоря, "двойственные чувства". Помнится когда-то родственные значения SM_CX и SM_CY были сгруппированы в одной строке и соотв-но таблица была вдвое "ниже потолка"

 

вот-вот! но мне новый мсдн нравиться, либо привыкать стал к нему.