for flooders
:: Главная :: Решения :: Статьи :: Сайт М. Дроздова :: Файловый архив :: Книга по VFP 9 :: Русский Help Online :: OFF-LINE Форум
   Л и с о в о д ы   в с е х   с т р а н,  о б ъ е д и н я й т е с ь !!!  

Список Форумов  :: Visual Foxpro, Foxpro for DOS
   :: Помощь сайту :: 

Re: О работе FPD-приложений под Win 7x64
andrewk

Сообщений: 82
Дата: 09.06.18 16:38:42ОтветитьЦитировать
ещё две - vDosPlus и FPD под ним.
Ratings: 0 negative/0 positive


Вложения:
[vDP-3.png (47.6KB)]   [vDP-4.png (17.8KB)]  

Re: О работе FPD-приложений под Win 7x64
andrewk

Сообщений: 82
Дата: 09.06.18 17:10:57ОтветитьЦитировать
Откуда ноги
Есть давнишний проект vDos – разработка, идущая параллельно с DOSBox. DOSBox заточен на игры, vDos – на «не игры». vDos пилит Джош Чаарс (Jos Schaars, Нидерланды). Открытый код, freeware. Но в случае, если ОС работает в доменной сети или работает с файлами на сетевом ресурсе, то периодически (~3 часа) выводит окошко, просящая регистрацию. Регистрация стоит 35 евро на пользователя либо 150 евро на домен (или сетевой ресурс), пожизненно, включая следующие версии.
На основе исходников vDos есть (был) проект vDosPlus. Разработчик – Венгер Ву (Wengier Wu). Началось с добавления длинных имён, а потом появилась куча других дополнительных фич. Соответственно каждой версии vDos появлялась своя ветка (branch) vDosPlus. Венгер человек широкой души, окно убрал, возможность доната есть на его сайте, через PayPal. Но осенью 2017-го он написал, что проекту требуется новый maintainer («сопровождающий»). Последняя доступная сборка от Венгера – ветка 2015.11.01 билд от 15.03.2017.
Им стал Эдвард Мендельсон (Edward Mendelson) (www.wpdos.org). Крайняя сборка от него (на неё ссылается и Венгер как на наиболее актуальную) – ветка 2017.08.01 билд от 16.02.2018.

Сначала я с ней и игрался. Потом оставил на несколько часов запущенный vDosPlus 2017.08.01 с открытым в DosZip текстовым файлом, находящимся на сетевом диске. Когда вернулся и начал что-то делать, получил таки рекламное окошко. Прикладываю. Эдвард у себя писал, что он, по договорённости с Джошем и Венгером, взял исходники vDos 2017.08.01, внёс туда правки из исходников vDosPlus и ещё «некоторые правки, сделанные после завершения активной разработки vDosPlus». И, видимо, в процессе этой работы это окно не убрал. А может, эта «договорённость» это предусматривала.
В связи с этим заканчиваю игры с 2017.08.01 и переключаюсь на 2015.11.01. Найти какую-нибудь сборку ветки 2016.10.01 не смог.
Честно говоря жаль. На форуме Эдвард в феврале писал, что «оригинальный автор» (Венгер) прекратил разработку vDosPlus «без официальных объяснений». При этом разработка vDos будет продолжаться. Вышла версия 2018.05.01, в которой что-то там исправлено насчёт CPU и, главное, насчёт блокировок записей, «особенно сказывается при работе с БД по сети».

Все эксперименты проводились вперемешку на двух компьютерах, под WinXP (на работе) и Win7 x86 (дома). Поскольку здесь основное было уже написано под 2017.08.01, оставляю это и соответственно помечаю.

Про шрифты
Если в config.txt не устанавливать параметр FONT, то есть, не назначать свой шрифт, то используется какой-то встроенный. Он похож на Consola.ttf (но ноль «без палочки»), вполне аккуратненький.
(2015.11.01) Во встроенном шрифте кириллицы нет. Идущий в комплекте Nouveau_IBM мне не понравился. Взял Consola из Win7 (в WinXP нет псевдографики)
(2017.08.01) Встроенный показывает и кириллицу, и псевдографику.


Файловая система
Длинные имена поддерживает. Собственно, по словам Венгера, включение поддержки LFN и было поводом дл создания форка vDosPlus, а уж потом добавилось множество других фич. Но, как я не крутил, русские имена файлов показывает кракозябрами. Менял кодовые страницы на разных этапах запуска, отключал LFN (LFN=OFF), менял фильтрацию отображения (Filter83=ON/OFF) – глушняк.
Например, в FPD работает
MODIFY FILE D:\РАЗНОЕ\VDOSPLUS\!МОЁ\ЧИТАТЬ.TXT
а под vDosPlus при LFN=ON в Doszip это выглядит как
D:\?рчэюх\vDosPlus\!ью\abc2~1.txt
а при LFN=OFF
D:\FD8E~1\VDOSPLUS\!FE45~1\abc2~1.txt

Но, похоже, это проблема именно отображения. Например, несмотря на то, что SET выдаёт
PATH=C:\WINDOWS;C:\WINDOWS\SYSTEM32;D:\?рчэюх\VDOSPLUS\DOSZIP
если набрать "dz", то
D:\[b]Разное[/b]\vDosPlus\DosZip\dz.bat
находится и запускается.
Не критично, но неприятно. Скажется ли на реальной работе, буду посмотреть.


Клипбоард
Прелесть. Работают стандартные комбинации Ctrl+C, Ctrl+V, Ctrl+A. А если их нажимать с Win (кнопка с флагом Windows), то это работает с буфером хоста. Более того, работает Win+Ctrl+мышка. Нужность использовать для всего этого кнопку Win можно отключить в config.txt (WinKey=OFF).


Переменные окружения хоста
Чтобы их использовать, требуется определить соответствующую «внутреннюю» командой SET, окружив переменную хоста двойным "%%". Например:
set ComputerName=%%ComputerName%%
echo ComputerName=%ComputerName%

Но есть пробелемы:
1. У команды SET есть ограничение длины (во всяком случае в autoexec.txt). Эмпирически – 121 символ. Например, в vDP.bat создаём переменную в 115 символов:
set HostVar=................................................................................................................115  
  start "запуск vDosPlus" /d %~dp0 vDosPlus.exe
autoexec.txt:
set A=%%HostVar%%  
  echo A=%A%
так прокатывает.
А если значение HostVar увеличить на 1 символ ИЛИ вместо "set A=" сделать "set A1=" или даже "set A=", то выдаст "Windows variable is too long" и переменную не присвоит. При этом длина имени хост-переменной не влияет – оно и понятно, поскольку в команде "set A=%%HostVar%%" подставляется не она, а сразу её значение. Отсюда: MaxSetLen=len(HostVar+"set A=")=121 и MaxVarLen=115.

И с другой стороны. Создаём переменную в 64 символа. А в autoexec.txt:
set A=%%HostVar64%%  
  set B=%%HostVar64%%  
  set V=%A%%B%  
  echo %V%>vDP.log
При этом ошибку про длину не напишет, но длина V – 118 символов. Если "V" заменить на "V1" или " V", то 117 символов. Видимо, это те же 121, но не считая "set".

Возможно, как-то можно настроить 4DOS. Например, в 4DOS.ini есть "Environment=2048". Я не разбирался.
Сказаться это может для PATH. Например, сделав "set PP=%%PATH%%", получаем ошибку. Насколько это критично – дело частное. Я, например, всё равно запускаю из батника, в котором PATH подготовлена в сокращённом варианте, поэтому и так катит.

Кстати, в примерах Криспи (и похожее в примере разраба) при назначении PATH есть ".\DOSZIP". Но "." – это не папка запуска, а папка, текущая в каждый текущий момент. То есть, если мы перешли в D:\Folder и попытаемся запустить doszip.exe, то он будет искаться в D:\Folder\DOSZIP. Поэтому лучше примерно так:
PATH %PATH%;%vDosP_ExeDir%\DosZip
Есть несколько «встроенных» переменных (только в 2015.11.01). Описание в моём autoexec.txt.


2. С кириллицей в переменных опять возникает печаль, сходная с обсуждавшейся в соседней теме.
(2015.11.01)
Маленькие русские буквы (исключая "ё") хранятся в CP-1251. Например, "HostVar=вася", тогда
set Var=%%HostVar%%  
  echo Var=%Var%	– хрень  
  chcp 1251  
  echo Var=%Var%	– вася
Но заглавные как-то не так.

(2017.08.01)
Здесь лучше – все буквы в CP-1251.

Однако, ситуация лучше, чем с NTVDM. Здесь соответствие для кириллицы и chr(242)–chr(255) однозначное, а значит, конвертация обратимая. И при желании можно разобраться и потом в Фоксе юзать ChrTran(). Или даже в вызывающем батнике подобное забабахать. Псевдографика потеряется, но для переменных она не нужна.



Doszip Commander
На первый взгляд неплохо. Но
1. Как-то теряется в папках. То по ".." переходит сразу в корень (вроде, только при LFN=ON, на 2015.11.01 пока не сталкивался), то ещё чего-то. Короче, глюковат.
2. При включении в его настройках "auto delete history" при выходе тупо удаляет dz.cfg и потом его вообще не создаёт.
3. Не подхватывает размер окна, а меняет на свой. Два варианта по Alt+F9.
Но для работы он не нужен, а для экспериментов покатит.



Запуск программ
vDosPlus определяет, является ли запускаемое чисто DOS-программой или shell-командой (DIR...) либо нативной win-программой.
В первом случае это выполняется своими силами в своём окне, во втором случае – запускается новый процесс в новом окне. Прокатывает такое: "start 1.xlsx" или "start http: //ya.ru" – на самом деле выполняется не shell-команда START, а start.exe из папки vDosPlus.
Для win-программ создаётся независимый процесс со своим окном и окружением. Соответственно, такие штуки, как title, mode con не катят. Но (для некоторых) есть большие трудности.
В моём случае это потребует немало изменений в проге. Сейчас у меня всё «внешнее» запускается через "!cmd/c", в большинстве случаев – универсальный батник, который делает разные вещи. Но, во-вторых, он заточен под CMD и надо проверять, как там всё будет работать под 4DOS. А во-первых, печать и прочее выполняется через консольные win-программы (7z, curl, NirCmd...), а значит, управление уже вернётся в FPD пока они ещё работают в другом окне. Однако для запуска windows-программ в vDosPlus есть опции [WAIT][HIDE]. Короче, надо пробовать.
Кстати, так не катит:
cmd/c ipconfig>tmp.txt
Надо так:
cmd/c "ipconfig>tmp.txt"


Команда USE
Это смесь виндовых SUBST и NET USE. Можно так:
USE Q: D:\dosprog\
USE R: \\server\share\dosprog\
Наверное, для каких-то случаев удобно. Но для подключения сетевого ресурса не хватает логина/пароля.
В моём случае эта фича не нужна. Я всё равно это запускаю через универсальный батник, в котором, в том числе, при необходимости подключается нужный сетевой ресурс. А учитывая, что при замечательном параметре UseDrvs=ON все драйвы (буквы дисков), включая сетевые, «перекидываются» из хоста, то всё уже готово.

autoexec.txt
CHCP 866 – лишнее, хоть и указано в мануале. Если это не вписать, CP и так 866. Все проблемы с кодировками, которые выше описаны, остаются независимо от наличия или отсутствия этой команды.

На сайте написано, что если наша прога не использует INT9/IRQ1, то дополнительный драйвер клавиатуры не нужен, берётся раскладка хоста. То есть, переключиться можно, в том числе, мышкой по иконке.
Поэтому для FPD строка "KEYB RU,866,keybrd2.sys" лишняя.
(2017.08.01) НО не вводится русская маленькая "Р", ни с KEYB, ни без. Ситуацию исправило использование другого драйвера, у меня "lh KeyRus.com /click=off>nul", но при этом ожидаемо потерялась связь с раскладкой хоста.
(2015.11.01) Этой проблемы нет.


Экран
Размер устанавливается в строках/колонках. При запуске автоматом занимает 75% экрана, этот процент настраивается. Удобно. Не надо париться с размерами шрифтов. Классная фича: Ctrl+колесо меняет размер окна и, соответственно шрифта.
Стандартная палитра какая-то бледноватая. Но там настраивается, надо разбираться.

Память
По умолчанию отводится 16 МБ. У себя поставил 32 (config.txt: "XMem=32 XMS"). FPD рапортует о доступных 30. При этом в диспетчере задач процесс vDosPlus – 38 МБ, а при 16 (умолчание) – 14. (У меня FPD/ntvdm давно не реагирует ни на MemLimit в Config.fp – ошибся, были неверные значения). В шутку поставил 120 – Фокс на sys(1001) сказал, что видит 118 МБ. Правда если ставить больше, то вылетает на старте с "page fault".

CPU
В стоячем состоянии под Win7/32 – 0%, то есть всякие ResFree не нужны. А вот под WinXP/32 – 5–15%, есть над чем думать. NTVDM+ResFree – 0%.


Несмотря на некоторые нюансы и, для некоторых, требуемые доработки ПО (связанные с русскими именами файлов и вызовами внешних программ/команд), считаю vDosPlus намного более удобным вариантом DOS-программ, включая FoxPro, под x64, нежели VirtualBox и подобные технологии. Учитывая мизерные объёмы vDosPlus, его можно воткнуть прямо в свой дистрибутив или обновлялку. Словами Бегемота: королева в восхищении, мы в восхищении!


Производительность
Здесь слёзы восторга сменились слезами детской обиды.
Сам старт процесса и в нём запуск Фокса – очень быстро, никакого дискомфорта. Отклик интерфейса вполне приемлемый. Но вот расчётные вещи и ввод/вывод – тормоза безбожные.
Пример такой (суть процесса вам ни о чём не скажет, но относительные величины понятны). WinXP/32. Запустил расчёт квартплаты в одной БД. И программа, и база на жёстком диске (не сеть), однопользовательский режим без lock(), почти по всем лицевым счетам есть изменения относительно ранее расчитанного (то есть будет активная запись в БД):
NTVDM/ResFree 14 секунд 40–45% в пике 156 МБ ОЗУ
vDosPlus 483 секунды 48–50% в пике 42 МБ ОЗУ
В 35 раз...
Та же процедура, но запущенная повторно, то есть было только чтение и вычисления, записи не было (ничего не менялось):
NTVDM+ResFree 6 секунд (получается, что ~60% времени тратится на сохранение (но это не чисто вывод – там много что делается)
vDosPlus 330 секунд
Ещё хлеще, в 55 раз.

Джош пишет (мой вольный перевод): «теоретически, vDos может работать до 70 раз медленнее, чем NTVDM, это если не считать BIOS/DOS-запросы и файловый ввод/вывод. На практике же это где-то 5–10 раз. На сетевых подключениях и при использовании блокировок (в нашем случае – lock/unlock) разница будет менее значительной. Конечно, DOSBox будет работать намного быстрее – но за счёт внутреннего кэширования файловых операций, что неприемлемо при работе в многопользовательской среде, поскольку приведёт к повреждению файлов.»
Вообще-то, в ченджлоге крайней версии vDos 2018.05.01 говорится об оптимизации как раз таки ввода/вывода и блокировок и, возможно, там ситуация получше, но там нужна регистрация. Я бы и заплатил эти деньги (стряхнул бы с начальства), в конце концов каждый полезный труд должен быть вознаграждён, но там речь об оплате за каждое рабочее место либо сетевой ресурс с привязкой по id, то есть не «размножишь», а это меняет ситуацию.

Тем не менее, на сей момент я остаюсь при мнении, что vDosPlus – не просто отличный, но категорически лидирующий по удобству вариант запуска DOS-приложений, включая FoxPro, под x64. Подавляющему большинству эти проги приходится запускать от случая к случаю, а даже если и постоянно, то они выполняют «мелкие» задачи, а значит, тормоза не играют определяющую роль. В случаях же типа моего, когда прога выполняет ключевые задачи бизнес-процессов, ну... так скажу, глобальные расчёты проводятся раз в месяц, и если уж нет 32-машины, то можно и на ночь поставить, а при текущей работе, ну будет какое-то действие выполняться не 0.5, а 3 секунды, это не катастрофа. Зато то время, которое приходится тратить на установку VirtualBox и приведение его в чувства после очередного обновления Винды, куда лучше потратить на окончательное избавление от FPD.

После праздников доведу настройки до ума и попробую поставить «в боевой» режим на пару машин в своей конторе. Как раз расчёты закончились, начнётся текучка, там работа сетевая – проверю как всякие блокировки отрабатывают. Потом отпишусь.



Исправлено: andrewk, 15.06.18 05:38
Ratings: 0 negative/0 positive


Вложения:
[nag-window 2017.08.01.png (4.3KB)]  

Re: О работе FPD-приложений под Win 7x64
Simple777

Сообщений: 19015
Дата: 09.06.18 19:19:18ОтветитьЦитировать
В моем случае есть режимы, где снижение производительности в 10-15 раз (не говоря уже о 50!) абсолютно неприемлемо...
Ratings: 0 negative/0 positive

Re: О работе FPD-приложений под Win 7x64
akvvohinc

Сообщений: 2756
Откуда: Москва
Дата: 10.06.18 04:38:31ОтветитьЦитировать
andrewk
у меня FPD/ntvdm давно не реагирует ни на MemLimit в Config.fp, ни на настройки в pif и всегда берёт 30 МБ под Win7 и 150 под WinXP

Поясни этот момент - не реагирует на MemLimit в Config.fp вообще, или не можешь сделать больше 150 под XP?

Приведи два варианта разных MemLimit, которые у тебя выдают одинаковые результаты.
И как смотришь результат напиши, если не через SYS(1001).
Ratings: 0 negative/0 positive

Re: О работе FPD-приложений под Win 7x64
Crispy
Автор

Сообщений: 12832
Дата: 11.06.18 08:21:52ОтветитьЦитировать
andrewk

Исследование в принципе любопытное. Как информацию к размышлению в различных случаях думаю кому-то может быть даже полезно в чем-то.
Не совсем правда понятна конечная цель использования данного в общем-то как бы вынужденно промежуточного приспособления (vFosPlus).
В моем случае например, он просто сыграл роль некоего вынужденного эмулятора, с чем относительно неплохо справился.
Само собой, если бы МС не встали в позу зю и не отказались от создания NTVDM под 64, а чисто технически думаю никаких проблем в этом бы не было, разумеется, было бы предпочтительней не использовать вообще ничего стороннего. Но тут уже чистая политика и прочее выдавливание с их стороны. Они зверски даже ХР-то вон как вытесняли незаконным подкупом, давлением на производителей софта и прочими нелегальными средствами крупного бизнеса. Но не будем дразнить гусей, а то тема может уйти в очередное гагага. Я просто к тому, что в любом случае всем тем, у кого есть такая необходимость, как запуск FPD под 64, приходится как-то извращаться. Т.е. изыскивать решение каким угодно способом.
Либо - переписывать свои приложения в VFP. Третьего, как говорится, не дано.
Так что выбирать особо не приходится. В самом начале я перечислил все основные возможности. Для моей ситуации все они подошли в гораздо меньшей степени, чем vDosPlus.
Просто любопытно - в твоих экспериментах очень много описана непосредственная работа в дос-среде (в командной строке vDosPlus). Неужели для работы твоих приложений действительно нужна такая "голая работа в Дос"?
Скажем по доступным каталогам - доступ в самом FPD в принципе элементарно регулируется SET DEFAULT и SET PATH. Т.е. собственно установки Доса как бы большой роли тут не играют. Да и никогда не играли. У Фокса и у Доса - как бы свои "независимые территории" в этом смысле были. Смена директории в одном не влияла на смену в другом.
По поводу же русских имен - это тоже как бы древнее правило фокс-программирования. Некие 10-фоксзаповедей. Одна из которых - никогда не использовать не-английских имен. Соблюдение чего в принципе никогда не подводило. Нарушение же - могло вызывать только лишние проблемы.
Что же касается производительности.
Не берусь утверждать конечно на все 100%. Но сколько приходилось наблюдать и пробовать в FPD - все тормоза и проблемы в вычислениях (та же избыточная загрузка памяти), как правило, всегда были связаны с использованием вычислений в циклах (еще и многократно вложенных порой). Которыми я например пользовался обычно только по крайней нужде. Предпочитая составлять вместо этого выражения в SELECT-SQL выборках. Сегодня это уже сложнее измерить. Но скажем, когда использовали Пентиум-1-133, однажды это даже так явно проявилось, что бухша не поверила, что что-то вообще вычисляется. Т.е. в написанной до меня проге некий процесс вычислялся где-то минут 10, в моей же выборке - какие-то доли секунды. Как лишнее подтверждение порочности циклических методов вычисления. Впрочем, "чисто по-человечески" конечно можно понять "пишущих циклами". Чтобы так писать - достаточно сесть и тупо набить весь код за каких-то полчаса, а потом идти пить чай. В то время, как с той же выборкой придется помучиться возможно полдня. Ну это к слову как бы. Понятно в любом случае, что кардинально переделывать старые проги даже ради повышения производительности вряд ли кто уже будет.
В целом же, думаю твои, чисто практические эксперименты, по-своему достаточно интересны. Главное разумеется во всем этом - найти приемлемое и для своего случая решение.


------------------
В действительности все иначе, чем на самом деле.
                                      (Антуан де Сент-Экзюпери)




Исправлено: Crispy, 11.06.18 08:23
Ratings: 0 negative/0 positive

Re: О работе FPD-приложений под Win 7x64
Igor Korolyov

Сообщений: 31505
Дата: 11.06.18 09:34:56ОтветитьЦитировать
Crispy
Само собой, если бы МС не встали в позу зю и не отказались от создания NTVDM под 64, а чисто технически думаю никаких проблем в этом бы не было
Разумеется БЫЛИ. Там где технических проблем нет, в 32-разрядных версиях ОС, NTVDM вполне себе существует (пусть и как опциональный компонент), и никто его решительно не "убивал".
Crispy
Они зверски даже ХР-то вон как вытесняли незаконным подкупом, давлением на производителей софта и прочими нелегальными средствами крупного бизнеса.
Тебе кто-то запрещает установить WinXP (ну если есть лицензия, конечно)? Более того, сейчас даже продаются компьютеры с предустановленным FreeDOS-ом (чтобы не платить за лицензию на ОС) - если твой софт такой уникальный и незаменимый - не проблема под него ОС подобрать, а не наоборот - софт под ОС.
Не понимаю странной привычки чего-то "требовать" от других коммерческих предприятий - они исходят из своих интересов, в основе которых всё же желание удовлетворить пользователей (т.к. именно они являются основными клиентами), а не из интересов прямо скажем странных производителей прикладного ПО, не желающих модернизации и новых возможностей.


------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: О работе FPD-приложений под Win 7x64
BOBAN

Сообщений: 541
Откуда: Солигорск
Дата: 11.06.18 12:30:16ОтветитьЦитировать
andrewk
Вообще-то, в ченджлоге крайней версии vDos 2018.05.01 говорится об оптимизации как раз таки ввода/вывода и блокировок и, возможно, там ситуация получше, но там нужна регистрация.

А можно оценить скорость 2018.05.01-й версии ?



Исправлено: BOBAN, 11.06.18 12:30
Ratings: 0 negative/0 positive

Re: О работе FPD-приложений под Win 7x64
andrewk

Сообщений: 82
Дата: 14.06.18 18:44:41ОтветитьЦитировать
akvvohinc
не реагирует на MemLimit в Config.fp вообще, или не можешь сделать больше 150 под XP?
Потому что олень. Я в него не заглядывал даже предположить не могу сколько лет, а там, видать после каких-то экспериментов, была чушь без верхней границы. Сейчас исправил на "MemLimit=1,8192,32768", проверил под WinXP и Win7 – работает как и предполагается.


Crispy
Не совсем правда понятна конечная цель использования данного в общем-то как бы вынужденно промежуточного приспособления (vFosPlus).
Конечная цель – исключительно в соответствии с заголовком темы – возможность запуска FPD под Win x64.

Crispy
в твоих экспериментах очень много описана непосредственная работа в дос-среде (в командной строке vDosPlus)
Дак потому что о настройках самого vDosPlus и «технологии работы с ним» ты подробненько уже расписал в своём первом посте, за что безусловный поклон . Я и не циклился на этом. Остановился на вещах, которые ты не упоминал. А про DOS-shell, дак лишь потому, что Фокс – такая же ДОС-программа, и если, например, DIR в командной строке выдаёт вместо "ВАСЯ.TXT" какую-нибудь "AB~1.TXT", то и Фокс будет видеть так же. А разборки начал с командной строки для того, чтобы, если есть нюансы в работе самого эмулятора, знать об этом заранее. Чтобы потом не возникала мысль, что, может, сам Фокс именно под этим эмулятором отчего-то косячит.

Crispy
Неужели для работы твоих приложений действительно нужна такая "голая работа в Дос"?
Нет. Как раз чистый ДОС не волнует, а вот вызовов win-приложений не мало. В том числе печать большинства отчётов основана на консольной win-программе. Ну то есть в моём случае это базовые вещи, поэтому крутил эту тему. Ну а раз получил какой-то результат, поделился им с общественностью.

Crispy
по доступным каталогам - доступ в самом FPD в принципе элементарно регулируется SET DEFAULT и SET PATH
Именно для программы именно под FPD вообще не вопрос. Про странности «видимости» каталогов я написал только для «накопления фактов» о странностях с кириллицей в файловой системе. Просто в своём первом докладе ты об этом не упомянул, поэтому возникла вероятность, что это что-то моё локальное (вон, на memlimit напоролся же ). К тому ж сам vDosPlus как проект начался именно с длинных имён, поэтому ожидал, что в нём этот вопрос решён во всех деталях. Вот я и стал факты выкладывать, вдруг, кто-то сходу скажет «дак это у тебя тут-то косяк» или наоборот «это же принципиальная проблема, связанная с тем-то, нечему удивляться».

Crispy
Некие 10-фоксзаповедей. Одна из которых - никогда не использовать не-английских имен.
Не спорю. Но есть частные случаи, вот навскидку. Регламент обмена данными с соцзащитой не менялся ну лет пятнадцать, только поля добавлялись и справочники. Он единый для всех городов и районов края. Там всё через dbf-файлы dBase. От жилищников выгружаются 4 файлика и как-то передаются в УСЗН. В подавляющем большинстве случаев через обычный e-mail. Понятно, что удобнее прикреплять один файл, а не четыре. Я их пакую в один архив и открываю проводник с курсором на этом архиве. Если он назван по-русски, это удобней и бухгалтершам и принимающей стороне.
И подобных всяких отчётов/выгрузок тупо не помню сколько, и если юзать этот эмулятор, придётся выискивать и менять.
Ещё раз. Я пытался по-максимуму найти возможные проблемы ещё до первого запуска Фокса, чтобы, если оно аукнется где-то при работе программы, быть к этому готовым. И выложил это здесь на случай, если кто-то с этим столкнётся.

Насчёт культуры кодирования. Ну я помню время, когда считал циклы процессора на ассемблерные команды и писал два mov вместо одного swap . Но это так, к слову. Здесь же речь шла о сравнении производительности самого Фокса под нативным ntvdm и под эмулятором vDosPlus. А не о производительности конкретных алгоритмов под Фоксом. Поэтому привёл время выполнения одной и той же реальной задачи на реальной базе. Поэтому оптимальность или корявость кода в данном случае роли не играет, главное, что он один и тот же.


BOBAN
А можно оценить скорость 2018.05.01-й версии ?
Для этого надо vDos (не Plus) ставить. Попробую поразбираться после выходных. А то у нас лето началось с озёрами, надо ловить момент



Вот ещё эксперимент, чисто «вычислительная» работа Фокса, без ДОС-вызовов. WinXP на старом AMD Athlon по 2300 МГц на ядро:



Исправлено: andrewk, 15.06.18 05:50
Ratings: 0 negative/0 positive



Извините, только зарегистрированные пользователи могут писать в этом форуме.

On-line: 41 Божья_коровка GM51  and Guests: 39


© 2000-2018 Fox Club 
Яндекс.Метрика