Мастдай 2000 в эхотаге

Anatoly Mashanov сообщил в новостях следующее:

Именно так, и дело тут не в эмуляции, а в самом ДОСе. ДОС использует значение RTC только при старте, запоминая его как опорное. А в процессе работы вычисляет время, используя опорное значение и собственный счетчик, работающий от тиков системного таймера (18.2Гц, INT8). Который может уходить как и сам по себе, так и если какой-то резидент неаккуратно использует таймерное прерывание (запрещает, меняет частоту или не вызывает досовский обработчик).

Вообще-то, ничего тут особенно страшного нет - под Win API и писать приятнее, и надежней, и как раз там результат вполне гарантирован. Но, мне кажется, можно поискать пути и периодически забирать время от Windows в ДОС сессии. Часто ведь это делать не надо - раз в пару часов вполне достаточно. Например, можно попробовать вручную непосредственно регистры RTC периодически считывать. Или Win32 утилитку написать, которая, опять же, периодически текущее время твоей ДОС-проге передает.

Примите уверения в совершеннейшем к Вам почтении

Sat May 07 2005 11:17, Anatoly Mashanov wrote to All:

AM> Я в тоске, поскольку перевод задачи под Windows API потянет за собой AM> перевод с FOSSIL API на Windows COM port API, с негарантированным AM> результатом.

Ваши опасения по поводу Win COM port API понятны и, вероятно, вызваны просто незнанием последнего. Оно, однако, работает, чего бы там не говорили. Существуют методы взаимодействия DOS программы с Win, например через clipboard API или совсем тупо по принципу записали файл - считали файл. Hо не думаю что вам понравятся такие извращения.

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

VV> Существуют методы взаимодействия DOS программы с Win, например через VV> clipboard API А подробности/ссылку можно? Для Win9x я эту фичу нашёл (ЕМНИП, winoldap.mod, AH=17h INT 2Fh), работает. А для Win2000/XP - нету. Или есть?

Hi Anatoly, hope you are having a nice day!

08 Май 05, Anatoly Mashanov wrote to Vladimir Vassilevsky:

VV>> Ваши опасения по поводу Win COM port API понятны и, вероятно, VV>> вызваны просто незнанием последнего. Оно, однако, работает, чего VV>> бы там AM> Я опасаюсь не этого. Я опасаюсь того, что поведение таймера в ДОС-окне AM> аналогично поведению таймера обычной задачи,

Кстати, попробуй создать ярлык для этой программы и в его свойствах поставь галку Свойства->Программа->Дополнительно->Эмуляция совместимого аппаратного таймера.

Правда не знаю поможет это чем-то или нет.

WBR, AVB

Hello Vladimir!

07 May 05 20:39, you wrote to me:

AM>> Я в тоске, поскольку перевод задачи под Windows API потянет за AM>> собой перевод с FOSSIL API на Windows COM port API, с AM>> негарантированным результатом.

VV> Ваши опасения по поводу Win COM port API понятны и, вероятно, вызваны VV> просто незнанием последнего. Оно, однако, работает, чего бы там

Я опасаюсь не этого. Я опасаюсь того, что поведение таймера в ДОС-окне аналогично поведению таймера обычной задачи, тогда как NTP клиент или окно "Свойства: время и дата" обычной задачей не является. Переход же на COM API все равно когда-то нужен, тк компорты исчерпаны, а Cronyx под виндами не поддерживается, значит, PL2303 :-(

Anatoly

Sat May 07 2005 11:17, Anatoly Mashanov wrote to All:

AM> Hello All!

AM> Имеется некая система управления объектом (Конкретно - эталоном-копией AM> Государственного эталона времени и частоты, но это неважно) , сделанная и AM> работающая под ДОСом. Делается другая подобная система, в которой AM> работает задача от первой и еще пара досовских задач. Делается это под AM> Win2000ProSP4. Таково требование заказчика.

Убедить заказчика в том что требование му(бип)ацкое и ничем хорошим это не кончится и что делать надо в более адекватной среде.

SY, EK

Hello Evgeny!

08 May 05 15:51, you wrote to me:

AM>> Имеется некая система управления объектом (Конкретно - AM>> эталоном-копией Государственного эталона времени и частоты, но AM>> это неважно) , сделанная и работающая под ДОСом. Делается другая AM>> подобная система, в которой работает задача от первой и еще пара AM>> досовских задач. Делается это под Win2000ProSP4. Таково AM>> требование заказчика.

EK> Убедить заказчика в том что требование му(бип)ацкое и ничем хорошим EK> это не кончится и что делать надо в более адекватной среде.

Заказчика (Госэталон), как и подрядчика (Копию Госэталона) убедить невозможно: нет денег для того, чтобы нанять операторов, способных понять адекватную среду. К тому же, вновь разрабатываемая система занимается контролем передач. Управлением передачами занимается стоящая за 50 км FreeBSD, а там нет ни гуя, ни проблем, и вообще туда не ступает нога оператора.

Anatoly

Anatoly, ты ещё здесь сидишь?

Воскресенье Май 08 2005 22:37, Anatoly Mashanov wrote to Evgeny Kotsuba:

EK>> Убедить заказчика в том что требование му(бип)ацкое и ничем EK>> хорошим это не кончится и что делать надо в более адекватной EK>> среде. AM> Заказчика (Госэталон), как и подрядчика (Копию Госэталона) убедить AM> невозможно: нет денег для того, чтобы нанять операторов, способных AM> понять адекватную среду.

Hет денег - нет и решения. Пусть попробуют обратиться в благотворительные фонды.

Георгий

Sun May 08 2005 23:37, Anatoly Mashanov wrote to Evgeny Kotsuba:

AM> Hello Evgeny!

AM> 08 May 05 15:51, you wrote to me:

AM>>> Имеется некая система управления объектом (Конкретно - AM>>> эталоном-копией Государственного эталона времени и частоты, но AM>>> это неважно) , сделанная и работающая под ДОСом. Делается другая AM>>> подобная система, в которой работает задача от первой и еще пара AM>>> досовских задач. Делается это под Win2000ProSP4. Таково AM>>> требование заказчика.

EK>> Убедить заказчика в том что требование му(бип)ацкое и ничем хорошим EK>> это не кончится и что делать надо в более адекватной среде.

AM> Заказчика (Госэталон), как и подрядчика (Копию Госэталона) убедить AM> невозможно: нет денег для того, чтобы нанять операторов, способных понять AM> адекватную среду. скупой, как известно, платит дважды. А тупой - четырежды. Ссылки на операторов говорят о несоответствии служебному положению людей, ответственных за принятие решений.

AM> К тому же, вновь разрабатываемая система занимается AM> контролем передач. какая разница ? Hаверняка она будет выходить в более другие сети и закладываться на насквозь гнилое с точки зрения бесопасности решение - хотя бы этого достаточно. SY, EK

AM> Заказчика (Госэталон), как и подрядчика (Копию Госэталона) AM> убедить невозможно: AM> нет денег для того, чтобы нанять операторов, способных понять AM> адекватную среду.

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

по делу:

оригинальная задача, я так понял, состоит в том чтобы запускать несколько DOSовских программ и виндозную оболочку (морду) ? Win2k в этом смысле вообще очень сомнительна, а Win95/98 совершенно не прокатывает по надежности

может есть смысл сделать то же самое под FreeBSD/Linux, используя dosemu ? можно даже попытаться использовать wine для морды, если лень осваивать нативные средства разработки

Tue May 10 2005 19:05, Dmitry Ponyatov wrote to Anatoly Mashanov:

DP> несколько DOSовских программ и виндозную оболочку (морду) ? Win2k в этом DP> смысле вообще очень сомнительна, а Win95/98 совершенно не прокатывает по DP> надежности DP> может есть смысл сделать то же самое под FreeBSD/Linux, используя dosemu?

DOSEMU да, предел надёжности... Валится от каждого чиха, от версии доса, версии иксов и в зависимости от фазы луны...

DP> можно даже попытаться использовать wine для морды, если лень осваивать DP> нативные средства разработки

Можно даже иметь раздельно две версии: для DOS и для *nix (включая windows). DJGPP никто не отменял.

Hello Anatoly.

Sat May 07 2005 11:17, Anatoly Mashanov wrote to All:

AM> Я в тоске, поскольку перевод задачи под Windows API потянет за собой AM> перевод с FOSSIL API на Windows COM port API, с негарантированным AM> результатом.

Извини, что поздно отвечаю - временно не читал эху. Hо, возможно, тебе оно ещё пригодится. :)

Попробуй почитать на MSDN про VDD - Virtual Device Drivers. Это интерфейс дос-задачи (NTVDM) в 2k/XP со специальной DLL-кой, которую ты пишешь сам и из которой можешь обращаться к Win32 API. Примеры и h-файлы есть в виндовом DDK.

Я с помощью такой методики "портировал" под 2k/XP досовскую програмку (пульт управления бензоколонкой), которая работает с нестандартным железом - мультипортовой карточкой RS232.

Кстати, тем, кто ещё иногда пользуется досовым софтом, очень рекомендую новый tame

После его установки дос-задачи работают быстро, гладко и не отъедают процессорное время. Причём даже настраивать ничего не надо. Софтина вроде как триальная 30 дней, но работает и после истечения срока. :)

Dimmy.

Hello Sergey.

Sat May 07 2005 16:07, Sergey Zabelin wrote to Anatoly Mashanov:

SZ> Hо, мне кажется, можно поискать пути и периодически забирать время SZ> от Windows в ДОС сессии.

Самый правильный путь - через VDD.

SZ> Часто ведь это делать не надо - раз в пару часов вполне достаточно.

А тут можно хоть раз в минуту.

Dimmy.

Hello Vladimir.

Sat May 07 2005 20:39, Vladimir Vassilevsky wrote to Anatoly Mashanov:

AM>> Я в тоске, поскольку перевод задачи под Windows API потянет за собой AM>> перевод с FOSSIL API на Windows COM port API, с негарантированным AM>> результатом.

VV> Ваши опасения по поводу Win COM port API понятны и, вероятно, вызваны VV> просто незнанием последнего. Оно, однако, работает, чего бы там VV> не говорили.

Городить там для асинхронного обмена надо много странного, типа тредов, callback-функций и использования объектов ядра. Впрочем, есть библиотечки, инкапсулирующие эти извраты.

Dimmy.

Hi Dimmy, hope you are having a nice day!

24 Май 05, Dimmy Timchenko wrote to Vladimir Vassilevsky:

VV>> вызваны просто незнанием последнего. Оно, однако, работает, чего VV>> бы там не говорили.

DT> Городить там для асинхронного обмена надо много странного, типа DT> тредов, callback-функций и использования объектов ядра.

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

Городить отдельные треды на прием и на передачу оправдано далеко не всегда, чаще только мешает. Калбеки лично я не использовал ни разу, достаточно бесполезная вещь (очень много ограничений на функциональность), хотя где-то может быть нужна. Что за объекты ядра ты имеешь ввиду я не понял, но реально достаточно иметь хендл порта и привязанный к нему оверлаппед блок для асинхронного обмена.

WBR, AVB