Чем отличается HB2 от HB1.1?

Форум » [x]Harbour » Чем отличается HB2 от HB1.1? » Ответить

Чем отличается HB2 от HB1.1?

wad1: Здравствуйте всем! Скачал HARBOUR2.0. Настроил пути и собрал проект. Исполняемый модуль увеличился. А что еще хорошего следует ожидать от замены компилятора? Спасибо за ответы!

Ответов - 35, стр: 1 2 All

PSP: http://www.harbour-project.org/news.html

wad1: Это я конечно видел. Но понимается с трудом (и дело не только в незнании английского). Хотелось бы по-русски узнать - кто какие преимущества реально ощутил после перехода на 2.0

PSP: Интересный вопрос... :) Мне думается, что каждый сам может выяснить, глядя на список изменений и дополнений, есть какие-либо преимущества лично для него или нет. Проект развивается - это главное "преимущество", имхо. :)

sergey5703: Выскажу сугубо личное мнение. Вот у меня на домашнем компьютере нет принтера, в Windows установлен принтер "Generic / Text Only" для которого указан порт вывода - файл на диске. И СКОЛЬКО HARBOUR-ОВ Я НЕ ПЕРЕПРОБОВАЛ - НИ ОДИН НЕ ХОЧЕТ В НЕГО ПЕЧАТАТЬ! А с xHarbour - легко и приятно иметь дело. Меня не интересует кросс-платформенность и GNU C++, и Linux я осваивать не собираюсь (вместе с Unix-ом). ИМХО!

PSP: sergey5703 пишет: в Windows установлен принтер "Generic / Text Only" для которого указан порт вывода - файл на диске. И СКОЛЬКО HARBOUR-ОВ Я НЕ ПЕРЕПРОБОВАЛ - НИ ОДИН НЕ ХОЧЕТ В НЕГО ПЕЧАТАТЬ! Только что попробывал. Нормально работает. Единственный момент: если написать следующий код SET PRINTER TO ( Win_PrinterGetDefault() ), то имя принтера по-умолчанию должно быть пригодным для создания файла ИмяПринтера.prn В нашем случае имя принтера - "Generic / Text Only". Думаю, не стоит объяснять, почему система не сможет создать файл с именем "Generic / Text Only.prn"... :) Можно просто установить принтер "Generic / Text Only" по-умолчанию и написать: SET PRINTER TO ( "SpoolFile" ) и получим файл "SpoolFile.prn"

wad1: Хочется услышать сравнительные характеристики по скорости, надежности и прочее. Например Harbour намного превосходит Clipper при сложных заданиях на локальной машине при работе одним пользователем. В сети при нескольких работающих станциях преимущество практически незаметно. А как с H2? И еще. В примерах поставки H2 есть пример терминального протокола. Кто-нибудь пробовал? Как я понял, для применения терминального доступа нужно несколько модифицировать свое приложение и запускать его на сервере. Кроме того, запустить там же терминальный сервер, а на рабочей станции - клиент. После этого приложение будет выполняться на сервере, а на клиент будут посылаться экраны, обратно - нажатия клавиш (может и мышь?). С печатью вроде бы не все гладко. Очень заманчивая вещь для многопользовательских систем. Может организуем клуб "терминальщиков"? Сообща веселее.

Pasha: Имеется в виду examples\terminal ? Я запускал этот пример по локальной сети, нажатие клавиш отрабатываеися с задержкой. Почему - не разбирался. Что касается удаленной печати, то ее можно сделать таким образом. Разработать класс RemotePrint. Обьект этого класса создается на терминальном сервере приложением вместо объекта класса Win_Prn В обработчике ERROR HANDLER на клиент должны передаваться имя метода с параметрами. На клиенте при этом будет создаваться уже обьект класса Win_Prn, выполняться его методы, и обратно возвращаться результат. Обработчик ERROR HANDLER на сервере вернет результат приложению. Такой же механизм можно использовать для работы и с дугими классами. Собственно можно сделать один подобный класс вида: CREATE CLASS TrmRemote DATA ServerClass DATA socket DATA handle METHOD New( cClass ) CONSTRUCTOR ERROR HANDLER OnError() ENDCLASS

wad1: Да, речь именно об этом. Прежде чем вкладывать в эту штуку время и другие ресурсы, хотелось бы узнать мнение гуру: это реальная вещь или игрушка, от которой до настоящей терминал-серверной работы - вечность?

Петр: wad1 пишет: это реальная вещь или игрушка, от которой до настоящей терминал-серверной работы - вечность? Это реальный пример и не более того. Вы можете его улучшить (или ухудшить ). Написание этого примера стало возможным благодаря использованию новых возможностей hb 2.0 (МТ, socket etc.) В ближайшем будущем Пржемек пообещал вернуться к работе над GTNET - "..Anyhow I plan to work on GTNET in the nearest future..", так что пожелаем ему удачи, себе терпения . Хочется услышать сравнительные характеристики по скорости, надежности и прочее. Ну, наверное, для такого сравнения надо специальные тесты писать. Естественно я этого не делал. Более того, я использую не официальные выпуски, а делаю регулярно свои сборки, поэтому четко определить разницу между 1.0 и 2.0 не могу Теоретически (и практически) за последний год-полтора Harbour стал быстрее, и способствовало этому два фактора - использование собственного менеджера памяти на базе dlmalloc и компилирование HVM в виде единого файла (hvmall.c), что позволяет С компиляторам проводить более глубокую оптимизацию генерируемого кода. Само собой разумеется скорость зависит от выбраной модели ST или MT, cкорость также зависит от того какой С компилятор вы используете. У меня два фаворита MSVC и MinGW. С MSVC можно использовать еще один альтернативный менеджер памяти hoard. Теперь о надежности, в hb 2.0 были исправлены некоторые ошибки и другие потенциально опасные вещи, могущие привести к RTE или GPF. Прежде чем вкладывать в эту штуку время и другие ресурсы Рекомендую потратить время на изучение новых возможностей hb 2.0, hbnetio, hbmemio. А к идее терминала вернуться чуть позже, после реализации GTNET.

Andrey: Петр пишет: изучение новых возможностей hb 2.0, hbnetio, hbmemio А что это такое ? Хоть несколько строк, чтоб понять....

Петр: Andrey, вы же пользуетесь xHarbour, зачем вам это нужно? В терминологии xHb hbmemio - это filemem, hbnetio - что-то вроде hbfilere, но покруче, поскольку кроме операций RDD позволяет также исполнение RPC.

Andrey: Петр пишет: вы же пользуетесь xHarbour, зачем вам это нужно? Я же не век сидеть буду на хХарборе.... Тем более все пишут, что Харбор быстрей.... А быстродействие своих программ я тоже хочу поднять... Тем более нужно стремиться к новому ! Петр пишет: В терминологии xHb hbmemio - это filemem, hbnetio - что-то вроде hbfilere, но покруче, поскольку кроме операций RDD позволяет также исполнение RPC. А по русски можно ? Ну не все такие разбирающиеся в технологиях .....

wad1: Похоже, что с помощью hbmemio можно создавать таблицы (в виде DBF) в памяти, индексировать их, обрабатывать, и все это без записи на диск. Скорость обработки видимо должна существенно возрасти, если памяти достаточно. Однако сможет ли другое приложение увидеть такую таблицу? Частенько временные таблицы создаются для передачи их, например, внешнему генератору отчетов.

PSP: Про hbnetio (чтобы исключить неточности, цитирую из ChangeLog) 2009-09-01 00:56 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) ............................................................................................................ + added new library: HBNETIO. It implements alternative RDD IO API which uses own TCP/IP sockets to exchange data between client and server. This library contains client and server code and is fully MT safe. On client side it's enough to execute: NETIO_CONNECT( [<cServer>], [<cPort>], [<nTimeOut>] ) -> <lOK> function to register alternative NETIO RDD API and set default server address and port. <cServer> - server addres (default 127.0.0.1) <cPort> - server port (default 2941) <nTimeOut> - connection timeout (default -1 - not timeout) Above settings are thread local and parameters of the 1-st successful connection are used as default values for each new thread. After registering NETIO client by above function each file starting "net:" prefix is automatically redirected to given NETIO server, i.e. use "net:mytable" It's also possible to pass NETIO server and port as part of file name, i.e.: use "net:192.168.0.1:10005:mytable" On the server side the following functions are available: create NETIO listen socket: NETIO_LISTEN( [<nPort>], [<cAddress>], [<cRootDir>] ) -> <pListenSocket> | NIL accept new connection on NETIO listen socket: NETIO_ACCEPT( <pListenSocket> [, <nTimeOut>] ) -> <pConnectionSocket> | NIL start connection server: NETIO_SERVER( <pConnectionSocket> ) -> NIL stop connection accepting or connection server: NETIO_SERVERSTOP( <pListenSocket> | <pConnectionSocket>, <lStop> ) -> NIL activate MT NETIO server (it needs MT HVM): NETIO_MTSERVER( [<nPort>], [<cAddress>] ) -> <pListenSocket> | NIL To create NETIO server is enough to compile and link with MT HVM this code: proc main() local pListenSocket pListenSocket := netio_mtserver() if empty( pListenSocket ) ? "Cannot start server." else wait "Press any key to stop NETIO server." netio_serverstop( pListenSocket ) pListenSocket := NIL endif return NETIO works with all core RDDs (DBF, DBFFPT, DBFBLOB, DBFNTX, DBFCDX, DBFNSX, SDF, DELIM) and any other RDD which inherits from above or use standard RDD IO API (hb_file*() functions). Without touching even single line in RDD code it gives the same functionality as REDBFCDX in xHarbour but for all RDDs. It's possible that such direct TCP/IP connection is faster then file server protocols especially if they need more then one IP frame to exchange data so it's one of the reason to use it in such cases. Please make real speed tests. The second reason to use NETIO server is resolving problem with concurrent access to the same files using Harbour applications compiled for different platforms, i.e. DOS, LINUX, Windows and OS2. It's very hard to configure all client stations to use correct locking system. NETIO fully resolves this problem so it can be interesting alternative also for MS-Windows users only if they do not want to play with oplocks setting on each station. I'm interesting in user opinions about real life NETIO usage.

Andrey: PSP пишет: Про hbnetio Это чтож получается, как у "alkresin" - драйвер LetoDB ? А кто реально пробовал эти штуки ? Ваши впечатления, господа ?

Pasha: Нет, это не клиент-сервер. При использовании netio доступ к файлам выполняется не через файловые операции: open, read и пр, а с помощью передачи данных по ip протоколу.

Петр: Да это не клиент-сервер, как пишет автор, это альтернативное RDD IO API, использующее свой очень простой TCP/IP файл сервер. Но, в версии 2.0.1 в HBNETIO протокол была добавлена поддержка RPC (удаленного вызова процедур). К примеру ? netio_funcexec( "upper", "hello world !!!" ) // Естественно такая функция должна существовать на стороне сервера. Что можно делать с таким комбинированным сервером, это уже сам программист должен решать. Но то, что это очень и очень расширяет возможности - это факт.

sergey5703: Не знаю, может я что то путаю, но мне кажется, что NETIO очень сильно смахивает на заготовку ядра будущего Харборовского SQL-сервера (пока без языка запросов и всего прочего). В тексте, процитированным PSP разработчик Przemyslaw Czerpak просит "Пожалуйста сделайте реальные тесты скорости", а также пишет: "Я интересуюсь пользовательскими мнениями о реальном использовании NETIO".

wad1: Вопрос: в случае применения NETIO нужно давать пользователю полные права на каталог с данными? Хочется надеяться, что нет. Однако как быть с источниками данных, не являющимися DBF-таблицами: INI-файлы, бланки отчетов и т.д.? Еще вопрос: если клиентов много, то сервер должен запускаться только один? А скольких клиентов он потянет? И последний (в этот раз): Смогут ли параллельно с сервером работать с этими же файлами сторонние подсистемы с корректным применением блокировок и корректировкой индексов?

Петр: в случае применения NETIO нужно давать пользователю полные права на каталог с данными нет Однако как быть с источниками данных, не являющимися DBF-таблицами: INI-файлы, бланки отчетов и т.д.? RPC, пока если клиентов много, то сервер должен запускаться только один? С технической стороны таких ограничений нет, вы можете запустить несколько сервером на одном компе используя разные порты, или несколько серверов в сети, создать вычислительный кластер А скольких клиентов он потянет? Попробуете, поделитесь информацией Смогут ли параллельно с сервером работать с этими же файлами сторонние подсистемы с корректным применением блокировок и корректировкой индексов? Что вы имеете ввиду под "сторонние подсистемы", если это приложения написанные на harbour - да.

wad1: Петр пишет: Что вы имеете ввиду под "сторонние подсистемы" Сейчас с одними и теми же DBF-таблицами работает Clipper/Harbour программа "Расчет зарплаты", а также Delphy/Apollo модули "Учет кадров" и "Табельный учет". Если "Зарплата" подключится через NETIO, то "Кадры" смогут обращаться к этим файлам напрямую? И еще: подключив NETIO можно открывать файлы только через него, или с локальными таблицами можно будет работать как раньше?

Петр: то "Кадры" смогут обращаться к этим файлам напрямую? Смогут, но, чувствую, когда нибудь вы нарветесь на бяку в виде несовместимых блокировок/index corruption

wad1: Петр пишет: нарветесь на бяку в виде несовместимых блокировок/index corruption Вы это именно применительно к NETIO? Связка Clipper (а затем Harbour) - Apollo работает с 2001 года у десятков клиентов. Если бы несовместимость блокировок/индексов была, то уже давно прорезалась бы.

wad1: Господа, подскажите пожалуйста, как организовать компиляцию С-модулей с помощью MINGW. С BCC5 у меня формируется файл BUILD.TMP с перечнем С-модулей и библиотек, а затем вызывается "BCC32 @BUILD.TMP >>log.txt". MINGV скачал с поставкой Harbour, а как вызвать компилятор - непонятно.

Zakrzevky: перескочил c Harbour 1.6.69 на hb2.0. Работает не медленнее чем с предыдущей версией, но с ADS выдает ошибку 'типа нет AdsSeekUnique() ' при компиляции в rddads. в 1.6.69 работал с готовыми библиотеками ace32.lib и rddads.lib с купленной ADS8.0. Понятно, что их надо как-то пересобирать. В поставке hb20\lib\win\bcc есть свой rddads.lib (повидимому к 9-й версии). Достаточно ли к нему в парочку из асе32.dll сделать ace32.lib или rddads.lib тоже нужен другой? Может есть готовый комплект на hb20 для ADS например версии 9.

Pasha: rddads не использует функцию AdsSeekUnique, ее нет и в ace9, так что ситуация непонятна. Какая точно ошибка выдается при сборке ? Лучше конечно пересоберите сами rddads, и сделайте ace32.lib из ace32.dll от 8-й версии.

Zakrzevky: Pasha пишет: пересоберите сами rddads Cпасибо!. я взял текущую rddads (она была c:\hb20) точно 9.10 ADS (понятно даже по контексту при просмотре в FAR-е по F3) . ADS 9.10 у меня была левая. Я ее использовал в приложениях CA-VISUAL OBJECTS 2.5 - 2.8. Из Ace32.dll получил lib, как доктор прописал. adsloc32.dll опять же взял с девятки, прикрученной тоже к проекту на CAVO. Все состыковалось и заработало! Остался вопрос с клиентами у которых легально купленный ADS 8.0. Все Есть, надо только пересобрать rddads.lib на harbour2.0. Опыта сборки "либов из сырцов харбора" пока не имею, думаю что разберусь или кто подскажет. P.S. Pasha пишет: А что еще хорошего следует ожидать от замены компилятора? В дополнении к теме не могу не согласится с ответом, что главное ... есть движение вперед, и харборовцы не "спят в оглоблях". И о сожалениях! Жаль, что столько потрачено сил (и не только, а денег... )на программирование в CAVO. Столько времени было отдано переводу проектов с Clipper на CA-VISUAL. Некогда передовой CA стал отставать в своей поддержке и "любви к своим useram" даже от АЛЯСКИ. Последний SP3 для CAVO2.8 стал последней каплей переполнившей чашу - за исправления собственных ошибок официальные разработчики grafxSoft (купившей CA) уже просят деньги. Для справки CAVO 2.5 - куплен официально (в Москве) CAVO 2.8 - куплен официально (в Германии) +Bbrowse SP2 хуже SP1, SP3 - уже платно для официально купивших продукт и не купить даже через счета в Европе. (может лень деньги получать). Достучатся до разработчиков хуже чем до небес. Форум кавистов пустует почти полгода, а если кто и пишет, то о том мол хаборовцы опять новые релизы выложили. Да будет Harbour и ваш форум!

Pasha: Zakrzevky пишет: Все Есть, надо только пересобрать rddads.lib на harbour2.0. Опыта сборки "либов из сырцов харбора" пока не имею, думаю что разберусь или кто подскажет. rddads - это всего лишь библиотека, состоящая из 4-х сишных модулей: ads1.c adsfunc.c adsmgmnt.c adsx.c Так что можете не заморачиваться с makefile, а просто написать батник вида: компиляция каждого модуля компилятором bcc32 со стандартными флагами для харбора, и затем вызов tlib для добавления модуля в библиотеку.

Zakrzevky: Все так посто!

Петр: Zakrzevky пишет: Все так посто! все еще проще, поместите в папку с rddads такой bat файл и запустите [pre2]@echo off set PATH=h:\borland\bcc55\bin set HB_COMPILER=bcc set HB_WITH_ADS=e:\ace\9.10\acesdk ..\..\win-make install -j2 [/pre2] Здесь имеется ввиду, что вы используете стандартную структуру каталогов и компилятор bcc

Pasha: Zakrzevky пишет: И о сожалениях! Я году так в 2002-2003-м, когда переход на 32-х разрядную платформу уже ой как назрел, интересовался CAVO. Но тут вовремя подвернулся харбор, и я "набросился" на него. С тех пор сожалею только о том, что не начал заниматься харбором на несколько лет раньше. Надо было присоединяться к проекту с самого начала.

Andrey: Pasha пишет: С тех пор сожалею только о том, что не начал заниматься харбором на несколько лет раньше. Надо было присоединяться к проекту с самого начала. И я тоже очень жалею. Что целый год "убил" на Аляску....

Pasha: В раннем харборе отпугивал медленный gtwin под win98 и недоработанный dbfcdx. В дальнейшем эти вопросы были закрыты.

sergey5703: Вот интересно, наступит наконец-то такое время когда в Харборах не останется никаких глюков. Вы застали недоработанный DBFCDX, а я в старых Харборах (0.43.x и 0.99.x) пытался использовать DBFNTX (по Клипперовской привычке), и наслаждался незабываемыми ощущениями - от неправильно работающих функций BOF() и EOF() до GPF-ов. Да если бы Alaska xBase++ с Clipper Tools для нее были бы бесплатными с исходниками да под бесплатный BCC 5.5 - лучшего и пожелать нельзя было бы.

Andrey: sergey5703 пишет: а если бы Alaska xBase++ с Clipper Tools для нее были бы бесплатными с исходниками Отстой... Целый год промучился с ихнем переходом на их объекты. Под Харбором все понятней и компактней получается... На Аляске мой проект весил 12 Мб + еще DLL-аляски нужны еще 5-7 Мб. На Харборе мой проект весит 3,5 Мб и все... И что быстрей будет выполнятся ? Это еще при том что драйвер работы с базой нужно загружать отделной DLL-кой.... ... какой то...

полная версия страницы