Привет всем.
Скажите, как можно сделать указатель на начало видеобуфера, чтобы самому писать на экран в текстовом режиме в консольном приложении на C#?

пишу следующее:

unsafe ...
{
...
char *p;
p = (char*)0xB8000000;
*p='a'; // Допустим в левый верхний угол запишем символ 'a'.
...
}

Так вот — в последней строке возникает исключение "В экземпляре объекта не задана ссылка на объект" и программа останавливается.

ZAV>Скажите, как можно сделать указатель на начало видеобуфера, чтобы самому писать на экран в текстовом режиме в консольном приложении на C#?

Ладно вам над человеком издеваться-то! Хотя такие вещи лучше все-таки под анонимом писать.

Дорогой ZaharowAV, виндовс не позволит Вам вот так просто писать напрямую в видеопамять, на каком бы языке программирования Вы не писали. Если только вы не пишете видеодрайвер, конечно. Но это уже совсем другая история...

Belegel.

Здравствуйте, Belegel, Вы писали:

B>Ладно вам над человеком издеваться-то! Хотя такие вещи лучше все-таки под анонимом писать.
B>Дорогой ZaharowAV, виндовс не позволит Вам вот так просто писать напрямую в видеопамять, на каком бы языке программирования Вы не писали. Если только вы не пишете видеодрайвер, конечно. Но это уже совсем другая история...
B>Belegel.

Ладно вам над человеком издеваться-то! Хотя такие ответы тоже лучше всё-таки под анонимом писать.

P.S.
"реклама по радио: Продаётся компьютер — один Вэ Эм Эр Эс Ха Те".

Здравствуйте, ZaharowAV, Вы писали:

ZAV>unsafe ...
ZAV>{
ZAV>...
ZAV>char *p;
ZAV>p = (char*)0xB8000000;
ZAV>*p='a'; // Допустим в левый верхний угол запишем символ 'a'.
ZAV>...
ZAV>}

Это провокация?

Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, ZaharowAV, Вы писали:

ZAV>>unsafe ...
ZAV>>{
ZAV>>...
ZAV>>char *p;
ZAV>>p = (char*)0xB8000000;
ZAV>>*p='a'; // Допустим в левый верхний угол запишем символ 'a'.
ZAV>>...
ZAV>>}

A>Это провокация?

В каком смысле?
Да никакая это не провокация.
Просто у меня был очень приличный опыт написания программок под досом, а теперь просто проверяю, что из того, что я умел осталось действительно, а что надо подтягивать. Каким бы RAD не был навороченным — сам он алгоритмы не придумает и не напишет. Вот и перевожу свой старый опыт на новые рельсы.

Короче — мне нужен ответ. Либо можно в консольном приложении писать в видеобуфер, либо нет. Мне полемика о моих способностях не нужна. Если кого-то это задело, то извините.

Здравствуйте, ZaharowAV, Вы писали:

ZAV>Короче — мне нужен ответ. Либо можно в консольном приложении писать в видеобуфер, либо нет.

Либо нет.

Здравствуйте, ZaharowAV, Вы писали:

Интересно, а разве в видеобуфере символы хранятся в уникоде???

Здравствуйте, ZaharowAV, Вы писали:

ZAV>Короче — мне нужен ответ. Либо можно в консольном приложении писать в видеобуфер, либо нет.

Не было, нет и не будет.

ZAV>Мне полемика о моих способностях не нужна. Если кого-то это задело, то извините.

Когда немного попривыкнешь к НЕТу, ответь сам на свой вопрос. Многое в реакции других станет понятней.

Здравствуйте, Belegel, Вы писали:

B>виндовс не позволит Вам вот так просто писать напрямую в видеопамять,
странно, но вот это пишет в видеопамять и виндовс позволяет....

.model small
.stack 100h
.code
.186
start:
push FAR_BSS
pop ds
xor ax,ax
int 1ah
mov di,320*200+1
fill_buffer:
imul dx,4e35h
inc dx
mov ax,dx
shr ax,15
mov byte ptr [di],al
dec di
jnz fill_buffer
mov ax,0013h
int 10h
new_cycle:
mov di,320*200+1
step_1:
mov al,byte ptr [di+1]
add al,byte ptr [di-1]
add al,byte ptr [di+319]
add al,byte ptr [di-319]
add al,byte ptr [di+320]
add al,byte ptr [di-320]
add al,byte ptr [di+321]
add al,byte ptr [di-321]
shl al,4
or byte ptr [di],al
dec di
jnz step_1
mov di,320*200+1
flip_cycle:
mov al,byte ptr [di]
shr al,4
cmp al,3
je birth
cmp al,2
je f_c_continue
mov byte ptr [di],0
jmp short f_c_continue
birth:
mov byte ptr [di],1
f_c_continue:
and byte ptr [di],0fh
dec di
jnz flip_cycle
push 0a000h
pop es
mov cx,320*200
mov di,cx
mov si,cx
inc si
rep movsb
mov ah,1
int 16h
jz new_cycle
mov ax,0003h
int 10h
mov ax,4c00h
int 21h
.fardata?
db 320*200+1 dup(?)
end start

Здравствуйте, DEMON HOOD, Вы писали:

DH>странно, но вот это пишет в видеопамять и виндовс позволяет....
Щаззз. Дайте ей только разбежаться побыстрее.

Читайте про виртуальный 8086-режим из-под 80386-защищенного.
Ничуть это не видеопамять. Более того, Ваш код замечательно
заботает на сервере вообще без видеоадаптеров, из терминальной
сессии. Там даже понятия такого нету, как видеопамять.

Павел.

Здравствуйте, DEMON HOOD, Вы писали:

B>>виндовс не позволит Вам вот так просто писать напрямую в видеопамять,
DH>странно, но вот это пишет в видеопамять и виндовс позволяет....

Как человек далекий от видео памяти. Можно ли символы писать в видео память? Разве там не оперируется пикселями?

Здравствуйте, mikа, Вы писали:

M>Как человек далекий от видео памяти. Можно ли символы писать в видео память? Разве там не оперируется пикселями?

В текстовом режиме оперируется символами.

Здравствуйте, ZaharowAV, Вы писали:

ZAV>Привет всем.
ZAV>Скажите, как можно сделать указатель на начало видеобуфера, чтобы самому писать на экран в текстовом режиме в консольном приложении на C#?

ZAV>пишу следующее:

ZAV>unsafe ...
ZAV>{
ZAV>...
ZAV>char *p;
ZAV>p = (char*)0xB8000000;
ZAV>*p='a'; // Допустим в левый верхний угол запишем символ 'a'.
ZAV>...
ZAV>}

ZAV>Так вот — в последней строке возникает исключение "В экземпляре объекта не задана ссылка на объект" и программа останавливается.

Может, указатель нужно создавать с помощью макроса MK_FP?

Здравствуйте, Serginio1, Вы писали:

S> Интересно, а разве в видеобуфере символы хранятся в уникоде???
Да, ведь один символ занимает два байта!

Hello, !
You wrote on Thu, 05 Aug 2004 15:47:04 GMT:

S>> Интересно, а разве в видеобуфере символы хранятся в уникоде???
> Да, ведь один символ занимает два байта!

А где смайлик? Там байт под символ и байт под атрибуты.

With best regards, Sergey.

Здравствуйте, Sergey, Вы писали:

S>Hello, !
S>You wrote on Thu, 05 Aug 2004 15:47:04 GMT:

S>>> Интересно, а разве в видеобуфере символы хранятся в уникоде???
>> Да, ведь один символ занимает два байта!

S>А где смайлик? Там байт под символ и байт под атрибуты.

S>With best regards, Sergey.
Да уж как давно то это было.
Все никак вспомнить не могу. Байт под символ,а второй делился под цветом бэкграунда и соответственно под цвет символа, причем последний бит под мерцание.
Интересно как будет выглядеть уникодная русская 'Ё'

Здравствуйте, Блудов Павел, Вы писали:


DH>>странно, но вот это пишет в видеопамять и виндовс позволяет....
БП>Щаззз. Дайте ей только разбежаться побыстрее.

Дорогой ZaharowAV, виндовс не позволит Вам вот так просто писать напрямую в видеопамять, на каком бы языке программирования

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

БП>Читайте про виртуальный 8086-режим из-под 80386-защищенного.
БП>Ничуть это не видеопамять. Более того, Ваш код замечательно


хотя,
мне по большому счёту всё равно куда будут записыватся мои байты, в видяху или нет, главное что программа работает так как было задумано.

Здравствуйте, DEMON HOOD, Вы писали:

... <<Rammstein — You hate Rsdn@Home 1.1.4 beta 1 Windows XP 5.1.2600.0 >>

Здравствуйте, ZaharowAV, Вы писали:

ZAV>Привет всем.
ZAV>Скажите, как можно сделать указатель на начало видеобуфера, чтобы самому писать на экран в текстовом режиме в консольном приложении на C#?

ZAV>пишу следующее:

ZAV>unsafe ...
ZAV>{
ZAV>...
ZAV>char *p;
ZAV>p = (char*)0xB8000000;
ZAV>*p='a'; // Допустим в левый верхний угол запишем символ 'a'.
ZAV>...
ZAV>}

ZAV>Так вот — в последней строке возникает исключение "В экземпляре объекта не задана ссылка на объект" и программа останавливается.

Если вы хотите записать произвольный символ(ы) в произвольное место консольного окна, то вам нужны функции
WriteConsoleOutputCharacter
WriteConsoleOutput
WriteConsoleOutputAttribute
Подробности — в MSDN.
С уважением, Сергей.

Здравствуйте, Serginio1, Вы писали:

S> Все никак вспомнить не могу. Байт под символ,а второй делился под цветом бэкграунда и соответственно под цвет символа, причем последний бит под мерцание.
Не всегда, можно установить так, чтобы последний бит отвечал за яркость фонового цвета, а не за мигание

S>Интересно как будет выглядеть уникодная русская 'Ё'
Как темнокрасная рожа на черном фоне.

Не, прямое управление адаптером EGA — это вещь, не то что сейчас — хлебом не корми, дай блитнуть трукалором...

Здравствуйте, der Igel, Вы писали:

DI>Здравствуйте, DEMON HOOD, Вы писали:

DI>... <<Rammstein — You hate Rsdn@Home 1.1.4 beta 1 Windows XP 5.1.2600.0 >>

DI>
прикольно получилось

Здравствуйте, ZaharowAV, Вы писали:

ZAV>unsafe ...
ZAV>{
ZAV>...
ZAV>char *p;
ZAV>p = (char*)0xB8000000;
ZAV>*p='a'; // Допустим в левый верхний угол запишем символ 'a'.
ZAV>...
ZAV>}

Даже для DOS нулей многова-то. Правильный адрес 0000:0xB800, то есть 0xB800 * 16 = 0xB80000.

ZAV>char *p;
ZAV>p = (char*)0xB8000000;
ZAV>*p='a'; // Допустим в левый верхний угол запишем символ 'a'.

— Да, печальная история.
Подумал я и вспомнил как когда-то сам, когда перелазил на Win-ды
пытался откомпилировать прогу использующую BGI, на BCW 3.1.

> Даже для DOS нулей многова-то. Правильный адрес 0000:0xB800, то есть
> 0xB800 * 16 = 0xB80000.
>
Ну тогда уж 0xB8000!!!
Но и не стоит забывать о линейном рижиме адресации видеоадаптеров!!!

Здравствуйте, Stanky, Вы писали:

>> Даже для DOS нулей многова-то. Правильный адрес 0000:0xB800, то есть
>> 0xB800 * 16 = 0xB80000.
>>
S>Ну тогда уж 0xB8000!!!

Да, точно, умножил неправильно.

S>Но и не стоит забывать о линейном рижиме адресации видеоадаптеров!!!

Ещё раз, для чайников: что за линейный реджим адресации видеоадаптеров?

SH>Да, точно, умножил неправильно.

S>>Но и не стоит забывать о линейном рижиме адресации видеоадаптеров!!!

SH>Ещё раз, для чайников: что за линейный реджим адресации видеоадаптеров?

Видимо, имеется ввиду LFB. 2Stanky — а что, текстовый режим уже работает с ЛФБ? Очень сомнительно. Насколько я понимаю, все равно используется соотв. окно физической памяти и VGA регистры.

> Видимо, имеется ввиду LFB. 2Stanky — а что, текстовый режим уже
> работает с ЛФБ?
>
Честно говоря не пробовал!!! Но сам подумай логически — когда мы в графическом режиме пишем в стандартное окно (A0000-...) мы же получаем то же самое, что при работе с линейным буфером!!! Мне кажется, что данный попадают в одно и то же место в видеопамяти, просто ради совместимости окно оставлено!!!

>> Видимо, имеется ввиду LFB. 2Stanky — а что, текстовый режим уже
>> работает с ЛФБ?
>>
S>Честно говоря не пробовал!!! Но сам подумай логически — когда мы в графическом режиме пишем в стандартное окно (A0000-...) мы же получаем то же самое, что при работе с линейным буфером!!! Мне кажется, что данный попадают в одно и то же место в видеопамяти, просто ради совместимости окно оставлено!!!

Понятие "логически" к PC железу применять сложно. Кругом одни подпорки. Сам я не пробовал, но уверенности в этом у меня нет — например, непонятно, как тогда переключать текстовые экраны (а их в зависимости от режима, могло быть несколько) и как они расположены в буферах различных видеокарт. А вот на физические адреса они (текстовые страницы) мапятся одинаково вне зависимости от строения LFB в этом режиме для конкретной видеокарты — таков уж стандарт CGA\VGA, и производители обязаны ему следовать. Поэтому мне думается, что глубоко внутри системы в текстовых (полноэкранных) режимах используется именно эти физические адреса, хотя бы ради совместимости.

S>>Честно говоря не пробовал!!! Но сам подумай логически — когда мы в
S>>графическом режиме пишем в стандартное окно (A0000-...) мы же получаем
S>>то же самое, что при работе с линейным буфером!!! Мне кажется, что
S>>данный попадают в одно и то же место в видеопамяти, просто ради
S>>совместимости окно оставлено!!!

> Понятие "логически" к PC железу применять сложно.
>
Вообщето в данном контексте понятие "логически" было применено к тебе, а вернее это была директива твоему мозгу включить логику!!!

> Кругом одни подпорки. Сам я не пробовал, но уверенности в этом у меня нет
> — например, непонятно, как тогда переключать текстовые экраны (а их в
> зависимости от режима, могло быть несколько)
>
А как переключаются буферы при двойной буферизации? Точно так же!!!

> и как они расположены в буферах различных видеокарт.
>
А это мы сами можем выбирать!!!

> А вот на физические адреса они (текстовые страницы) мапятся одинаково вне
> зависимости от строения LFB в этом режиме для конкретной видеокарты — таков
> уж стандарт CGA\VGA, и производители обязаны ему следовать. Поэтому мне
> думается, что глубоко внутри системы в текстовых (полноэкранных) режимах
> используется именно эти физические адреса, хотя бы ради совместимости.
>
Это всего лишь адреса видеопамяти отображённые на системную!!!
Вот допустим к одному и тому же куску видеопамяти можно обратиться по адресам: 0A000 и 0D2000000!!!

Свою гипотизу я уже подтвердил экспериментально!!!

>> Понятие "логически" к PC железу применять сложно.
>>
S>Вообщето в данном контексте понятие "логически" было применено к тебе, а вернее это была директива твоему мозгу включить логику!!!

Мой мозг, к счастью, не умеет мыслить так логично, как Ваш

>> Кругом одни подпорки. Сам я не пробовал, но уверенности в этом у меня нет
>> — например, непонятно, как тогда переключать текстовые экраны (а их в
>> зависимости от режима, могло быть несколько)
>>
S>А как переключаются буферы при двойной буферизации? Точно так же!!!

При чем здесь это? Двойная буферизация реализуется средствами DirectX, что является частью Direct DDI — смотрите DDK. К текстовым режимам это не относится — они не имеют _никакой_ поддержки со стороны драйверов. Все реализуется средствами системы, и, вполне очевидно, что стандартыми регистрами CGA\VGA + стандартным окном в физическом адресном пространстве.

>> и как они расположены в буферах различных видеокарт.
>>
S>А это мы сами можем выбирать!!!

Не можем. Под виндовс мы ничего не можем, если не в нулевом кольце, да и там все сравнительно непросто. Долго объяснять, просто посмотрите IOCTL_VIDEO_xxx и DDI, и убедитесь, что никаких вариантов работы с текстовым режимом просто нет. По крайней мере, никому еще побороть это не удалось http://www.radmin.com/ru/support/faq.php#3_2

>> А вот на физические адреса они (текстовые страницы) мапятся одинаково вне
>> зависимости от строения LFB в этом режиме для конкретной видеокарты — таков
>> уж стандарт CGA\VGA, и производители обязаны ему следовать. Поэтому мне
>> думается, что глубоко внутри системы в текстовых (полноэкранных) режимах
>> используется именно эти физические адреса, хотя бы ради совместимости.
>>
S>Это всего лишь адреса видеопамяти отображённые на системную!!!
S>Вот допустим к одному и тому же куску видеопамяти можно обратиться по адресам: 0A000 и 0D2000000!!!

Для вашей видеокарты — возможно. А что, скажем, если карта не поддерживает LFB? (а представьте, такие очень часто бывают, например, на терминал серверах, где, собственно, кроме консоли часто ничего и не надо)

S>Свою гипотизу я уже подтвердил экспериментально!!!

На конкретно взятом оборудовании — вполне вероятно. На всем доступном спектре — гарантируются только стандартные окна в физических адресах. Ими и пользуется система для вывода консоли при загрузке и для полноэкранного текстового режима.

> При чем здесь это? Двойная буферизация реализуется средствами DirectX,
> что является частью Direct DDI — смотрите DDK.
>
Стоп, стоп, стоп!!! Кто тут вообще про винду говорил? Я имел ввиду, то как это на самом нижнем уровне происходит!!! Грубо говоря есть несколько текстовых буферов из которых только один может быть активным, чтобы увидеть другой текстовый экран мы просто меняем адрес начала буфера!!! Работаем напрямую с видюхой!!!

> К текстовым режимам это не относится — они не имеют _никакой_ поддержки со
> стороны драйверов.
>
Ну я бы не стал так категорично это утверждать!!!
Взять ту же VESA — там есть 5 текстовых режимов, которыми можно пользоваться в режиме линейной адресации!!! Номера режимов: 108h, 109h, 10Ah, 10Bh, 10Ch!!!
Почему же в винде драйвер не может использовать линейный буфер для вывода текста (в полноэкранном режиме)?

> Все реализуется средствами системы, и, вполне очевидно, что стандартыми
> регистрами CGA\VGA + стандартным окном в физическом адресном пространстве.
>
Может конечно оно и так!!!

>>> и как они расположены в буферах различных видеокарт.
S>>А это мы сами можем выбирать!!!

> Не можем. Под виндовс мы ничего не можем, если не в нулевом кольце, да
> и там все сравнительно непросто.
>
Я вообще про Windows речи не вёл — я работал с голым железом!!!

S>>Вот допустим к одному и тому же куску видеопамяти можно обратиться по
S>>адресам: 0A000 и 0D2000000!!!

> Для вашей видеокарты — возможно. А что, скажем, если карта не
> поддерживает LFB?
>
Неужели сейчас такое можно найти?
Ну даже если и не поддерживает, моё-то предположение состояло в том, что всё что записывается в окно 0A0000-0BFFFF можно прочитать или перезаписать пользуясь адресами линейного буфера и наоборот!!!

> (а представьте, такие очень часто бывают, например, на терминал серверах,
> где, собственно, кроме консоли часто ничего и не надо)
>
И неужели линейный буфер так трудно реализовать, что даже сейчас попадаются видюхи без них?
Как мне кажется это всё пережитки прошлого — так как раньше нельзя было записать больше 64КБ в видюхах использовали окна видеопамяти по 64КБ, которые доставляли просто огроменную массу гемороя!!! По заполнению одного окна нужно было переходить к другому!!! При работе с графикой постоянно контролировать пересечения границ окон, например при рисовании диагональной линии!!!
Так что если не принимать во внимание совместимость, то гораздо проще (в аппаратной реализации) выкинуть нахрен весь этот хлам совместимости и сделать видеопамять линейной нежели наоборот!!!

> На конкретно взятом оборудовании — вполне вероятно. На всем доступном
> спектре — гарантируются только стандартные окна в физических адресах.
> Ими и пользуется система для вывода консоли при загрузке
>
Откуда такая уверенность?
А вот такой вопрос: а логотип Wind'ы при загрузке тоже в стандартное окно выводится?

> и для полноэкранного текстового режима.
>
А про это уже говорилось выше!!!

S>Стоп, стоп, стоп!!! Кто тут вообще про винду говорил? Я имел ввиду, то как это на самом нижнем уровне происходит!!! Грубо говоря есть несколько текстовых буферов из которых только один может быть активным, чтобы увидеть другой текстовый экран мы просто меняем адрес начала буфера!!! Работаем напрямую с видюхой!!!

Вообще то это форум по винапи, тут все относительно системы. Иначе вы ошиблись форумом.

>> К текстовым режимам это не относится — они не имеют _никакой_ поддержки со
>> стороны драйверов.
>>
S>Ну я бы не стал так категорично это утверждать!!!
S>Взять ту же VESA — там есть 5 текстовых режимов, которыми можно пользоваться в режиме линейной адресации!!! Номера режимов: 108h, 109h, 10Ah, 10Bh, 10Ch!!!
S>Почему же в винде драйвер не может использовать линейный буфер для вывода текста (в полноэкранном режиме)?

Потому что в виндовс драйвер (точнее, минипорт) не обслуживает стандартные VGA режимы (в частности, int10 моде 3), а отдает их HAL.

>> Все реализуется средствами системы, и, вполне очевидно, что стандартыми
>> регистрами CGA\VGA + стандартным окном в физическом адресном пространстве.
>>
S>Может конечно оно и так!!!

Я очень надеюсь, что так

>>>> и как они расположены в буферах различных видеокарт.
S>>>А это мы сами можем выбирать!!!

>> Не можем. Под виндовс мы ничего не можем, если не в нулевом кольце, да
>> и там все сравнительно непросто.
>>
S>Я вообще про Windows речи не вёл — я работал с голым железом!!!

Еще раз — форум про винапи и мы говорим о том, как работает с текстовым режимом виндовс. В данном случае мы говорим не о user-mode интерфейсе с консолью, там все очевидно и понятно из MSDN, а о том, как сама система работает в fullscreеn text mode. Повторю — все это мои догадки, основанные на собственных изучениях HAL, исследовании видео-драйверов\минипортов и нескольих топиках в группо-гугле. Тут я могу, конечно, ошибаться, и если у вас есть действительно агрументированный довод — интересно будет услышать. Пока что ничего кроме эмоций я тут не вижу. (кстати, к чему столько восклицательных знаков?)

S>>>Вот допустим к одному и тому же куску видеопамяти можно обратиться по
S>>>адресам: 0A000 и 0D2000000!!!

Можно. Но в LFB два банка для текстового буфера могут быть расположены не последовательно, а в адреса B8000 мапится последовательно (конечно, вряд ли, но теоретически это вполне возможно, история учит, что нет предела идиотизму), как того требует СТАНДАРТ CGA\VGA. Более того, повторюсь, система не предоставляет минипорту какой-либо возможности (ну, или я ее просто не заметил) работать с текстовыми режимами, осуществляя все это сама. У вам есть другие данные? Будет интересно узнать.

>> Для вашей видеокарты — возможно. А что, скажем, если карта не
>> поддерживает LFB?
>>
S>Неужели сейчас такое можно найти?
Есть. NT4+ ISA VGA card. Вполне себе терминальный сервер. Там даже VESA 1.2 может не быть, что, конечно, извращение. Вследствие чего можно предположить, что HAL не вызывает даже INT10 (поскольку это довольно затруднительно в защищенном резиме, а для VESA ниже 2.0 интерфейса с защищенным режимом нет), а пользует напрямую well-known стандартные vga\cga регистры, особенно это видно как виндовс поддерживает некоторые нестандартные текстовые режимы, задать которые только через INT10 затруднительно. Хотя возможно (не всегда) вызывать int10 для минипорта таки есть — VideoPortInt10.

S>Ну даже если и не поддерживает, моё-то предположение состояло в том, что всё что записывается в окно 0A0000-0BFFFF можно прочитать или перезаписать пользуясь адресами линейного буфера и наоборот!!!

Можно. Но где это будет находится в линейном буфере (если он есть) — непонятно. Вы встречали гарантии, что буфер для текста int10 mode3 обязательно будет в начале линейного буфера? Я почему то нет. Наверное потому, что когда разрабатывали эти режимы, про LFB не было и речи, а 256 кб памяти для видеоадаптера были просто роскошью. Еще раз — нет смысла системе использовать LFB там, где это не надо. Ровно так же нет смысла и вам.

>> (а представьте, такие очень часто бывают, например, на терминал серверах,
>> где, собственно, кроме консоли часто ничего и не надо)
>>
S>И неужели линейный буфер так трудно реализовать, что даже сейчас попадаются видюхи без них?
S>Как мне кажется это всё пережитки прошлого — так как раньше нельзя было записать больше 64КБ в видюхах использовали окна видеопамяти по 64КБ, которые доставляли просто огроменную массу гемороя!!! По заполнению одного окна нужно было переходить к другому!!! При работе с графикой постоянно контролировать пересечения границ окон, например при рисовании диагональной линии!!!
S>Так что если не принимать во внимание совместимость, то гораздо проще (в аппаратной реализации) выкинуть нахрен весь этот хлам совместимости и сделать видеопамять линейной нежели наоборот!!!

Вам может и проще, а система должна работать на любой доступной стандартой конфигурации оборудования, что для видео сейчас считается VGA. К тому же мы сейчас говорим не про графические режимы, а про текстовые полноэкранные. Для виндовс это совершенно различные вещи.

>> На конкретно взятом оборудовании — вполне вероятно. На всем доступном
>> спектре — гарантируются только стандартные окна в физических адресах.
>> Ими и пользуется система для вывода консоли при загрузке
>>
S>Откуда такая уверенность?
S>А вот такой вопрос: а логотип Wind'ы при загрузке тоже в стандартное окно выводится?

Включите консольный режим + текстовый режим загрузки (см соотв. флаги boot.ini) и убедитесь, что используется один из стандартных режимов уже _до_ загрузки любых видео драйверов. А вообще — к чему этот вопрос? Ответ на него никоим образом не определяет, как работает система в полноэкранном текстовом режиме после загрузки, о чем собственно сейчас идет речь.
В общем, я утверждаю, что при работе в текстовом режиме лучше не вспоминать о LFB Да и лучше вообще не вспоминать — это все проблемы системы, как работать с оборудованием, есть там LFB, или его придется эмулировать guard pages, или оперировать банками. Важно знать лишь то, что не все так просто, как кажется на первый взгляд и помнить, что это осталось в далеком прошлом, когда был жив DOS, 4 мб памяти считалось очень много, а дум вполне летал на 386-й машине и по геймплею забивал все современные шутеры.

Здравствуйте, ZaharowAV, Вы писали:

1) Прямой доступ к видео-памяти как в текстовом так и в графическом режиме (в том числе SVGA) доступен только под Win9x. Операционки класса WinNT его зарубают насмерть. Небольшое уточнение: я экспериментировал не с консольным Win-приложением, а с DOS-приложением, запущенным под VDM. Так что не знаю, получится ли достучаться до видеопамяти из консольного Win-приложения даже под Win9x, то что под NT не выйдет — это точно.

2) Боюсь, что на языке на подобии C# подобное приложение написать будет достаточно сложно. Как минимум придётся использовать не char*, а byte*. Потому что char в .NET`е — это символ юникода (2 байта).

> Вообще то это форум по винапи, тут все относительно системы. Иначе вы
> ошиблись форумом.
>
Вспомним с чего всё началось:
> Даже для DOS нулей многова-то. Правильный адрес 0000:0xB800, то есть
> 0xB800 * 16 = 0xB80000.
>
Ну тогда уж 0xB8000!!!
Но и не стоит забывать о линейном рижиме адресации видеоадаптеров!!!

> Я очень надеюсь, что так
>
Да пожалуйста, я ведь не бью себя в грудь утверждая обратного!!!

> Повторю — все это мои догадки,
>
Точно так же, как и у меня!!!

> Пока что ничего кроме эмоций я тут не вижу.
>
Да вроде никаких эмоций не было!!!

> (кстати, к чему столько восклицательных знаков?)
>
Привычка!!! Это они вызвали у тебя чувство, что я очень эмоционален?

> У вам есть другие данные?
>
Я же ничего не утверждал, я лишь предполагал, что система работает с линейным буфером!!!

> Можно. Но где это будет находится в линейном буфере (если он есть) -
> непонятно. Вы встречали гарантии, что буфер для текста int10 mode3
> обязательно будет в начале линейного буфера?
>
Нет!!! И я даже могу точно сказать, что он не будет в начале (по крайней мере не у всех)!!! Я проверил свою гипотезу на 2 компах: на одном как не странно к началу линейного буфера пришлось прибавить 0B8000h, а на другом он был практически на начале линейного буфера!!!

> Еще раз — нет смысла системе использовать LFB там, где это не надо. Ровно
> так же нет смысла и вам.
>
Я же не говорил, что я его использую!!! Просто было интересно провести маленький эксперимент!!!

> Вам может и проще, а система должна работать на любой доступной
> стандартой конфигурации оборудования, что для видео сейчас считается
> VGA.
>
Ну я же говорил, если не брать во внимание совместимость!!!