Какой ПБ купить?

[Димитрий]

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

опенсорс, либо честно купленный коммерческий

. Но если нет триал, то могу только посоветовать, кроме пиратского ознакомления, онлайн справку к PB (полностью повторяет поставляемый Help к продукту).

Я знаком с VB6, VBA, ПюреБейсиком и PB. Для моих задач PB (мелкие проги за пару дней, непроффесиональное программирование) наиболее оптимален.

8-9-10 Версии? Тут наверно как с выбором компьютера - если хочешь что бы работал без обновления хотя бы лет 5, то бери с запасом.

[Smitis-R]

А возвращаясь к первоначальному вопросу:
PBWIN - Создание гуевых приложений и DLL.
PBCC - Создание консольных приложений.
Т.е., это разные пакеты для разных типов приложений. В каждый пакет входит своя IDE и свой компилятор.

Брать лучше PBWIN 10 и PBCC 6, imho

[ZozBale]

Тогда ПБ мне категорически не подходит, потому что для моих целей придётся покупать и то, и другое, а это уже 370 баксов. Visual Studio Pro имеет сравнимую цену!

[Viper]

Visual Studio Pro имеет сравнимую цену!

Express версия Visual Studio вообще бесплатна.

[Dark Machine]

zozBale

может ты уже писал, но спрошу еще раз:

Какие конкретно задачи ты собираешься решать?
На Повере можно решить почти все задачи, кроме написания кернел и ринг 0 драйверов.
Консольый режим тоже можно использовать в PBWIN 10 - там есть псевдо консольный режим.

Если только для переламывания чисел, то обе версии подойдут - главное правильно поставить задачу (алгоритм), а то как и куда выводить это уже второстепенное дело. Ввод и ввывод можно сделать через файлы, СОМ интерфейс, DDE и т.д.

Ассембрел ПБ поддерживает все команды вплоть до XMM. Работать на асме в Повере очень удобно. Плюс есть без стековые процедуры, Поточные команды улучшились - вообщем инструмент реально повзрослел.

[Qwertiy]

Собственно синтаксис VB.NET в своей основе тот же, что и у синтаксиса VB 1 - VB 6.

При чём тут синтаксис?

Там не только синтаксис. Большая часть возможностей VB6 сохранилась в VB.NET, хотя есть некоторые тонкости в работе с массивами (нижняя граница всегда 0), строковые функции работают медленнее своих аналогов из класса String, попиксельный вывод не существует в таком виде (PSet).
С другой стороны, там есть и нововведения в сишном стиле - инициализация массивов в фигурных скобках, фигурные скобки у With при инициализации полей создаваемого объекта.

[Dark Machine]

Если задача чисто числодробилка, то нет смысла в использовании консоли под Винду. Вот например взламыватели паролей, работают без консоли, и математики там поуши - зато все наглядно..
Консоль в Винде - это уже рудимент. Если так приспичило консоль, тогда уж легче чистый ДОС в защищенном режиме + 64 бита проца на руках
Для численных вычислений - то что надо (за спиной ничто не крутится-вертится, весь проц твой )

[ger_kar]

На Повере можно решить почти все задачи, кроме написания кернел и ринг 0 драйверов.

1. А разве кернел и ринг 0 драйвера это не одно и то же.
2. А почему собственно нельзя? В VB6 - понятное дело это рантайм, который этого не позволит сделать, а что мешает написанию драйвера в PB? Просветите на эту тему.

[ZozBale]

Какие конкретно задачи ты собираешься решать?

Проиллюстрирую тривиальным примером. Допустим, я хочу написать программный комплекс, которая переводит температуру из одной шкалы в другую. Комплекс будет состоять из конгломерата программ: cel2far, far2cel, cel2kel, kel2cel, rea2cel, cel2rea, ran2far, far2ran, ну и так далее. Будет также основная программа, которая всё это богатство будет использовать. В частности, чтобы перевести градусы Ранкина в градусы Реомюра, будет вызвана такая цепочка:

tempReaumur = cel2rea( far2cel( ran2far(tempRankine) ) )

При этом ran2far и прочие - это не функции, и даже не библиотека, а отдельные программы, каждую из которых можно запусить как "ran2far.exe temp=40", например.

Консольый режим тоже можно использовать в PBWIN 10 - там есть псевдо консольный режим.

Это другое дело... Как я уже говорил, мне всё равно, какой именно будет интерфейс, лишь бы поменьше мороки.

Если только для переламывания чисел, то обе версии подойдут - главное правильно поставить задачу (алгоритм), а то как и куда выводить это уже второстепенное дело. Ввод и ввывод можно сделать через файлы, СОМ интерфейс, DDE и т.д.

Я уже не первый раз слышу слово СОМ и наконец-то догадался поинтересоваться, что оно означает. Раньше я не видел в этом смысла, потому что у меня было предубеждение против любых технологий, привязывающих к винде. Так вот, судя по тому, что я понял из википедии и пары статей, это и есть то, что мне нужно.

Ассембрел ПБ поддерживает все команды вплоть до XMM. Работать на асме в Повере очень удобно. Плюс есть без стековые процедуры, Поточные команды улучшились - вообщем инструмент реально повзрослел.

Это всё очень хорошо. Я даже знаю, что ассемблером там занимается Стив Хатчесон. Если Вы ещё скажете, что PB и с Фортом хорошо стыкуется - это будет счастье!

[Dark Machine]

На Повере можно решить почти все задачи, кроме написания кернел и ринг 0 драйверов.

1. А разве кернел и ринг 0 драйвера это не одно и то же.
2. А почему собственно нельзя? В VB6 - понятное дело это рантайм, который этого не позволит сделать, а что мешает написанию драйвера в PB? Просветите на эту тему.

1. Одно и тоже.
2. Кернел драйвер это почти что ДДЛ-ка, но точка входа описана по другому, навешаны определенные ограничения на сам код где адресация другая, требуется наличие ДДК, линкера и т.д. Повер не заточен для этих дел, хотя если постараться (шаманить), то можно и простенький ВДМ драйверок написать --- это так, мысли вслух.

Но вот написать спулер для принтера можно. На офф. форуме такое уже обсуждалось.

[Dark Machine]

Проиллюстрирую тривиальным примером. Допустим, я хочу написать программный комплекс, которая переводит температуру из одной шкалы в другую. Комплекс будет состоять из конгломерата программ: cel2far, far2cel, cel2kel, kel2cel, rea2cel, cel2rea, ran2far, far2ran, ну и так далее. Будет также основная программа, которая всё это богатство будет использовать. В частности, чтобы перевести градусы Ранкина в градусы Реомюра, будет вызвана такая цепочка:

tempReaumur = cel2rea( far2cel( ran2far(tempRankine) ) )

При этом ran2far и прочие - это не функции, и даже не библиотека, а отдельные программы, каждую из которых можно запусить как "ran2far.exe temp=40", например.

Если ran2far и прочие выполняют только перевод, т.е. чистая математика, то я решение вижу след. образом.
1. "Конгломерат" процедур для вычислений вынести в отдельную ДДЛ-ку (можно и СОМ ДДЛ-ку). Для каждого конгломерата создать свой ДДЛ.
Например - все переводы температурных величин в один ДДЛ, мат. обработка вектров - в другую --- ну тут все ясно. Причем организовать многопоточную обработку
для функций.
2. Я не вижу смысла плодить ЕХЕ файлы для каждой процедуры. Вместо этого лучше использовать основную программу, которая и будет вызывать те ф-ции, которые необходимы в данный момент, и организовать все это в отдельных потоках. Так, основная программа может работать и предостовлять ГУИ интерфейс и также можно запустить в отдельном потоке для обработки "конгломератов"

main.exe - запустить основную программу. Ну там ГУИ и т.п.
main.exe /f=cel2far /t=40 /of=c:\Stuff\resfar.txt - запустить ф-цию и записать результат в файл resfar.txt
main.exe /f=ran2far /t=50 /ow=04563878 - запустить ф-цию и передать результат в хендл окна
main.exe /f=ran2far /t=30 /oh=102020 - запустить ф-цию и передать результат в хендл файла
main.exe /f=far2ran /t=20 /oc="COMObject.GetValue" -запустить ф-цию и передать результат в СОМ объект

все это можно сделать на ПБ
примерно будет выглядеть так

Код: Выделить всё

TYPE TFCall
  mFunc AS ASCIIZ * 64
  lTemp AS SINGLE
  outDev AS ASCIIZ * 256
END TYPE

THREAD FUNCTION konglomerat ( BYVAL V AS DWORD ) AS LONG
    '...
END FUNCTION

FUNCTION PBMAIN () AS LONG
    LOCAL C1,C2,C3,funcName,temp,outMethod AS STRING
    LOCAL hThread AS DWORD, S AS LONG
    IF LEN(COMMAND$) THEN
       C1=LCASE$(COMMAND$(1)):C2=LCASE$(COMMAND$(2)):C3=LCASE$(COMMAND$(3))
       IF LEFT$(C1,3)="/f=" THEN funcName = REMAIN$(c1,"/f=")
       IF LEFT$(C2,3)="/t=" THEN temp = REMAIN$(c2,"/t=")
       IF LEFT$(C3,2)="/o"  THEN outMethod = REMAIN$(c3,"/o")

       IF LEN(funcName) AND LEN(temp) AND LEN(outMethod) THEN
          DIM U AS GLOBAL TFCall
          U.mFunc = funcName
          U.lTemp = VAL(Temp)
          U.outDev = outMethod
          THREAD CREATE konglomerat (VARPTR(U)) TO hThread
          DO
            THREAD STATUS hThread TO s
            IF s = 0 THEN
               THREAD CLOSE hTread
               EXIT DO
            END IF
          LOOP
       END IF
    END IF
END FUNCTION


[Dark Machine]

На Повере можно решить почти все задачи, кроме написания кернел и ринг 0 драйверов.

2. А почему собственно нельзя? В VB6 - понятное дело это рантайм, который этого не позволит сделать, а что мешает написанию драйвера в PB? Просветите на эту тему.

Думаю будет интересно посмотреть на этот код..
Virtual Device Driver Template for PBDLLhttp://www.powerbasic.com/support/pbforums/showthread.php?t=23423&highlight=driver

[Viper]

Проиллюстрирую тривиальным примером. Допустим, я хочу написать программный комплекс, которая переводит температуру из одной шкалы в другую. Комплекс будет состоять из конгломерата программ: cel2far, far2cel, cel2kel, kel2cel, rea2cel, cel2rea, ran2far, far2ran, ну и так далее. Будет также основная программа, которая всё это богатство будет использовать. В частности, чтобы перевести градусы Ранкина в градусы Реомюра, будет вызвана такая цепочка:tempReaumur = cel2rea( far2cel( ran2far(tempRankine) ) )При этом ran2far и прочие - это не функции, и даже не библиотека, а отдельные программы, каждую из которых можно запусить как "ran2far.exe temp=40", например.

А чем оправдывается такая мудреная реализация?

[ZozBale]

А чем оправдывается такая мудреная реализация?

Клинической неспособностью писать большие, сложные программы. Мне проще наплодить кучу маленьких монофункциональных утилит. А потом связать их. Тот же принцип, что и в UNIX. Только там программы связываются по принципу трубопровода - вывод одной подаётся на вход другой. А мне нужно в стиле клиент-сервер.

[Viper]

Только там программы связываются по принципу трубопровода - вывод одной подаётся на вход другой. А мне нужно в стиле клиент-сервер.

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

[Хакер]

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

Ты пропустил его слова о Unix-подходе.

[ZozBale]

Ты пропустил его слова о Unix-подходе.

Я не настаиваю именно на этом подходе. Это всего лишь пример удобного для меня подхода. Ещё удобнее было бы устроить что-то вроде двунаправленных каналов между программами. Или нечто вроде клипбоарда, но видимого лишь некоторыми приложениями. Я даже всерьёз думал над тем, чтобы обмениваться данными через временные файлы. Если расположить их на рамдрайве, то это будет практически то же самое, что обмениваться напрямую. Единственная загвоздка - нужно очень тщательно продумать порядок доступа к файлам, чтобы одна прога не пыталась читать их до того, как другая обновила, а третья не запихнула в файл обновлённые данные раньше времени и так далее. Может быть, существует уже готовая библиотека для таких (или хотя бы отдалённо похожих) вещей? Не хочу использовать полноценную клиент-серверную архитектуру поверх TCP/IP, потому что это уж слишком высокий уровень абстракции. Моя прога не распределённая.

[Sam777e]

Почтовый слот, Pipe . . .

[ZozBale]

Почтовый слот, Pipe . . .

Спасибо. Действительно, это оказалось то, что нужно. Особенно named pipes. В каких языках проще и удобнее с ними работать? (шёпотом: не обязательно Бейсик).

[DarkMachine]

СОМ, named pipes - для динамичных приложений, а что если одно приложение завершается и запускается другая?
Есть еще вариант обмена данными - это РЕЕСТР --- один из надежных способов обмена сообщениями, причем можно организовать слоты данных для "конгломерата".

Работа с реестров на ПБ широко описана, вообще информации на эту тему много.

А если серверная часть приложения всегда работает, то СОМ - наплохой вариант.

[Sam777e]

недолгий поиск по НАШЕМУ форуму и там пост

http://bbs.vbstreets.ru/viewtopic.php?f=7&t=38265

а внутри него

http://forum.sources.ru/index.php?showtopic=168882

. . .

[ZozBale]

СОМ, named pipes - для динамичных приложений, а что если одно приложение завершается и запускается другая?

Нет, в моей ситуации это невозможно. Когда одно завершается - значит, и в другом отпала необходимость.

Есть еще вариант обмена данными - это РЕЕСТР --- один из надежных способов обмена сообщениями, причем можно организовать слоты данных для "конгломерата".

А вот это мысль! Я тут погуглил и пришёл к выводу, что удобных и красивых средств работы с named pipes нет ни в одном языке, который мне хотя бы "шапочно" знаком. А вот для реестра наверняка есть удобные костыли, обёртки и прочее в том же роде. Вот в OS/2, например, было совсем просто - создаёшь файл в каталоге \PIPE\ (существующем только в воображении ОС) - и всё! Эх, мечты... Я правильно понимаю, что в Windows надо просто создать ветку в определённой части реестра?

Работа с реестров на ПБ широко описана, вообще информации на эту тему много.

Поищу. Главное - чтобы это были стандартные, надёжные, удобные, простые, лаконичные средства. Пусть в ущерб скорости и функциональности. Данных будет мало.

А если серверная часть приложения всегда работает, то СОМ - наплохой вариант.

Как я уже говорил, всегда будут работать и серверная, и клиентская части. Но в СОМе смысла не вижу - слишком муторно и ресурсозатратно, а преимуществ нет.

[DarkMachine]

Базовый набор работы с реестром http://bbs.vbstreets.ru/viewtopic.php?f=23&t=43799
Есть почти все...

[DarkMachine]

Я правильно понимаю, что в Windows надо просто создать ветку в определённой части реестра?

Вот сюда можно (ветки на русском - это уже от твоей программы)

\HKEY_LOCAL_MACHINE\SOFTWARE\МояСистема\ОбщийКаналСообщений\Температура
\HKEY_LOCAL_MACHINE\SOFTWARE\МояСистема\ОбщийКаналСообщений\Векторы

и т.д.

[Qwertiy]

Вот в OS/2, например, было совсем просто - создаёшь файл в каталоге \PIPE\ (существующем только в воображении ОС) - и всё! Эх, мечты...

В .NET работа с реестром сделана так же, как с файловой системой Всё что угодно можно сделать в одну или две команды.

[Qwertiy]

Только там программы связываются по принципу трубопровода - вывод одной подаётся на вход другой.

А что мешает сделать так в Windows? Решается же простым перенаправлением ввода-вывода

[ZozBale]

Я правильно понимаю, что в Windows надо просто создать ветку в определённой части реестра?

Вот сюда можно (ветки на русском - это уже от твоей программы)

\HKEY_LOCAL_MACHINE\SOFTWARE\МояСистема\ОбщийКаналСообщений\Температура
\HKEY_LOCAL_MACHINE\SOFTWARE\МояСистема\ОбщийКаналСообщений\Векторы

и т.д.

Я имел в виду совсем другое. Эта ветка используется, например, для сохранения конфигурации программы. Соответственно, сохраняется на диск. А мне нужно, чтобы данные кратковременно существовали только в памяти, пока их не прочитает программа-получатель. Я где-то слышал, что некоторые части реестра - виртуальные. Я полагал, что речь идёт о чём-то подобном. То есть в реестре есть спец-ветка, через которую можно вот так общаться. А на диск я писать не хочу...

[DarkMachine]

т.к. винда интенсивно использует виртуальную памать, то полагаю что избежать чтения с диска неудастся. тот же реестр (некоторая часть все же находится в памяти и кешируется) не всегда в памяти,а на виртуальном диске. Об этом беспокоится и думать нестоит.
Какая ожидается примерная частота межпрограмного общения? От этого возможно будет зависеть метод, которую надо подобрать для твоей задачи.