Внутренности Установщика WinXP

[vserd]

Mr dUSHA,
Может встречал, как называется функция которая определяет путь к файлам установки?

в установленной системе он записан в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SourcePath
на T40 его еще нет.

[Mr dUSHA]

vserd,
В библиотеке Syssetup.dll есть внутреняя вункция SpSetupProcessSourcePath.
Она какраз и занимается поиском дистрибутива. Вызывается она в момент разбора параметров из $winnt$.inf на Т-39.
Из $winnt$.inf она берет значение параметра "sourcepath", и преобразовывает его в букву диска и записывает в параметр "dospath".
(Конечно буква диска будет, если установка идет с CD-ROM-а или винчестера, а если сетьевая установка, то будет видимо ссылка на RIS-овую шару с дистрибутивом).

А сам параметр "sourcepath", насколько я понимаю, еще на текстовом этапе в $winnt$.inf вписывает SETUPDD.SYS

Сейчас смотрю функцию более детально, как ее можно использовать, либо переписать заново на С++.

А если буква диска с дистрибутивом нужна не на Т-40 (до вызова этого парсера), а на Т-12 например, то без зазрения совести ее можно прочитать напрямую с $winnt$.inf с параметра "dospath". :)

[vserd]

Mr dUSHA,
SpSetupProcessSourcePath или pSetupSetSystemSourcePath???
SpSetupProcessSourcePath не экспортируется...

Sourcepath из $winnt$.inf в нормальный вид я преобразовываю нормально.
Но если установка идет через winnt/winnt32 или с hdd тогда часть файлов копируется в $win_nt$.~ls и $win_nt$.~bt на системный раздел (С:), в $winnt$.inf записывается OriSrc = "A:\_WINDOWS\PROF\I386"
который собственно и показывает где находится дистрибутив.
Но в процессе установки, он правильно преобразуется в букву CDROM и пишется в реестр.

sourcepath имеет вид:
sourcepath = "\device\harddisk0\partition1\$win_nt$.~ls"
и показывает что установка идет с HDD, но нужные мне файлы на CD, вот и хочу использовать стандартные средства винды, а не городить свой эмулятор.
Тем более что описания этого хозяйства нет...
И там хитрый такой вариант есть. Установка по сети OriTyp = "4" (RIS ???), в котором можно использовать переменные. Вот его пока не могу проверить..
А инфы по OriTyp и OriSrc я не нашел.


А если буква диска с дистрибутивом нужна не на Т-40 (до вызова этого парсера), а на Т-12 например, то без зазрения совести ее можно прочитать напрямую с $winnt$.inf с параметра "dospath". »
Это слишком поздно. :)) Интересует все что на T40 можно использовать.

За одно, если встретится API которое объединяет $UNIQUE$.UDB c $winnt$.inf маякни?

[Mr dUSHA]

SpSetupProcessSourcePath не экспортируется... »
Совершенно верно. Но ничто не мешает ее вызвать напрямую по адресу.
Для конкретного билда библиотеки зарание узнаем VirtualOffset этой функции, далее после загрузки библиотеки с помощью LoadLibrary складываем VirtualOffset с дескриптором (который по сути является базовым адресом загруженой библиотеки) и вызываем функцию как обычно.

Функция имеет формат:

BOOL __stdcall SpSetupProcessSourcePath(LPCWSTR lpString1, LPCWSTR lpString2)

IN lpString1 - указатель на строку "sourcepath".
OUT lpString2 - указатель на строку-приемник, куда будет помещена строка "dospath".

возвращаемое функцией значение:
TRUE - преобразование завершено успешно.
FALSE - ошибка.


За одно, если встретится API которое объединяет $UNIQUE$.UDB c $winnt$.inf маякни? »
Это делает внутреняя функция InitializeUniqueness

Обе эти функции отрабатывают на Т-39 и вызываются тоже внутреней функцией SpSetupProcessParameters.

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

[Vizit0r]

раз тут за такие умные вещи разговор идет, тогда и я примажусь :)
подскажите, из-за чего в setuplog.txt где-то на T40 идет фраза
08/07/2008 15:36:44.437,d:\xpsp\base\ntsetup\syssetup\syssetup.c,6683,,Setup: Could not open the cdrom for hack, ec=0xc0000034
? Установка идет с флешки.

Полный лог до этого момента

Time,File,Line,Tag,Message
08/07/2008 15:36:42.437,d:\xpsp\base\ntsetup\syssetup\syssetup.c,6539,BEGIN_SECTION,Installing Windows NT
08/07/2008 15:36:44.437,d:\xpsp\base\ntsetup\syssetup\wizard.c,1568,,SETUP: Calculating registery size
08/07/2008 15:36:44.437,d:\xpsp\base\ntsetup\syssetup\wizard.c,1599,,SETUP: Calculated time for Win9x migration = 120 seconds
08/07/2008 15:36:44.437,d:\xpsp\base\ntsetup\syssetup\syssetup.c,6570,BEGIN_SECTION,Initialization
08/07/2008 15:36:44.437,d:\xpsp\base\ntsetup\syssetup\syssetup.c,6683,,Setup: Could not open the cdrom for hack, ec=0xc0000034

[vserd]

Mr dUSHA, Совершенно верно. Но ничто не мешает ее вызвать напрямую по адресу.
Для конкретного билда библиотеки зарание узнаем VirtualOffset этой функции, далее после загрузки библиотеки с помощью LoadLibrary складываем VirtualOffset с дескриптором (который по сути является базовым адресом загруженой библиотеки) и вызываем функцию как обычно. »
Для своей программы да или для внутреннего самостоятельного использования. А для аддона увы, не приемлимо :(((

Это делает внутреняя функция InitializeUniqueness »
гады :))) нет чтобы в экспорт выкинуть, так бы жизнь облегчили :))))

[Mr dUSHA]

гады :))) нет чтобы в экспорт выкинуть, так бы жизнь облегчили :)))) »
Как вариант, можно по добавлять в таблицу экспорта нужные функции, и вложить такую подправленную syssetup.dll в аддон.

syssetup ведь скорей всего обновляться через Windows Update, а новая версия ИМХО появится только в SP4, если конечно сам SP4 вообще выпустят... Я конечно вполне могу ошибаться, но что-то не помню, чтоб syssetup.dll обновлялась когда либо, кроме как через сервиспаки.

Так что можно реализовать простенькую функцийку контроля версий (могу даже выкинуть в шапку исходник) и составить таблицу VirtualOffset-ов нужных нам функций, скажем, для версий 2180 и 5512 библиотеки, и далее вызывать их напрямую даже в хитром аддоне.

А способ получения адреса функции путем складывания дескриптора библиотеки с VirtualOffset-ом технически ничем не отличается от функции GetProcAddress. Отличие только в том, что GetProcAddress берет VirtualOffset-ы из таблицы экспорта библиотеки, а мы - из своей базы для конкретной версии библиотеки.

[Mr dUSHA]

Для интеграции $UNIQUE$.UDB в $winnt$.inf есть такая функция:

int __stdcall IntegrateUniquenessInfo(PCWSTR FileName, PCWSTR Index)

PCWSTR FileName - полное имя с путем файла $UNIQUE$.UDB

PCWSTR Index - индекс (код), который указывается в стандартной реализации
в параметре /udf:код [,файл_UDB] для winnt32.exe

Возвращаемое значение - не ноль, если интеграция без ошибок,
либо ноль, если произошла ошибка при интеграции.



Но одна тонкость:
Сначала нужно вызвать функцию void __stdcall UnattendInitialize(void)
для того, чтоб она инициализировала внутренюю строковую переменную _AnswerFile, в которую заносится полный путь к $winnt$.inf.

[Mr dUSHA]

подскажите, из-за чего в setuplog.txt где-то на T40 идет фраза
Could not open the cdrom for hack, ec=0xc0000034»

Просто проверяет на наличие CD-ROM-а. Если CD-ROM не найден, то записывает вот такое сообщение в журнал.
Более никаких других действий связаных с этим сообщением я не наблюдаю.

[Vizit0r]

ясно, спасибо

[Dilinjer]

Цитата Dilinjer:Знает ли ктонить как пропатчить SFC_OS.DLL 5.1.2600.2180 чтоб было отключение инициализации SFC и проверки всех файлов на этапе Т-8 »
0000E8AB: 74 EB
0000ECE7: 75 EB
Это оба патча для 2180, которые описаны в SFC_OC_5512.txt.
Но не забывайте, что гдето в твиках на Т13-Т12 руками вам нужно внести в реестр SFCDisable = 0xFFFFFF9D, иначе не сработает. »
Патч работает :applause: (с Т9 установщик сразу переходит на Т2 ) но появляется другая проблемма:
В %SystemDrive%\$WIN_NT$.~LS остаются(неудаляются) временные файлы.... Причем количество неудаленных файлов при каждой установке ХРюши разное :idontnow:

Mr dUSHA, может подскажете в чем проблемма?

ЗЫ: Установку форточек произвожу из-под WinPE загруженной с USB-HDD такой строчкой bat'ника:
winnt32.exe /unattend:%AnswerFile% /s:%SetupFiles%\I386 /syspart:!DestDisk! /tempdrive:!TempDisk! /noreboot

[Mr dUSHA]

Патч работает (с Т9 установщик сразу переходит на Т2 ) но появляется другая проблемма: »
Гм... но ошибка ИМХО на прямую не связана с патчем.
Исходя из вашего лога setuperr.log, где по нескольким файлам выводится предупреждение

Программе установки не удалось удалить временный файл или каталог C:\$WIN_NT$.~LS\I386\msdtcprx.dl_ с жесткого диска из-за следующей ошибки:
DeleteFile(C:\$WIN_NT$.~LS\I386\msdtcprx.dl_): возвращена ошибка 32 (20).

можно сделать вывод, что файлы просто заняты в этот момент каким-либо другим процессом, поскольку "ошибка 32 (20)" - это ни что иное, как описаное в Error.h
#define ERROR_SHARING_VIOLATION 32

Можно сделать вывод, что без патча за те несколько минут, за которые SFC проверяет файлы на Т-8, другой процес успевает освободить эти файлы, после чего на Т-0 происходит зачистка всего мусора, и эти файлы удаляются тоже.

[Dilinjer]

Mr dUSHA, а можно както на T9 узнать какие процессы болтаются в памяти ? Может в winnt.sif в секции [SetupParams]
прописать какуюнить тулзу создающю лог выполняемых процессов ? Посоветуйте плиззз ченить !!!!

[Mr dUSHA]

Посоветуйте плиззз ченить !!!! »
А на Т-13, Т-12 не устанавливается ли какой-либо софт, копающийся в файлах на винчестере, например антивирусы?

[Dilinjer]

Mr dUSHA, разобрался в чем проблемма... В CMDLINES.TXT было:
"HIDEC.EXE RUNONCEEX.CMD"
В RUNONCEEX.CMD происходило копирование из sourcepath дистрибутива в %SystemRoot%\I386 .
CMDLINES.TXT не дожидался завершения выполнения RUNONCEEX.CMD вследсвие чего имел вышеописываемую проблему....
Чтоб решить проблему пришлось в CMDLINES.TXT прописать так: "HIDEC.EXE /W RUNONCEEX.CMD" , хотя во всех доках указано что команды вызываемые из CMDLINES.TXT выполняются последовательно т.е. ждут своего завершения :confused:
Задача была скопировать дистрибутив в локальную папку и при первом логоне заменить падченную sfc_os.dll на оригинальную а также в реестре прописать локльную папку с дистрибутивом чтоб в случае подмены оригинальных файлов ХРюши SFC не требовал установочного CD'диска а воостанавливал файлы из локальной папки с дистрибутивом... Но как окозалось(сейчас только обнаружил) уже на T40 в sourcepath имеем неполный дистрибутив (на текстовом этапе часть системных файлов распакована с перемещением в %SystemRoot%)
Как вариант, вижу только из-под WinPE c USB-HDD скопировать дистрибутив на системный раздел и оттуда запускать winnt32.exe и при первом логоне указывать в реестре местоположение скопированного дистрибутива.....

[Manuka1973]

я не уверин в ту ли тему я задаю этот вопрос ....!? Помогите кто знает..... я хочу собрать себе сборку Windoes XP какой программой можно собрать , кроме нлайта!!!!?????

[Shanser]

я не уверин в ту ли тему я задаю этот вопрос ....!? Помогите кто знает..... я хочу собрать себе сборку Windoes XP какой программой можно собрать , кроме нлайта!!!!????? »

Ну например для СП3 можно использовать UpdatePack-XPSP3-Rus версия 8.8.19 (http://forum.oszone.ru/thread-114740.html) + Gui-интегратор пакета обновлений и адонов (http://forum.oszone.ru/thread-100898.html) + смотрите раздел Наборы обновлений для Windows XP/2003/Vista (http://forum.oszone.ru/forum-62.html)

[Mr dUSHA]

"HIDEC.EXE RUNONCEEX.CMD" »
Это я видел в вашем логе. Просто в логе отсутствуют временные метки, поэтому тяжело понять, когда оно запускалось.

пришлось в CMDLINES.TXT прописать так: "HIDEC.EXE /W RUNONCEEX.CMD" , хотя во всех доках указано что команды вызываемые из CMDLINES.TXT выполняются последовательно т.е. ждут своего завершения »
Вы не правильно понимаете логику.
HIDEC.EXE сама по себе тупая, и команд из CMD-файла не выполняет. Она только запускает интерпретатор CMD.EXE в скрытом окне, и передает ему на выполнение ваш CMD-файл. Когда интерпретатор только запустился и начал работать (а работы у него много в данном случае), сама HIDEC.EXE завершается, и соответственно идет выполнение следующей комманды из CMDLINES.TXT.
С параметром /W вы заставляете HIDEC ждать завершения работы интерпретатора CMD.EXE, а SYSSETUP ожидает завершения HIDEC, так что при таком раскладе все у вас работает корректно.

[Dilinjer]

Mr dUSHA, а можно както извлечь из sfcfiles.dll в текстовый файл список файлов(папок) для которых работает WFP ? Проста для моей задачи хочеца не тупо копировать весь дистрибутив на системный раздел а только те файлы для которых сработает WFP......

ЗЫ: Эх... Былобы супер еслиб в список защищаемых файлов возможно былобы добавить и свои.....

[Mr dUSHA]

ЗЫ: Эх... Былобы супер еслиб в список защищаемых файлов возможно былобы добавить и свои..... »
Для этого вам нужны будут цифровые подписи для ваших файлов, поскольку защита работает в два уровня:
Первая часть защиты проводит мониторинг изменения файлов из списка sfcfiles.dll;
Вторая часть защиты отловленый измененный защищаемый файл проверяет на наличие цифровой подписи (в каталогах безопастности, установленых в системе), и если подпись отсутствует, то файл восстанавливается из дистрибутива. Но файл, лежащий в дистрибутиве, проверяется также. И если дистрибутивный файл также изменен, то вы видите сообщение, что "восстановить измененный файл до начальной версии не удалось...".

Во вложении список файлов для ХР SP3
(но он сформирован уже с привязкой к моей SystemRoot=c:\winnt\)