Есть программа работающая с звуком и графикой, однако тупо не умеющая обрабатывать ошибки. Когда тот же DirectSoundCreate возвращает не 0 - всё тупо вылетает с ошибкой. Особенно не приятно то, что до этого переключается видеорежим. Возникла идея реализовать это в отдельном модуле который будет запускаться до переключения видеорежима и выдавать ошибку.
Тестовое delphi приложение работает чётко, однако засунув всё в dll с удивлением заметил, что происходит вход в DirectSoundCreate, а вот выход нет. Всё зависает...
Мне кажется я тупо что-то не учёл, подскажите пожалуйста.
Гуглил безрезультатно, проблема похоже только у меня.

| Сообщение посчитали полезным:

Ну раз нет ни кода, ничего, будем гадать.
Ткну пальцем в небо, что первое пришло в голову: вызов запихал в DllMain?

| Сообщение посчитали полезным:

Archer пишет:
Ну раз нет ни кода, ничего, будем гадать.
Ткну пальцем в небо, что первое пришло в голову: вызов запихал в DllMain?

Я код не выложил потому, что нормального кода не написал. Пробовал разные варианты:
1) Вызывал DirectSoundCreate(nil, DirectSound, nil) между begin/end. модуля без DllMain
2) Там же делал CreateThread и вызов DirectSoundCreate в потоке.
3) Тоже самое только с ожиданием завершения потока.
4) DirectSoundCreate из DllMain при Dll_Process_Attach
5) CreateThread и вызов DirectSoundCreate в потоке из DllMain при Dll_Process_Attach
6) Тоже самое с WaitForSingleObject(Result,INFINITE);

Пробовал отладчиком. Уходит глубоко в недра DirectSoundCreate, там и остаётся...
Уверен, что большинство из моих попыток, если не все, ошибочны по сути. Буду благодарен если подскажите правильный путь, я его изображу в коде и выложу для более детального разбора ошибки.
p.s. Ещё в расширенном варианте был вызов DirectDrawCreate(nil,DD,nil); так вот с ним проблем никаких не было...

| Сообщение посчитали полезным:

распихать всё в один или два модуля, т.е обойтись без DLL, инициализировать DS перед сменой режима, проверить типы данных/их выравнивание, откатится на старый вариант, перенести всё в тестовое приложение нормально отработавшему DS Create

| Сообщение посчитали полезным:

Проект не мой, для меня есть подгрузка мой длл в которой всё хотелось бы сделать.
По идее всё должно быть очень просто, не понятно почему один и тот же код работает в ЕХЕ, но не работает в DLL. Сделать какие то костыли типа из ресурсов длл вытаскивать ехе который проверит ответ от DirectSoundCreate и передаст через клиент\сервер назад в длл я бы мог, но не хочется. Тут теперь дело принципа понять в чём проблема. Я много вариантов directsound.pas скачивал, даже ZenGL прикручивал где тоже есть работа с DirectSoundCreate - результат один, виснет.
Вот простейший код который по идее должен был бы работать:


Ни один messagebox не появляется...
Вообще моя цель проверить минимальным кодом доступность DX и правильность установки аудио и видео драйвера. Как я писал ранее основное приложение которое работает с моей длл использует DirectSoundCreate + DirectDrawCreate и тупо не обрабатывает ошибок.

p.s. Сейчас проверил, если запихнуть DirectSoundCreate в экспортируемую функцию и вызвать её после загрузки библиотеки - работает. Но из мой длл никаких функций не вызывается, она просто прописана в импорте ЕХЕ. Как сделать что бы это сработало при загрузке DLL через LoadLibrary?

Добавлено спустя 3 часа 7 минут
Прочитал статью и понял, что вся проблема из за DllMain.
Можно ли это как то обойти без вызова экспортируемой функции? Какой нибудь таймер инициировать в DllMain что бы запускал функцию когда уже можно будет???

| Сообщение посчитали полезным:

Идиотизм конечно, всё равно обработка будет в DllMain,
но можно всякие телодвижения выполнять не в этой DLL по её LoadLibrary, а по FreeLibrary в другой, импортируемой этой первой.
То есть в DllMain той второй по получении DLL_PROCESS_DETACH.
Тогда Dll'ей две штуки, первая при загрузке делает free второй, которую она же и импортировала, ну и ...
Не знаю, что это даст. Врядли что-то путное.
Да и в статье предостерегают от этого.

Во второй DLL:


| Сообщение посчитали полезным:

ToBad пишет:
Прочитал статью и понял, что вся проблема из за DllMain
Ну вообще это я сразу и написал. Не стоит туда пихать, что не попадя. А надо взять и почитать официальную документацию. И таймеры тут не помогут. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).aspx и http://msdn.microsoft.com/en-us/library/windows/desktop/dn633971(v=vs.85).aspx

| Сообщение посчитали полезным:

Да оно ведь и не сильно усложится, если вствить в екзек дополнительно вызов экспортируемой функции..

| Сообщение посчитали полезным:

dosprog пишет:
То есть в DllMain той второй по получении DLL_PROCESS_DETACH.

Тоже самое получается, умирает на DirectSoundCreate. [img]https://exelab.ruimg/smilies/s9.gif[/img]

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

То есть без вызова экспортируемой функции вообще ничего не получится? Никакие костыли не сработают?

Добавлено спустя 1 час 42 минуты
Сработали вот какие костыли:
1) В DllMain моей библиотеки создаётся поток, который ожидает когда EXE подгружающий DLL будет распакован (проверяет наличие кода в определённом месте). Это работало и ранее, для небольшого патча ЕХЕ.
2) Когда можно патчить, делаю jmp на мою процедуру из DLL поблизости от EntryPoint EXE файла.
3) В этой функции делаю проверку на DirectSoundCreate и DirectDrawCreate, выдаю месседж и на выход если не ОК либо выполняю код который был под JMP и возвращаюсь на следующие инструкции в EXE.

Добавлено спустя 1 час 47 минут
То есть как и должно было бы быть в нормальном варианте если бы EXE вызывал функцию из моей DLL, а не просто её подгружал. Так как он этого не делал - пришлось из DllMain это добавить.

| Сообщение посчитали полезным: