Мониторинг обменных курсов валют
18c0693f

Статический VxD:


VMM загружает статический VxD когда:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\key\StaticVx

  • VxD указан в system.in в секции [386enh]:

    • device=pathname

    Во время периода разработки, я предполагаю, что вы загружаете VxD из system.ini, потому что если в вашем VxD будет ошибка, из-за которой Windows не сможет загрузиться, вы сможете отредактировать system.ini из DOS'а. Вы не сможете ничего сделать, если VxD прописываться в регистре. (Можно отредактировать регистр с помощью regedit.exe, но под ДОСом это будет сложнее, чем под виндами - прим. Aquila).

    Когда VMM загружает ваш статический VxD, ваш VxD получить три системных контрольных сообщения в следующем порядке:

  • Если вы обрабатываете это сообщение, вам следует проводить инициализацию так быстро, как это возможно, чтобы предотвратить потерю вызовов хардварных прерываний (которые, как вы помните, запрещены).
  • Device_Init - VMM посылает контрольное сообщение после того, как прерывания были разрешены. Большинство VxD проводят инициализацию в качестве ответа на это сообщение. Так как прерывания разрешены, можно проводить объемные по времени операции без опасения того, что хардварные прерывания будут потеряны. Вам следует проводить инициализацию здесь (если потребуется).
  • Init_Comрlete - после того, как все VxD обработают сообщение Device_Init, но прежде чем VMM освободит все инициализационные сегменты (классы ICODE и RCODE), VMM посылает это контрольное сообщение. Требуется мало VxD , чтобы обработать это сообщение.


    • Ваше VxD должно очищать флаг переноса, если инициализация прошла успешно, в противном случае вы должны установить флаг переноса. Вам не нужно обрабатывать ни одно из этих сообщений, если ваш VxD не требует инициализации.

    Когда наступает время прервать выполнение статического VxD, VMM посылает следующие контрольные сообщения:

    Большинство VxD не нуждается в обработке этих двух сообщений, кроме тех случаев, когда вы хотите подготовить систему к переводу в реальный режим. Вы должны знать, что когда Windows 95 завершает работу, она входит в pеальный pежим. Поэтому если ваш VxD сделал что-то, что может сделать систему нестабильной в этом pежиме, ему следует восстановить изменения.

    Вы можете задать вопрос, почему эти два сообщения имеют на конце "2"? Помните, что когда VMM загружает статические VxD, она загружает VxD с наименьшим значением загрузочного порядка, чтобы VxD могли полагаться на сервисы VxD, загружаемых раньше них. Hапример, если VxD2 полагается на сервисы VxD1, она должна указать ее инициализационный порядок большим, чем порядок VxD1. Загрузочный порядок должен быть:

    ..... VxD1 ===> VxD2 ===> VxD3 .....

    Теперь, во время выгрузки, становится понятным, почему VxD, инициализированные раньше, должны и выгружаться раньше, чтобы они могли все еще могли вызывать сервисы VxD, которые загружались до них. В вышеприведенном примере, порядок должен быть следующим:

    .... VxD3 ===> VxD2 ===> VxD1.....

    В вышеприведенном примере, если VxD2 вызывал какие-то сервисы VxD1 во время инициализации, он все еще может нуждаться в них во время выгрузки. System_Exit2 и Sys_Critical_Exit2 шлются в порядке, обратном порядку инициализации. Это означает, что когда VxD2 получает эти сообщения, VxD1 еще не провел деинициализацию и он все еще может нуждаться в сервисах VxD1. Сообщения System_Exit и Sys_Critical_Exit не посылаются в обратном порядке. Это означает, что когда вы получаете эти два сообщения, вы не можете быть уверенным, что вы все еще можете вызывать сервисы VxD, который загружался до вас. Эти сообщения не следует использовать для новых VxD. Есть еще два сообщения выхода:

    Теперь вы можете предположить, что существуют сообщения Device_Reboot_Notify и Crit_Reboot_Notify, но они посылаются не в порядке, обратном порядку инициализации.




    Самый выгодный курс обмена валюты