Подумалось про кеш процессора. Чем кеша больше, тем, (условно)предположим, лучше. Тем больше попадёт софта в проц и, если повзёт, то весь текущий софт будет крутиться в ядре. Чем большее число тактов так будет продолжаться, тем лучше. Что, если сравнить быстродействие операционок с (условно)разным размером ядра на проце с маленьким кешем? Например, протестировать на одной машине(если получиться, то 80486) на winnt3.51/nt4 и win2000/winxp или что там пойдёт. Запустить, например, winrar или ещё что-нибудь с бенчмарком. Только чтобы памяти было достаточно и свап при тестировании не вмешивался. Будет ли система с меньшим размером ядра давать лучшие результаты за счёт меньшего вытеснения ядра приложения из кеша. В качестве тестирующего софта лучше найти что-то такое, что использовало бы побольше функций ядра, а не просто чистую математику или пересылку в памяти.

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

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

Подумалось про кеш процессора. Чем кеша больше, тем, (условно)предположим, лучше. Тем больше попадёт софта в проц и, если повзёт, то весь текущий софт будет крутиться в ядре. Чем большее число тактов так будет продолжаться, тем лучше. Что, если сравнить быстродействие операционок с (условно)разным размером ядра на проце с маленьким кешем? Например, протестировать на одной машине(если получиться, то 80486) на winnt3.51/nt4 и win2000/winxp или что там пойдёт. Запустить, например, winrar или ещё что-нибудь с бенчмарком. Только чтобы памяти было достаточно и свап при тестировании не вмешивался. Будет ли система с меньшим размером ядра давать лучшие результаты за счёт меньшего вытеснения ядра приложения из кеша. В качестве тестирующего софта лучше найти что-то такое, что использовало бы побольше функций ядра, а не просто чистую математику или пересылку в памяти.

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

Ну кроме размера кэша следует учесть и его скорость, посмотрите на Мендочины и Кламаты хотябы, мендочина может переплюнуть кламат, не смотря на то, что кеша на ней вчетверо меньше(зато fullspeed). В общем тут мороки много получается, да и результаты интересны разьве, что для себя или музея...
Если смотреть на 80486 то тут возникает пара приколов:
1) Зачем медленному процессору такой кеш (для 486 достаточно 256кб вроде ктото их старожилов проверял, 512 ник селу ни к городу для 286)
2) Банально опять упираемся в скорость, кеш по скорости медленен. Его увеличеные размеры не очень то и помогут (хотя довольно интересно увидеть тесты амдшки на 150мгц с 1мб кешем, если это реально вообще)
3) Ну и субъективизм: ну зачем 2к3 на486? (хотя и "Сэр Гетинакс знает толк в редкостных извращениях" (С) blood )

почитал про шаманство с setupldr - имхо проще 1й этап (копирование файлов) сделать на нормальной тачке, а 2й (собссно бут ядра и поиск/установка устройств/настройка винды) делать на целевом железе. setupldr грузится только при установке с сд... кстати - как вариант запуск установки из-под дос (с копированием файлов на винт): для 2к/хр - просто запуск winnt, для nt4 - winnt /b (вроде при этом копируется минимум файлов установки на винт и пользуется стандартный ntldr), но я особо с таким извращением дел не имел...

по поводу установки осей на старое железо - из своего опыта могу сказать, что для 386sx-20 с 4 метрами рамы все же предпочтительнее вин 95 чем вин 3.11 - сравнивал скорость работы как ворда 6 (16-бит), так и для сравнения на 95й ставил офис 97. на 386 в свое время с 3.11 в ворде жал "вставить картинку" и шел минут на 5 пить чай (пока свопило). с 95-й же все довольно резво бегает... 2-3 странички документы без проблем править... версию о "быстром винте" откидываю - это было 120мбайт какое-то чудо :)

Забыл самое главное!!!

Ведь, при отключенных проверках на нее, инструкция CMPXCHG8B (0F C7 xx) ВСЕ РАВНО встречается и ИСПОЛЬЗУЕТСЯ (~8 раз) в ntoskrnl.exe/ntkrnlmp.exe и прочих вариантах ядра (а может и еще где-то?). Значиться так... Эти точки нужно находить и ПАТЧИТЬ!!! Только после этого система XP/2003 может завестись на 80486 CPU.

Сам попробую это сделать на неделе. Если получиться - обязательно отпишусь.

sarinn

Эти точки нужно находить и ПАТЧИТЬ!!!

наивно - ядро проверяет свою CRC и если она неправильная, то вываливается в BSOD. Появилась такая защита, ИМХО, еще в 2000.

Root

наивно - ядро проверяет свою CRC и если она неправильная, то вываливается в BSOD. Появилась такая защита, ИМХО, еще в 2000.

А контрольную сумму (и/или ее проверку) тоже можно подправить. Было бы желание и время ковыряться с ядром.

sarinn

А контрольную сумму (и/или ее проверку) тоже можно подправить.

ее сначала найти надо ;) А копаться в 2МБ исполняемом файле охоты никакой, честно, нету...

2 Root

Хорошо. Предположу, что можно сделать драйвер ядра (заглушку), обрабатывающую CMPXCHG8B и всякие вызовы инструкции процессора на invalid opcode... Не буду утверждать что это 100% возможно. Но вдруг?

2 all
Опытным путем определил минимальное количество оперативки, необходимое для запуска:
1) Windows NT SP6a (ENG) - 6!!! Mb.
2) Windows 2000 SP4 (ENG) - 16!!! Mb.

Ковыряние в кернеле XPSP2 продолжается.
Выяснил что CMPXCHG8B импользуется в ntoskrnl.exe (и его вариантах) 8 раз и в NTDLL.DLL.

Также установил что ядро WinXP при отключенной проверке на CMPXCHG8B/CPUID ошибочно воспринимает *любой* 486-й камень как 386-й и "вылетает" в недрах ntoskrnl.exe с отключенным ACPI (F7/F5):
[code:1]
Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\com1
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: .\SYMBOLS
Executable search path is:

Loading symbols for 80400000 ntoskrnl.exe -> ntoskrnl.exe
ModLoad: 80400000 80614780 ntoskrnl.exe
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x80400000 PsLoadedModuleList = 0x80483b20
System Uptime: not available
Loaded dbghelp extension DLL
Loaded ext extension DLL
Loaded exts extension DLL
Loaded kext extension DLL
Loaded kdexts extension DLL
Force unload of ntoskrnl.exe
ModLoad: 80400000 80614780 ntoskrnl.exe
ModLoad: 80615000 8062ec00 hal.dll
*** Fatal System Error: 0x0000005d
(0x01040305,0x756E6547,0x49656E69,0x6C65746E)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
...

...
********************************************
Use !analyze -v to get detailed debugging information.
BugCheck 5D, {1040305, 756e6547, 49656e69, 6c65746e}
Probably caused by : ntoskrnl.exe ( nt!KiInitializeKernel+444 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
8040cb25 cc int 3
kd> !analyze -v
********************************************
UNSUPPORTED_PROCESSOR (5d)
386 - System failed because the processor is only a 386 or
compatible. The system requires a Pentium (or higher) compatible processor.
Arguments:
Arg1: 01040305
Arg2: 756e6547
Arg3: 49656e69
Arg4: 6c65746e

Debugging Details:
------------------

DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x5D
LAST_CONTROL_TRANSFER: from 8045b8e7 to 8040cb25

STACK_TEXT:
80479410 8045b8e7 00000003 8047976c 00000000 nt!RtlpBreakWithStatusInstruction
8047945c 8045c3be 00000003 80479890 ffdffa2c nt!KiBugCheckDebugBreak+0x19
8047983c 8045c9ae 0000005d 01040305 756e6547 nt!KeBugCheck2+0x574
8047985c 805e3f39 0000005d 01040305 756e6547 nt!KeBugCheckEx+0x1b
804798bc 805d2d2c 80482580 80482320 80479b80 nt!KiInitializeKernel+0x444
00000000 00000000 00000000 00000000 00000000 nt!KiSystemStartup+0x2bf

STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiInitializeKernel+444
805e3f39 cc int 3
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 41108004
SYMBOL_NAME: nt!KiInitializeKernel+444
FAILURE_BUCKET_ID: 0x5D_nt!KiInitializeKernel+444
BUCKET_ID: 0x5D_nt!KiInitializeKernel+444
Followup: MachineOwner
---------
[/code:1]