[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]

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