Господа, разбирая программку, которая входит в дистрибутив
MASM 6.13 (WinClock называется) я встретил такую команду

...
mov ah,2Ah
invoke DOS3Call
...

но не в одной библиотеке(dll) я не нашел эту функцию.
(Эта функция встречается в Паскале под Вынь.)
я попробывал выполнить такой код

...
mov ah,04h ; получить дату RTC
int 1Ah
...

все прекрасно отработало...
Вопрос: Есть ли разница между спользованием API функций и прерываний BIOS для решения одинаковых задач?

Да, конечно. В первую очередь потому, что под NT+ никто не позволит тебе напрямую обращаться к биос.

volodya
А подробней можешь?
как обратиться к биос через API? и вообще это возможно?

Могу.
Итак, я буду немного упрощать, возможно, где-то даже это будет профанацией, однако следует помнить, что я - прикладной программист и биохимик, а не системщик. Так что то, что я тут напишу, я узнавал чисто из познавательских целей, не более. Заставил ты меня жирком тряхнуть, однако!

MS-DOS.
Цепочка выглядит так:
int 21 (например) -> int 10 (например) -> соответствующий порт ввода-вывода (не помню).
Т.е. DOS -> BIOS -> I/O
Или вообще App -> I/O.

Win95
Такая операционная система мне неизвестна :)

Win2k+

Сначала рассмотрим путь стандартного Win API.

WriteFile (kernel32.dll) -> NTWriteFile (ntdll.dll) -> int 2E -> |диспетчер системных сервисов| -> KiSystemService -> NtWriteFile из ntoskrnl.exe -> I/O Manager -> драйвер №1 -> HAL -> драйвер №2 -> порты ввода-вывода

Итак, чуть подробнее. Имеем стандартный Win API. Очень важно понимать, что kernel32/user32 и иже с ним - это НЕ сама операционная система. Все это - не более, чем ПОДСИСТЕМА Windows. ОДНА ИЗ МНОГИХ. Т.е. Windows "эмулирует" (не могу подобрать лучшего слова) работу подсистем. А их может быть немало - OS/2, POSIX, Win32. Так вот, kernel32 и т.п. входят в подсистему Win32. Настоящая ось начинается за барьером диспетчеров. Т.е. здесь применяется т.н. клиент-серверная концепция (у Юникс есть подобные игрушки с X-Window). БОЛЬШИНСТВО запросов к ядру проходят через шлюз int 2Eh (внутри ntdll.dll). Далее int2eh получает собственное место в IDT. Далее запрос обрабатывается согласно IRQL уже со стороны сервера - ядра Windows - файл ntoskrnl.exe функция KiSystemService. Далее запрос уходит по цепочке вглубь, преобразуясь в IRP и обрабатываясь следующим диспетчером. И так - до портов ввода-вывода.
Едем дальше.
Подсистемы DOS в Win2k НЕТ! Вместо этого существует запрос к подсистеме Win32. Т.е. мы имеем ЕЩЕ один уровень абстракции, которого не было в 9x и благодаря которому многие DOS приложения вылетают в NT+.
Т.е., нечто вроде такого:

DOS App -> NTVDM -> ntdll.dll -> || -> ntoskrnl -> ...

Не обязательно это будет ntdll.dll, хотя, действительно, NTVDM непосредственно МОЖЕТ работать с ntdll.dll. Но, разумеется, путь int может пролегать и через kernel32.dll и т.п. Эмуляция DOS - неполная. Т.е. некоторые int (например, 2F) просто напросто вызовут останов приложения. Также MS заявлено, что "16-bit virtual device drivers that require direct access to a hardware component" не поддерживаются. Явная напряженка и TSR.

Я не готов сказать тебе, каким будет путь твоего 1A. Вероятно, оно будет проэмулировано ntvdm и спущено через Win32 подсистему к ядру. Может быть нет, не знаю. Есть знания бессмысленные, а есть устаревшие. Так вот, никому более не интересно знать, как же, собственно, умерший DOS ухитряется полувыюивать под 2k. В интернете я статей на эту тему не знаю и мне это глубоко неинтересно. Это уже мертво. DOS приложения дико тормозят под NT+ и теперь ты понимаешь почему (хотя, вероятно, и раньше знал). Это знание является устаревшим. Никому более не нужен DPMI/VCPI/Unreal Mode - все это интересно, но за это не платят деньги. Я ответил на твой вопрос? Или все это было бесмыссленной тратой времени?

volodya
Cпосибо.
Прочитал(два раза).
Про ДОС и INT`ы все понятно.
а вот только, что есть такое DOS3Call?(вернее я знаю что это такое, и даже представляю примерный ее код, но где она есть, и есть ли вообще?)

Interrupts for Virtual DOS machines (VDM), which include the WOW
(16-bit Windows on Window) subsystem, do not vector directly through
the IDT. For a VDM, interrupts are emulated by triggering a general
protection fault that special VDM code within NTOSKRNL handles. In
most cases, the interrupt is eventually reflected back to the VDM for
servicing. MS-DOS Interrupt 21 is handled as a special case (since an
actual IDT entry exists). This could be for performance reasons, compatibility
issues, or both.

Кроме того, для кажой NTVDM создается LDT.

volodya
ясьнонько, огромадное спасибо.

По поводу DOS3Call - это эквивалент int21.
ЧИТАЙ MSDN!!!

The DOS3Call API function in Windows 3.x must be called from assembly language. It is typically used to perform file I/O. In Win32, you should replace assembly language code that calls DOS3Call with the appropriate Win32 file I/O calls. Other (non-file) INT 21H functions should be replaced with the portable Windows API call as shown in the following table.

INT 21H subfunction MS-DOS operation Win32 API equivalent
0EH Select Disk SetCurrentDirectory
19H Get Current Disk GetCurrentDirectory
2AH Get Date GetDateAndTime
2BH Set Date SetDateAndTime
2CH Get Time GetDateAndTime
2DH Set Time SetDateAndTime
36H Get Disk Free Space GetDiskFreeSpace
39H Create Directory CreateDirectory
3AH Remove Directory RemoveDirectory
3BH Set Current Directory SetCurrentDirectory
3CH Create Handle CreateFile
3DH Open Handle CreateFile
3EH Close Handle CloseHandle
3FH Read Handle ReadFile
40H Write Handle WriteFile
41H Delete File DeleteFile
42H Move File Pointer SetFilePointer
43H Get File Attributes GetAttributesFile
43H Set File Attributes SetAttributesFile
47H Get Current Directory GetCurrentDirectory
4EH Find First File FindFirstFile
4FH Find Next File FindNextFile
56H Change Directory Entry MoveFile
57H Get Date/Time of File GetDateAndTimeFile
57H Set Date/Time of File SetDataAndTimeFile
59H Get Extended Error GetLastError
5AH Create Unique File GetTempFileName
5BH Create New File CreateFile
5CH Lock LockFile
5CH Unlock UnlockFile
67H Set Handle Count SetHandleCount


Линк - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccor e/html/_core_porting_ms.2d.dos_system_calls.asp

Если слышал о проекте эмулятора Windows под Linux - подними его архивы. Там просто бесценная инфа лежит. Скоро уже выходит моя с NEOx статья, я там тоже пару идей оттуда спер :)

я с ее резолюцией знаком, в паскале кодил когда-то.

volodya
ладно щас посмотрю

The following table provides a list of functions and messages that were in the 16-bit Windows API but were not implemented in 32-bit Windows.

DOS3Call Replaced by named, portable functions.

Линк - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winpr og/winprog/deleted_windows_programming_elements.asp

Ну, вроде все. Бай-бай.