Кодерский уголок

Напоролся сегодня на "магию" в 16-битном MASM. Есть огромный проект с макросами на макросах, которые погоняют макросами. Так вот, в одном из макросов, когда пишется подряд две строчки: push ds и pop ds (просто ради теста), весь функционал виснет. Если их заменить на любые другие регистры в любом количестве - все работает. То есть проблема не в стеке и не в занимаемом кодом месте. В других местах, программа нормально отностится к пушанью DS. В чем может быть магия?!

 

"весь функционал виснет"? Сие как должно понимать? Макрос весь давай, покумекаем.

 

Вобщем-то я уже заготовил воркэраунд. Переключаю сегменты в начале вызова функции, где push/pop для DS работат, а нужное значение сохраняю в переменную в текущем сегемнте.
Но все-таки просто интересно, почему оно не работало.
Насчет "макрос весь". Пожалуйста (хотя не думаю, что он поможет):

Код:

spec_case	macro	name,logic,draw
if1
name&_DEST_ADJ = 0
endif
	logic				;;Define required macros

name&_disp_table label byte
	db	name&_loop_0-name&_loop
	db	name&_loop_1-name&_loop
	db	name&_loop_2-name&_loop
	db	name&_loop_3-name&_loop
if UNROLL_BY_8
	db	name&_loop_4-name&_loop
	db	name&_loop_5-name&_loop
	db	name&_loop_6-name&_loop
	db	name&_loop_7-name&_loop
endif

	public	name
name	proc	near
	mov	bl,byte ptr clipped_font_height
if UNROLL_BY_8
	and	bx,0007h
else
	and	bx,0003h
endif
	mov	bl,name&_disp_table[bx]
	add	bx,CodeOFFSET name&_loop
	mov	unrolled_entry_point,bx
	mov	dx,ss_next_scan 	;;Index to next scan of a bitmap
if name&_DEST_ADJ
	dec	dx
else
	nop
endif
	entry_logic			;;Any specific entry logic required

name&_outer_loop proc near
	loop_setup			;;Char offset fetching
	mov	ch,byte ptr clipped_font_height
	jmp	unrolled_entry_point

	even
name&_loop:
name&_loop_0:
	draw	<fetch_logic>
	add	di,dx
name&_DEST_ADJ = DRAW_ADJUST		;;Need to know if a stosb was used

if UNROLL_BY_8
name&_loop_7:
	draw	<fetch_logic>
	add	di,dx

name&_loop_6:
	draw	<fetch_logic>
	add	di,dx

name&_loop_5:
	draw	<fetch_logic>
	add	di,dx

name&_loop_4:
	draw	<fetch_logic>
	add	di,dx
endif

name&_loop_3:
	draw	<fetch_logic>
	add	di,dx

name&_loop_2:
	draw	<fetch_logic>
	add	di,dx

name&_loop_1:
	draw	<fetch_logic>
	add	di,dx
if UNROLL_BY_8
	sub	ch,8
else
	sub	ch,4
endif
	ja	name&_loop

name&_done_char:
	loop_logic name&_outer_loop
	jmp	ret_addr		;To caller

name&_outer_loop endp

name	endp
	endm

Здесь в середину макроса draw передатеся макрос fetch_logic, который есть частью макроса logic (draw и logic передаются, как параметры). Так вот, в этом fetch_logic была захардкоджена константа, которую нужно заменить на переменную из другого сегмента данных. Даже если вписать пустой push/pop для DS, скажем, перед jmp unrolled_entry_point - программа больше не работает. Любые другие изменения ничего не ломают. Я могу пушать-попать все рагистры, писать хитрую логику, но на DS - табу. Почему - никак в голову не вкладывается!
А вот что за программа, как не работает и почему я ее не дебажу, я напишу чуток позже - сюрприз будет, благо воркэрануд нашел .

 

С таким количеством дополнительных макросов и переменных, влияющих на поведение формируемой процедуры - неудивительно, если не поможет. Мне так точно не помогло - если заменить недостающие части пустышками, всё просто работает, с push/pop или без, увы. Но там же огромных кусков не хватает, так что гадать без исходника можно ещё очень долго.

И не понятно ни рожна Ну процедура формируется, ну блок меток-разностей, ну ещё одна внутри неё. Ничего особенного. Я не представляю, почему виснет.

ret_addr портится? ss_next_scan?

UNROLL_BY_8 / DRAW_ADJUST - загадка, logic / draw - макросы и никто не знает, что в них.

Вот это самый интересный вопрос

 

Потому что не компилируется?

 

A.P.$lasH, Рыжий Тигра,
Ладно, времени баловаться сейчас нет, так что "открою карты". Пишу я универсальный видео-драйвер под вторую винду. Собрать отдельные драйвера, скажем для 16 цветов 640х350, 640х480, 800х600 - проще пареной репы. Но если мы захотим поменять расширение, то, увы, придется переставлять винду. Проблема в том, что все данные под текущий режим захардкоджены. Соответственно, драйвер компилится под конкретный один режим. Мне удалось добить всю эту фигню. Теперь за видео режим отвечает один байтик в ОЗУ, поменяв который можно переключатся между тремя режимами, по идее, даже не перезапуская саму винду. Только вот теперь вопрос в написании переключателя. Сначала возникла проблема, что Винда копирует данные из драйвера куда-то себе. Проблему, вроде пофиксал таким ообразом: когда винда первый раз запрашивает данные, я сохраняю адрес в который их нужно копировать. При измененнии режима, меняю данные и по тому адресу. Надеюсь, что они больше никуда не пересылаются, хотя... Но есть еще одна проблема: написать саму функцию-переключатель. Непосредственно функции драйвера дергает только сама винда, пользовательские программы не имеют к ним доступа. Нужно извратится и "выколупать" эти функции из ядра. Увы, архитектура "двойки" солидно отличается даже от 3.0, а ассортимен WinAPI для подобных операций скудный до безобразия. Вот, теперь, когда будет время, подумаю, как все-таки выколупать из собранного виндового бинаря нужную функцию.
А не дебажу, потому что собрать дебажную Винду дольше, чем прицепить воркэраунд .

 

А что тогда виснет, блокнот с исходником?

Zelya, это ещё и двойка... Круто

Вот тут лучше спросить, даже на таких условиях.
http://www.cyberforum.ru/drivers-programming/

 

Нет, Винда виснет при загрузке, если добавть эти злосчастные push/pop DS где-то в районе того макроса. В соседних макросах, или в функции, где они используются, все работает. Мне вобще в голову не укладывается, как такой код мог бы поломать программу?! Ладно, если б были проблемы со стеком или с размером кода, но тогда любой другой push pop должен был бы тоже не работать. Магия одним словом.

Да ладно, проехали. Главное проблему-то обошел. Тем более по дровам ниже Винды 3.1 вряд ли хоть кто-то подскажет.

Сейчас главное, как мою DeviceMode функцию из win200.ovl дернуть. Лежит - вот она, на поверхности, рядышком со всеми остальными, а вот дернуть ее из проги, ну никак, пока не выходит. Нужно, наверное, забить на WinAPi и обычной сишкой колупать. Хотя не знаю, получится ли. Вдруг сишка попробует лоадить этот win200.ovl, а он уже в памяти. Короче, нужно пробовать, а времени нет.

---------- Сообщение добавлено в 12:54 ---------- Предыдущее сообщение размещено в 12:48 ----------

ПС Конечно, всегда есть вариант WinAPI расширить, но, пока надеюсь на лучшее

 

Я понял. Тигра же предположил, что не компилируется

Так ведь порча других регистров может и не проявиться, в отличие от сегмента данных, который буквально при следующем обращении к любой переменной даст о себе знать. А что если после push/pop проверить, что вытолкнулось, совпадает ли с исходным? На любом регистре проверить.

Раз уж отладки не было, где гарантия, что результат не портился?

Там ребята весьма неглупые, я бы не зарекался. Хороший форум.

 

Проверить-то можно, но мне уже лень . Непонятно просто, как DS может портится. Мы ж его достаем сразу же как только положили. Спцеиально для теста писал, так как мой код не работал.

 

Эт святое, да.

Ну а как раньше можно было без cli/sti скормить прерыванию новый сегмент стека со старым смещением? И тоже, казалось бы, подряд присваиваем ss/sp.

 

Программирование сведений о системе

Пробовал вставить код:

(код

Код:

using System;
using System.Management;

namespace Win32_Processor
{
class Class1
{

static void Main(string args)
{
// ╧юыєўрхь тёх яЁюЎхёёюЁ√ ъюья№■ЄхЁр
WqlObjectQuery query = new WqlObjectQuery(
"Select * from Win32_Processor");
ManagementObjectSearcher find = 
new ManagementObjectSearcher(query);
int i = 0;
foreach (ManagementObject mo in find.Get()) 
{
Console.WriteLine("-- Processor #" + i + " -");
Console.WriteLine("Processor address width in bits." +
mo);
Console.WriteLine("Architecture of processor." +
GetArchitecture(mo));
Console.WriteLine("Caption." + mo);
Console.WriteLine("Processor address width in bits." +
mo);
Console.WriteLine("Usage status of the processor." +
GetCpuStatus(mo));
Console.WriteLine("Current clock speed (in MHz)." +
mo);
Console.WriteLine("Processor data width." + mo);
Console.WriteLine("Unique string identification." +
mo);
Console.WriteLine("External clock frequency." +
mo);
Console.WriteLine("Processor family." + GetFamily(mo));
Console.WriteLine("L2 cache size." + mo);
Console.WriteLine("L2 cache speed." + mo);
Console.WriteLine("Load percentage (average value for second)." + mo);
Console.WriteLine("Manufacturer." + mo);
Console.WriteLine("Maximum speed (in MHz)." +
mo);
Console.WriteLine("Name." + mo);
Console.WriteLine("Support for power management." +
mo);
Console.WriteLine("Unique identificator describing processor"+
mo);
Console.WriteLine("Processor type." + GetProcessorType(mo));
Console.WriteLine("Role (CPU/math)." + mo);
Console.WriteLine("Socket designation." +
mo);
Console.WriteLine("Status." + mo);
Console.WriteLine("Status information." + GetStatusInfo(mo));
Console.WriteLine("Processor version." + mo);
Console.WriteLine("Socket voltage." + mo);
i++;
}
}

private static string GetArchitecture(ManagementObject mo)
{
int i = Convert.ToInt32(mo);
switch (i)
{
case 0: return "x86";
case 1: return "MIPS";
case 2: return "Alpha";
case 3: return "PowerPC";
case 4: return "ia64";
}
return "Undefined";
}

private static string GetCpuStatus(ManagementObject mo)
{
int i = Convert.ToInt32(mo);
switch(i)
{
case 0: return "Unknown";
case 1: return "CPU Enabled";
case 2: return "CPU Disabled by User via BIOS Setup";
case 3: return "CPU Disabled By BIOS (POST Error)";
case 4: return "CPU is Idle";
case 5: return "This value is reserved.";
case 6: return "This value is reserved.";
case 7: return "Other";
}
return "Undefined";
}

private static string GetFamily(ManagementObject mo)
{
int i = Convert.ToInt32(mo);
switch (i)
{
case 1: return "Other";
case 2: return "Unknown";
case 3: return "8086";
case 4: return "80286";
case 5: return "80386";
case 6: return "80486";
case 7: return "8087";
case 8: return "80287";
case 9: return "80387";
case 10: return "80487";
case 11: return "PentiumR brand";
case 12: return "PentiumR Pro";
case 13: return "PentiumR II";
case 14: return "PentiumR processor with MMX technology";
case 15: return "CeleronT";
case 16: return "PentiumR II Xeon";
case 17: return "PentiumR III";
case 18: return "M1 Family";
case 19: return "M2 Family";
case 24: return "K5 Family";
case 25: return "K6 Family";
case 26: return "K6-2";
case 27: return "K6-3";
case 28: return "AMD AthlonT Processor Family";
case 29: return "AMDR DuronT Processor";
case 30: return "AMD2900 Family";
case 31: return "K6-2+";
case 32: return "Power PC Family";
case 33: return "Power PC 601";
case 34: return "Power PC 603";
case 35: return "Power PC 603+";
case 36: return "Power PC 604";
case 37: return "Power PC 620";
case 38: return "Power PC X704";
case 39: return "Power PC 750";
case 48: return "Alpha Family";
case 49: return "Alpha 21064";
case 50: return "Alpha 21066";
case 51: return "Alpha 21164";
case 52: return "Alpha 21164PC";
case 53: return "Alpha 21164a";
case 54: return "Alpha 21264";
case 55: return "Alpha 21364";
case 64: return "MIPS Family";
case 65: return "MIPS R4000";
case 66: return "MIPS R4200";
case 67: return "MIPS R4400";
case 68: return "MIPS R4600";
case 69: return "MIPS R10000";
case 80: return "SPARC Family";
case 81: return "SuperSPARC";
case 82: return "microSPARC II";
case 83: return "microSPARC IIep";
case 84: return "UltraSPARC";
case 85: return "UltraSPARC II";
case 86: return "UltraSPARC IIi";
case 87: return "UltraSPARC III";
case 88: return "UltraSPARC IIIi";
case 96: return "68040";
case 97: return "68xxx Family";
case 98: return "68000";
case 99: return "68010";
case 100: return "68020";
case 101: return "68030";
case 112: return "Hobbit Family";
case 120: return "CrusoeT TM5000 Family";
case 121: return "CrusoeT TM3000 Family";
case 128: return "Weitek";
case 130: return "ItaniumT Processor";
case 144: return "PA-RISC Family";
case 145: return "PA-RISC 8500";
case 146: return "PA-RISC 8000";
case 147: return "PA-RISC 7300LC";
case 148: return "PA-RISC 7200";
case 149: return "PA-RISC 7100LC";
case 150: return "PA-RISC 7100";
case 160: return "V30 Family";
case 176: return "PentiumR III XeonT";
case 177: return "PentiumR III Processor with IntelR SpeedStepT Technology";
case 178: return "PentiumR 4";
case 179: return "IntelR XeonT";
case 180: return "AS400 Family";
case 181: return "IntelR XeonT processor MP";
case 182: return "AMD AthlonXPT Family";
case 183: return "AMD AthlonMPT Family";
case 184: return "IntelR ItaniumR 2";
case 185: return "AMD OpteronT Family";
case 190: return "K7";
case 200: return "IBM390 Family";
case 201: return "G4";
case 202: return "G5";
case 250: return "i860";
case 251: return "i960";
case 260: return "SH-3";
case 261: return "SH-4";
case 280: return "ARM";
case 281: return "StrongARM";
case 300: return "6x86";
case 301: return "MediaGX";
case 302: return "MII";
case 320: return "WinChip";
case 350: return "DSP";
case 500: return "Video Processor";
}
return "Undefined processor family";
}

private static string GetProcessorType(ManagementObject mo)
{
int i = Convert.ToInt32(mo);
switch (i)
{
case 1: return "Other";
case 2: return "Unknown";
case 3: return "Central Processor";
case 4: return "Math Processor";
case 5: return "DSP Processor";
case 6: return "Video Processor";
}
return "Undefined type";
}

private static string GetStatusInfo(ManagementObject mo)
{
int i = Convert.ToInt32(mo);
switch (i)
{
case 1: return "Other";
case 2: return "Unknown";
case 3: return "Enabled";
case 4: return "Disabled";
case 5: return "Not applicable";
}
return "StatusInfo not defined.";
}
}
}

)

Но для Visual Studio не подходит, так как там не существует ManagementObject. Под чем этот скрипт можно запустить?

 

netsky2004, Это C# NET Framework 4.5

И ты мог узнать это сам, просто полистав MSDN или спросив Google.

 

Bato-San, я пробовал. В VS 2008 C# NET Framework 3.5 нельзя запустить. Чего тут листать? Это не поможет. Уже 2 года листаю, всю жизнь мне листать?

 

netsky2004, есть же какая то разница между 3.5 и 4.5 - тебе так не думается ? И, да ! Программист всю жизнь листает и учит.

 

Bato-San, почему using System.Management ничего не даёт? Писать using System.Management могу сколько хочешь, но это не даст распознание WqlObjectQuery

 

System.Management появился ещё в 3.5.

 

netsky2004, что то мне подсказывает, что тебе читать здесь.

Здесь.

Здесь.

А исходник ты надыбал, видимо, здесь ?

 

Если кому интересно, то до моих функций, как оказалось, доступится очень легко. Совершенно случайно нашел, что видеодрайвер грузится системой, как модуль DISPLAY. Берем хендл на этот модуль, а потом ищем в нем любые интересные нам функции. Только оправдались мои наихудшие опасения. При переключении режима, Винда сплошь и рядом использует данные от старого ражима, из-за чего изображение ломается. Нужно будет определять такие места и заставлять драйвер брать в этих местах собственные данные.

 

надо просто сообшить винде о смене видеорежима. А при переключении видеорежима преобразовать имеющееся изображение в требуемый формат. Собственно это не проблема винды. В любой доспроге при переключении видеорежима имеющееся в видеопамяти изображение превратится в чёрте что. Собственно так и появился DIB (DeviceIndependentBitmap) для виндовс.