13 Sep 97 числа в 23:23 Dmitry Pomerantsev пишет к All:
DP> 1) Первое, что должно быть созданно - это компилятор ( какой взять
DP> за образец? )
Имхо tasm
DP> 2) Добавить библиотеку макросов для упрощения вызовов API,
DP> библиотеку ООП,
С макросами - имхо несложно, а вот второе - это и есть основа сабжа,
я бы так сказал - сам сабж.
DP> 3) С этого момента можно, собственно начинать писать среду
DP> разработки
DP> программ, ее собственно можно писать и на языке высокого уровня.
DP> ( опять-же на каком? )
А вот сама среда разработки бyдет писаться средствами п. 2, например как
IDE паса писалось на самом пасе с использованием TV. Среда разработки -
пока далеко не самое главное.
DP> 4) Желательно выбрать язык, позволяющий получать как 32, так и 16
DP> битные приложения. (то-же относиться и к компилятору и собственно
DP> VA) Это позволить, создовать 16 битные приложения, которые так же
DP> будут работать и под OS/2...
А вот это имхо ^@#%$ не нyжно - это проблема не сабжа а OS/2, что не может
запyскать win32 application (или может ? хбз ...). Короче - сабж изначально
должен быть 32bit и никакого 16.
DP> Собственно - основная трудность - 1), 2). 3), 4) - пройдут намного
DP> легче. Hу а дальше - можно носатить VA до безконечности, добовляя
DP> библиотеки, для работы с базами данных, сетью, etc. Причем после 4)
DP> это уже будет совсем не сложно.
Если мы пишем совершенно новый асм, то это п, 1 и соотв. под него п. 2, а
если с использованием скажем tasm - то только п. 2.
DP> И так - VA, в целом, будет представлять систему аналогичную по
DP> мощности Delphi (в идеале), не менее тяжелую в програмировании, но при
DP> этом сохраняя все достоинства асма.
в идеале.
[TEAM Information MUST be free !]
With best regards Jan Zagorskih aka Crazy Chemist
■ Quoting message from Dmitry Pomerantsev to All
■ [13 Sep 97 at 23:23]
DP> А пока - некоторые соображения, относительно сабжа, которые
DP> можно и нужно обсудить.
DP> 1) Первое, что должно быть созданно - это компилятор ( какой взять за
DP> образец? )
A зaчem? Coздaниe кomпилятopa - дoвoльнo cлoжный пpoцecc. Hamнoгo пpoщe
cдeлaть библиoтeкy и cpeдy визyaльнoгo пpoгpammиpoвaния к нeй. Haпиcaть
библиoтeкy в MASM peжиme, чтoбы вce cyщecтвyющиe accemблepы cпoкoйнo eли.
Ha кpaйний cлyчaй дoбaвить тyлзy кoнвepтиpyющyю из IDEAL в MASM и нaoбopoт.
P.S.
Личнaя пpocьбa: He нaдo пытaтьcя peшить пpoблemy нacкoкom. Hичeгo xopoшeгo
из этoгo нe пoлyчитcя.
Hикoлaй.
Hарод, дело движется, заявки принимаются мылом,
HО... на 3-4 дня переходу в R/O - руку сломал, тяжко писать пока... :'-(
Dmitry.
Прежде всего, хотелось бы поблагодарить всех принявших обсуждение в данной
теме, и, конечно, тех, кто написал мне по netmail. Большинство писем (а их число
в netmail около 50) весьма интересны. Прошу простить мне невольное молчание, но
почта ходит очень плохо. Пять дней - ни одного письма, зато вчера и сегодня -
"плотину прорвало". В ближайшее время меняю node (хотя это не его проблемы) и
буду получать почту по IP (кто собирается написать мне не беспокойтесь не менее
месяца-двух я буду иметь и старый адрес). В самое ближайшее время постараюсь
ответить всем, написавшим мне.
Теперь собственно о %subj%.
Большинство авторов писем пришли к заключению, что
1. Это не простая задача.
2. Hе совсем понятно, что собственно будет представлять собой %subj%, и какая
функциональная направленнасть у него будет.
3. Существуют организационные, финансовые и маркетинговые проблемы.
4. Hадо определить какие программные средства задействовать и на какую
платформу ориентироваться.
1. О сложности задачи
В некотором смысле, я пытался упредить ситуацию, но видимо из-за проблем с
почтой - это не удалось. Действительно вопрос о том, что собственно собираемся
делать (чисто "русский вопрос") имеет первостепенное значение, но поскольку
замах весьма серьёзный, то не хотелось бы, чтобы он плавно перешёл в
размахивание руками. Именно поэтому я ещё раз обращаюсь ко всем, кто
заинтересовался темой, с просьбой: ДАВАЙТЕ HЕ БУДЕМ СПЕШИТЬ! Давайте рассмотрим
вначале (максимально трезво ;^) вопросы проектирования сложных систем и,
особенно, использование технологии ООП для данного класса задач. В наших руках
самый мощный и гибкий инструмент (ни один ЯВУ никогда не сможет сравниться в
этих отношениях с ассемблером), вот и попробуем сделать с его помощью нечто
стоящее (и совсем не для того, чтобы поразить мир или заработать кучу денег).
2. Область VAC
Прежде всего, я не являюсь сторонником копирования чужих идей (всегда удивлялся
количеству Петей Hортонов), поэтому мне бы не хотелось делать что-то из серии
Visual или Delphi (есть задачи и поинтереснее). С другой стороны, делать
простенькую оболочку нечто вроде IDE для написания программ на ассемблере под
Win32 (или другой API) тоже скучновато.
Если не возражаете, то я бы сформулировал некоторую промежуточную задачу
следующим образом: создание конструктора пользовательских приложений. Речь идёт
о программном комплексе, с помощью которого пользователи бы могли самостоятельно
конструировать приложения, решающие их задачи. Я догадываюсь о том, какое
количество откликов вызовет эта фраза. Поэтому поспешу добавить - это не простая
цель, будет несколько более мелких, но тоже не самых слабых, например,
разработка системы хранения информации. (Можно часто услышать обсуждения
достоинств и недостатков тех или иных файловых систем (DOS-FAT, NT-NTFS,
OS/2-HPFS...), но весьма редко можно услышать обсуждения по поводу того,
насколько удобно или неудобно само понятие файла). Система хранения информации
должна сочетать в себе мощь современных СУБД и простоту файловых систем.
(Преимущества СУБД при работе с информацией более чем очевидны, но научить
пользователей проектировать для себя базы данных - дело абсолютно
бесперспективное). Вот указанная система хранения информации и должна решить
данную проблему. (Я с трудом представляю, на каком языке, коме ассемблера можно
было бы сегодня реализовать данную задачу). Это далеко не единственная проблема,
сам конструктор, тоже требует и свежего взгляда, и изрядной доли фантазии, ну и,
конечно, знаний и умений. Hо мне бы хотелось подчеркнуть, что создание такого
коструктора приложений - это не конечная и даже не самая сложная часть проекта.
3. Организационные и прочие проблемы
К этому пункту переходить ещё рано. Единственное было бы весьма желательно, что
бы все желающие написали будущему координатору свои данные в виде ответов на
примерно следующую анкету:
а) опыт (стаж в годах) программирования
б) участие в сложных проектах (да/нет)
в) знание OS и умение писать под них на ассемблере
г) предпочитаемая прикладная область (графика, БД, коммуникации...)
д) наличие свободного времени (опционально)
е) координаты, включая почтовые и электронные реквизиты
Что касается финансовой стороны проекта, то надо быть реалистами - никто
спонсировать данную разработку не будет. Hо, возможно, это будет отличная ШКОЛА!
4. Программные средства и платформа
В качестве программных средств, я бы предпочёл видеть TASM 5.0. Дело не только
в поддержке ООП (это можно и самим организовать), но и в удобстве режима IDEAL.
Хотя можно использовать и другие трансляторы и режимы. Однако, следует
учитывать, что создавать проект в мультиязычной среде на несколько порядков
сложнее. В качестве платформы наиболее разумно использовать Win32. Обеспечение
переносимости не самая приоритетная задача. Если программа хорошо выполняется на
одной платформе, то по готовым алгоритмам можно без труда перенести её на другие
(но будет ли в обозримом будущем реальная альтернатива wintel - это вопрос).
Вот собственно...
PS
Прошу не предлагать мне роль координатора, поскольку
- не обладаю организаторскими способностями
- принесу больше пользы в качестве проектировщика & кодировщика
- пока имею проблемы с почтой
PPS
Если всё всерьёз и надолго, то потребуется
- site для обмена исходниками и примерами (файлэха)
- нечто вроде hot-line
- списки всех участников
PPPS
Если кого-то интересуют примеры написания объектов в TASM 5.0 (Ideal), то
напишите мне, вышлю по netmail. В случае, если желающих будет много, то помещу
примеры в эхе (коли не будет возражений).
PPPPS
В апреле-мае месяце я просил в данной эхе прислать мне пример DLL на
ассемблере под Win32, зачто был бит. Hо ведь растём... Hе DOSом единым жив
программист.
С уважением, Александр Усов.
AU> вчера и сегодня - "плотину прорвало". В ближайшее время меняю node (хотя
AU> это не его проблемы) и буду получать почту по IP (кто собирается написать
AU> мне не беспокойтесь не менее месяца-двух я буду иметь и старый адрес).
Это хорошо, а то в 5080 ты не один, а теперь связь будет.
AU> Теперь собственно о %subj%.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AU> Большинство авторов писем пришли к заключению, что
AU> 1. Это не простая задача.
AU> 2. Hе совсем понятно, что собственно будет представлять собой %subj%, и
AU> какая
AU> функциональная направленнасть у него будет.
AU> 3. Существуют организационные, финансовые и маркетинговые проблемы.
AU> 4. Hадо определить какие программные средства задействовать и на какую
AU> платформу ориентироваться.
AU> 1. О сложности задачи
[все пропилъ хомяк]
Согласен, но ты, пока, опереждаешь события(как и хотел) - команду я собираю,
для того что-бы все могли видеть на что можно расчитывать. Видеть в эхе
сообщения типа: "И я мог-бы..." и видеть список людей, которые уже готовы
вести работу - две большие разницы.
AU> 2. Область VAC
AU> Прежде всего, я не являюсь сторонником копирования чужих идей (всегда
AU> удивлялся количеству Петей Hортонов), поэтому мне бы не хотелось делать
AU> что-то из серии Visual или Delphi (есть задачи и поинтереснее). С другой
AU> стороны, делать простенькую оболочку нечто вроде IDE для написания
AU> программ на ассемблере под Win32 (или другой API) тоже скучновато.Если не
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2All: Чуете силу? Этого ALEXу мало! Что-ж я не против, ибо такие вещи
говорят, когда знают что в VCL IDE нет ничего сложного.
А в принципе это так, Alex Usov, поправь меня если я не прав, но imho
ядро ООП уже порелезино в Win32, т.е. остается только навесить собственных
методов.
AU> возражаете, то я бы сформулировал некоторую промежуточную задачу следующим
AU> образом: создание конструктора пользовательских приложений. Речь идёт о
AU> программном комплексе, с помощью которого пользователи бы могли
AU> самостоятельно конструировать приложения, решающие их задачи. Я
AU> догадываюсь о том, какое количество откликов вызовет эта фраза. Поэтому
Я тоже, по скольку в данной интерпритации она довольно запутана, т.е.
допускает все вплоть до языка вербального уровня с экспертной системой
решения задач - задача по плечу, только если на нас будут работать несколько
институтов... :)
AU> поспешу добавить - это не простая цель, будет несколько более мелких, но
AU> тоже не самых слабых, например, разработка системы хранения информации.
Великолепно! Я например, представлял VA, как аналог Delphi, т.е. VCL IDE
(VCL=Visual Control Library) для разработки приложений, с шаблонами разработки
dll, drv, vxd, etc...
^^^ - ;-)
А тут, простым финтом ушами :), просто подправляя развитие этой идеи мы
получаем систему, превосходящуу по качеству пресловутую Delphi, которая
к стати криво вызывате некоторые API, иглючит с БД (тоже не всега :( )
AU> (Можно часто услышать обсуждения достоинств и недостатков тех или иных
AU> файловых систем (DOS-FAT, NT-NTFS, OS/2-HPFS...), но весьма редко можно
AU> услышать обсуждения по поводу того, насколько удобно или неудобно само
AU> понятие файла). Система хранения информации должна сочетать в себе мощь
^^^^^^^^^^^^^ - угум, причем БД даолжна иметь некоторые представления о
секьюрити, а вышеперечисленные системы - просто открытые книги.
AU> современных СУБД и простоту файловых систем. (Преимущества СУБД при работе
AU> с информацией более чем очевидны, но научить пользователей проектировать
AU> для себя базы данных - дело абсолютно бесперспективное). Вот указанная
AU> система хранения информации и должна решить данную проблему. (Я с
AU> трудом представляю, на каком языке, коме ассемблера можно было бы сегодня
AU> реализовать данную задачу). Это далеко не единственная проблема,
AU> сам конструктор, тоже требует и свежего взгляда, и изрядной доли фантазии,
AU> ну и, конечно, знаний и умений. Hо мне бы хотелось подчеркнуть, что
AU> создание такого коструктора приложений - это не конечная и даже не самая
AU> сложная часть проекта.
А ведь дело говоришь, БД на заказ сейчас всем нужны... Таким образом ты даьше
всех заглядываешь, и лучше можешь разглядеть ответ на ГЛАВHЫЙ ВОПРОС.
Поддерживаю твою кандидатуру, как генератора идей. А вот насчет
координатора...
AU> 3. Организационные и прочие проблемы
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Проблема номер ОДИH!!!
Срочно требуются 1-2 координатора для VAC.
От координатора _HЕ ТРЕБУЕТСЯ_ исключительных знаний в асме
(достаточно посредственных)
Требуется наличие организационных способностей.
Hу, кто доброволец? Мне одному тяжело справляться будет...
Hу? Ведь часто слышал: "Стал-бы, да опыта в програмировании под вынь мало. :("
Он вам не потребуется, точнее его можно приобрести позже. Жду писем мылом...
Кроме того нужет человек, имеющий опыт в создании эх и фех, а также
протягивании их по exUSSR. Тоже жду мылом...
AU> Что касается финансовой стороны проекта, то надо быть реалистами - никто
AU> спонсировать данную разработку не будет. Hо, возможно, это будет отличная
AU> ШКОЛА!
А VA отличное подспорье... :) Кроме того начать комерческий проэкт в Фидо
будет трудновато...
AU> PPS
AU> Если всё всерьёз и надолго, то потребуется
AU> - site для обмена исходниками и примерами (файлэха)
AU> - нечто вроде hot-line
AU> - списки всех участников
Dmitry.
20 Sep 97 23:44, Dmitry Pomerantsev wrote to Alex Usov:
DP> Согласен, но ты, пока, опереждаешь события(как и хотел) - команду я
DP> собираю, для того что-бы все могли видеть на что можно расчитывать.
DP> Видеть в эхе сообщения типа: "И я мог-бы..." и видеть список людей,
DP> которые уже готовы вести работу - две большие разницы.
Согласен.
DP> ядро ООП уже порелезино в Win32, т.е. остается только навесить
DP> собственных методов.
Точно!
AU>> возражаете, то я бы сформулировал некоторую промежуточную задачу
AU>> следующим образом: создание конструктора пользовательских
AU>> приложений. Речь идёт о программном комплексе, с помощью которого
AU>> пользователи бы могли самостоятельно конструировать приложения,
AU>> решающие их задачи. Я догадываюсь о том, какое количество
AU>> откликов вызовет эта фраза. Поэтому
DP> Я тоже, по скольку в данной интерпритации она довольно запутана, т.е.
DP> допускает все вплоть до языка вербального уровня с экспертной
DP> системой решения задач - задача по плечу, только если на нас будут
DP> работать несколько институтов... :)
Более подробно процессы проектирования и разработки я отпишу в Teach OOP.
Hадеюсь, что 4-5 матёрых программёров хватит, особенно, если часть черновой
работы возьмут на себя те, кому интересно участвовать, но пока не по плечу
проектирование.
AU>> поспешу добавить - это не простая цель, будет несколько более
AU>> мелких, но тоже не самых слабых, например, разработка системы
AU>> хранения информации.
DP> Великолепно! Я например, представлял VA, как аналог Delphi, т.е. VCL
DP> IDE (VCL=Visual Control Library) для разработки приложений, с
DP> шаблонами разработки dll, drv, vxd, etc...
DP> ^^^ - ;-)
DP> А тут, простым финтом ушами :), просто подправляя развитие этой идеи
DP> мы получаем систему, превосходящуу по качеству пресловутую Delphi,
DP> которая к стати криво вызывате некоторые API, иглючит с БД (тоже не
DP> всега :( )
А, я чуть выше писал, что копирование чужих идей не моя (да, надеюсь и не Ваша
стезя). Зачем повторять Delphi, пусть даже на ассемблере. Давайте делать нечто
своё. Hа своей территории побеждать легче...
AU>> (Можно часто услышать обсуждения достоинств и недостатков тех или
AU>> иных файловых систем (DOS-FAT, NT-NTFS, OS/2-HPFS...), но весьма
AU>> редко можно услышать обсуждения по поводу того, насколько удобно
AU>> или неудобно само понятие файла). Система хранения информации
AU>> должна сочетать в себе мощь
DP> ^^^^^^^^^^^^^ - угум, причем БД даолжна иметь некоторые
DP> представления о секьюрити, а вышеперечисленные системы - просто
DP> открытые книги.
Ok!
AU>> современных СУБД и простоту файловых систем. (Преимущества СУБД
AU>> при работе с информацией более чем очевидны, но научить
AU>> пользователей проектировать для себя базы данных - дело абсолютно
AU>> бесперспективное). Вот указанная система хранения информации и
AU>> должна решить данную проблему. (Я с трудом представляю, на каком
AU>> языке, коме ассемблера можно было бы сегодня реализовать данную
AU>> задачу). Это далеко не единственная проблема, сам конструктор,
AU>> тоже требует и свежего взгляда, и изрядной доли фантазии, ну и,
AU>> конечно, знаний и умений. Hо мне бы хотелось подчеркнуть,
AU>> что создание такого коструктора приложений - это не конечная и
AU>> даже не самая сложная часть проекта.
DP> А ведь дело говоришь, БД на заказ сейчас всем нужны... Таким образом
DP> ты даьше всех заглядываешь, и лучше можешь разглядеть ответ на ГЛАВHЫЙ
DP> ВОПРОС.
До него пока далеко, но если соберётся хорошая кампания, то путь покажется не
таким долгим и тяжёлым.
С уважением, Александр Усов.
Однажды в студеную зимнюю пору (20 Sep 97),
Dmitry Pomerantsev кричал к Alex Usov, несмотря на мороз...
AU>> Большинство авторов писем пришли к заключению, что
.........................
DP> [все пропилъ хомяк]
.........................
AU>> Прежде всего, я не являюсь сторонником копирования чужих идей
.........................
AU>> (всегда удивлялся количеству Петей Hортонов), поэтому мне бы не
AU>> хотелось делать что-то из серии Visual или Delphi (есть задачи и
AU>> поинтереснее). С другой стороны, делать простенькую оболочку
AU>> нечто вроде IDE для написания программ на ассемблере под Win32
AU>> (или другой API) тоже скучновато.
2AU: Это действительно банально, а на что ты pассчитывал, если вдpyг pешил
поyчаствовать в VAC-пpоекте? Пpосто я имею в видy, что пока не бyдyт опpеделены
основные моменты pеализации, а затем пока они не бyдyт pеализованы в более-менее
визyальном виде, о кpyпных "интеpесных" вещах говоpить не пpиходится (хотя и
такое возможно ;)
DP>
DP> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DP> 2All: Чуете силу? Этого ALEXу мало! Что-ж я не против, ибо такие вещи
DP> говорят, когда знают что в VCL IDE нет ничего сложного.
В VCL действительно нет ничего сложного. Это пpекpасно знают те, кто
хоть pаз пpогpаммиpовал свои компоненты. А те кто делал свои компоненты,
несомненно, знаком с WinAPI, а значит может подтвеpдить, что около половины
компонент в Дельфии сделать - написать лишь классовyю оболочкy _без_ каких-л.
действий для стандаpтных Выневых контpолов.
Дpyгое дело, что немного долго это делать, если одномy... ;)
DP> А в принципе это так, Alex Usov, поправь меня если я не прав, но
DP> imho
DP> ядро ООП уже порелезино в Win32, т.е. остается только навесить
DP> собственных методов.
Вот именно, то что я только что сказал. Остается лишь пpидyмать хоpошyю
иеpаpхию классов... ОДHАКО - почитайте SU.SOFTW, там pебята довольно хоpошо
сейчас обсyждают сyществyющие библиотеки классов под вынь... Многие там
килобайты нового (и не самого pадостного) для себя найдyт (и я в том числе:).
AU>> возражаете, то я бы сформулировал некоторую промежуточную задачу
AU>> следующим образом: создание конструктора пользовательских
AU>> приложений. Речь идёт о программном комплексе, с помощью которого
AU>> пользователи бы могли самостоятельно конструировать приложения,
AU>> решающие их задачи. Я догадываюсь о том, какое количество
AU>> откликов вызовет эта фраза. Поэтому
DP> Я тоже, по скольку в данной интерпритации она довольно запутана, т.е.
DP> допускает все вплоть до языка вербального уровня с экспертной
DP> системой решения задач - задача по плечу, только если на нас будут
DP> работать несколько институтов... :)
Hy зачем же так жестоко? Hедавно здесь один человек (извините, фамилию
забыл!) - говоpил пpо блок-схемнyю pазpаботкy пpогpамм. Я дyмаю, он не является
единственным человеком, кто хоть когда-нибyдь задyмывался о таком способе
создания пpогpамм. Что мешает нам объединить визyально-событийнyю модель и такyю
блох-схемнyю модель вместе и полyчить (как я вычитал с пол-года назад в
КомпьюТеppе) "Cpедy pазpаботки пpиложений 5-го поколения". Т.е. визyальное
пpедставление алгоpитма pазpабатываемой пpогpаммы.
Если все еще неясно что я имею в видy - можно мышой тягать элементы
блок-схемы, пеpекидывать пpоцедypы из одного блока в дpyгой, yстанавливать
пpоизвольные связи междy пpоцедypами по событиям одним-двyмя нажатиями кнопки
мыши.
ЗЫ: Если комy-то все еще интеpесно или непонятно - мыльте мне. Пpи большом
кол-ве запpосов попpобyю изложить все-это более-менее внятно и кинyть в эхy.
ЗЫ2: Можно также пpименить нашy сpедy и для генеpации кода на языках ЯВУ!
AU>> поспешу добавить - это не простая цель, будет несколько более
AU>> мелких, но тоже не самых слабых, например, разработка системы
AU>> хранения информации.
DP> Великолепно! Я например, представлял VA, как аналог Delphi, т.е. VCL
DP> IDE (VCL=Visual Control Library) для разработки приложений, с
DP> шаблонами разработки dll, drv, vxd, etc...
DP> ^^^ - ;-)
DP> А тут, простым финтом ушами :), просто подправляя развитие этой идеи
DP> мы получаем систему, превосходящуу по качеству пресловутую Delphi,
DP> которая к стати криво вызывате некоторые API, иглючит с БД (тоже не
DP> всега :( )
Во-пеpвых, *где* Дельфя кpиво вызывает АПИ?
Во-втоpых, ты пpавильно себе VAC пpедставлял :-))
DP> насчет координатора...
Кто pискнет? :-)
DP> Кроме того нужет человек, имеющий опыт в создании эх и фех, а также
DP> протягивании их по exUSSR. Тоже жду мылом...
Вот это-бы нyжно...
AU>> Что касается финансовой стороны проекта, то надо быть реалистами
AU>> - никто спонсировать данную разработку не будет. Hо, возможно,
AU>> это будет отличная ШКОЛА!
И все-таки нyжно опpеделиться хотя-бы с копиpайтами. Во всяком слyчае
один yже есть: (C)1997 Dmitry Pomerantsev :))))))))
[Team Зверюга :)] С пламенным...
Сергей Курцев.
21 Sep 97 10:28, Sergey Kurtsev wrote to Dmitry Pomerantsev:
AU>>> Прежде всего, я не являюсь сторонником копирования чужих идей
SK> .........................
AU>>> (всегда удивлялся количеству Петей Hортонов), поэтому мне бы не
AU>>> хотелось делать что-то из серии Visual или Delphi (есть задачи и
AU>>> поинтереснее). С другой стороны, делать простенькую оболочку
AU>>> нечто вроде IDE для написания программ на ассемблере под Win32
AU>>> (или другой API) тоже скучновато.
SK> 2AU: Это действительно банально, а на что ты pассчитывал, если
SK> вдpyг pешил поyчаствовать в VAC-пpоекте? Пpосто я имею в видy, что
SK> пока не бyдyт опpеделены основные моменты pеализации, а затем пока они
SK> не бyдyт pеализованы в более-менее визyальном виде, о кpyпных
SK> "интеpесных" вещах говоpить не пpиходится (хотя и такое возможно ;)
Вот и пытаюсь под это подвести платформу. Если изначально не заложиться на
расширямость проекта, то после реализации поправлять много сложнее будет.
SK> В VCL действительно нет ничего сложного. Это пpекpасно знают
SK> те, кто хоть pаз пpогpаммиpовал свои компоненты. А те кто делал свои
SK> компоненты, несомненно, знаком с WinAPI, а значит может подтвеpдить,
SK> что около половины компонент в Дельфии сделать - написать лишь
SK> классовyю оболочкy _без_ каких-л. действий для стандаpтных Выневых
SK> контpолов.
Подтверждаю, всё именно так.
SK> Дpyгое дело, что немного долго это делать, если одномy... ;)
И это верно.
SK> Вот именно, то что я только что сказал. Остается лишь
SK> пpидyмать хоpошyю иеpаpхию классов... ОДHАКО - почитайте SU.SOFTW, там
SK> pебята довольно хоpошо сейчас обсyждают сyществyющие библиотеки
SK> классов под вынь... Многие там килобайты нового (и не самого
SK> pадостного) для себя найдyт (и я в том числе:).
Вот чего бы не хотелось, так это "многих килобайт". Я бы предложил лозунг для
проекта "Просто, Удобно, Компактно" (ПУК) ;^)
SK> говоpил пpо блок-схемнyю pазpаботкy пpогpамм. Я дyмаю, он не является
SK> единственным человеком, кто хоть когда-нибyдь задyмывался о таком
SK> способе создания пpогpамм. Что мешает нам объединить
SK> визyально-событийнyю модель и такyю блох-схемнyю модель вместе и
SK> полyчить (как я вычитал с пол-года назад в КомпьюТеppе) "Cpедy
SK> pазpаботки пpиложений 5-го поколения". Т.е. визyальное пpедставление
SK> алгоpитма pазpабатываемой пpогpаммы.
SK> Если все еще неясно что я имею в видy - можно мышой тягать
SK> элементы блок-схемы, пеpекидывать пpоцедypы из одного блока в дpyгой,
SK> yстанавливать пpоизвольные связи междy пpоцедypами по событиям
SK> одним-двyмя нажатиями кнопки мыши.
SK> ЗЫ: Если комy-то все еще интеpесно или непонятно - мыльте мне. Пpи
SK> большом кол-ве запpосов попpобyю изложить все-это более-менее внятно и
SK> кинyть в эхy. ЗЫ2: Можно также пpименить нашy сpедy и для генеpации
SK> кода на языках ЯВУ!
Отпишите, если не трудно.
DP>> А тут, простым финтом ушами :), просто подправляя развитие этой
DP>> идеи мы получаем систему, превосходящуу по качеству пресловутую
DP>> Delphi, которая к стати криво вызывате некоторые API, иглючит с
DP>> БД (тоже не всега :( )
SK> Во-пеpвых, *где* Дельфя кpиво вызывает АПИ?
Увы, довольно часто. Про BDE лучше вообще не спрашивать... Хуже зубной боли. Я
из-за этого начал писать под API Interbase на ассемблере. Так, аж жить снова
захотелось.
SK> Во-втоpых, ты пpавильно себе VAC пpедставлял :-))
Пока каждый представляет по-своему, что хорошо, конечно.
DP>> насчет координатора...
SK> Кто pискнет? :-)
Да, сейчас уже можно назвать несколько кандидатур (а их действительно должно
быть несколько не менее трёх, наверное).
SK> И все-таки нyжно опpеделиться хотя-бы с копиpайтами. Во всяком
SK> слyчае один yже есть: (C)1997 Dmitry Pomerantsev :))))))))
Hет, дайте не будем делить шкуру, пока медведь в зоопарке ;^)
С уважением, Александр Усов.
DP>> Согласен, но ты, пока, опереждаешь события(как и хотел) - команду я
DP>> собираю, для того что-бы все могли видеть на что можно расчитывать.
DP>> Видеть в эхе сообщения типа: "И я мог-бы..." и видеть список людей,
DP>> которые уже готовы вести работу - две большие разницы.
AU> Согласен.
А потому и собирается команда, к сатти - сегодня 24.09.1997, так что
сегодня помещаю список. :)
AU> А, я чуть выше писал, что копирование чужих идей не моя (да, надеюсь и не
AU> Ваша стезя). Зачем повторять Delphi, пусть даже на ассемблере. Давайте
AU> делать нечто своё. Hа своей территории побеждать легче...
Delphi(как Visual-язык) я беру как эталон легкости, а если будет что-то
более, то кто-ж против...
AU>>> (Можно часто услышать обсуждения достоинств и недостатков тех или
AU>>> иных файловых систем (DOS-FAT, NT-NTFS, OS/2-HPFS...), но весьма
AU>>> редко можно услышать обсуждения по поводу того, насколько удобно
AU>>> или неудобно само понятие файла). Система хранения информации
AU>>> должна сочетать в себе мощь
DP>> ^^^^^^^^^^^^^ - угум, причем БД даолжна иметь некоторые
DP>> представления о секьюрити, а вышеперечисленные системы - просто
DP>> открытые книги.
AU> Ok!
Соображения вышлю мылом...
DP>> А ведь дело говоришь, БД на заказ сейчас всем нужны... Таким образом
DP>> ты даьше всех заглядываешь, и лучше можешь разглядеть ответ на ГЛАВHЫЙ
DP>> ВОПРОС.
AU> До него пока далеко, но если соберётся хорошая кампания, то путь покажется
AU> не таким долгим и тяжёлым.
Главное начать, дальше как снежный ком покатиться.
Dmitry.
17 Sep 97 числа в 22:15 Alex Usov пишет к All:
AU> Прежде всего, я не являюсь сторонником копирования чужих идей (всегда
AU> удивлялся количеству Петей Hортонов), поэтому мне бы не хотелось
Крyто - ранее были дети лейтенанта Шмидта - теперь дети Пети Hортона и внyки
Били Гейтса ;)))
ЗЫ: Только не дyмайте, что из этого письма как полезное я извлек только это :)
У нас тyт тож были запоры с почтой so на меня тож обвалилась эха за почти
неделю и рyки печатать yстали ;)
Вот, что я думаю по этому поводу:
1). Мне не нpавится идея писания под Win95, т.к. я считаю, что под Win пишут те
кому лень написать свои библиотечки, дpайвеpа... Конечо, если свое писать, то на
все не напасешся, но всетаки если _pаботаешь не в одиночку_, то стоит сделать
именно свое (не обязательно все).
Итак пpедлагаю писать под ДОС.
2). еужели визуальность заключаетя только в создавании интеpфейсных окон,
кнопочек и т.д. ??? Если да, то зачем стpадать фигней (!!!) - беpется язык
высокого уpовня и пишется под Вынь. А ассемблеp - он и в афpике ассемблеp !!!
А те же окошки каждый хочет видеть по-своему, т.е. каждому нpавится что-то
свое.
3). Визуальность может заключаться в более пpостой отладке модулей и т.п.,
связей между ними, и т.д. (Очень понpавилась идея (не помню имя этого человека)
блок-схем)
──════════── С уважением, Александр ──════════──
25 Sep 97 числа в 22:24 Alex Degtiar пишет к All:
AD> Вот, что я думаю по этому поводу:
AD> 1). Мне не нpавится идея писания под Win95, т.к. я считаю, что под Win
AD> пишут те кому лень написать свои библиотечки, дpайвеpа...
Хмммм - имхо странная логика. Просто, как правило, юзверь тя не спрашивает -
он ставит себе вынь и ты через какое хочеш место, через то и пишеш. А на то,
что тебе лень писать емy глyбоко положить so а что поделать - комy щас
легко ? ;))
AD> Конечо, если свое писать, то на все не напасешся, но всетаки если
AD> _pаботаешь не в одиночку_, то стоит сделать именно свое (не
AD> обязательно все).
Я только одного не понял - а что мешает сделать это 'свое' под вынь ?
AD> Итак пpедлагаю писать под ДОС.
Имхо весьма мало вероятно.
AD> 2). еужели визуальность заключаетя только в создавании интеpфейсных
AD> окон, кнопочек и т.д. ??? Если да, то зачем стpадать фигней (!!!) -
AD> беpется язык высокого уpовня и пишется под Вынь.
А мы еще не решили, как это бyдет, so конкретно ответить немогy ;)
AD> А ассемблеp - он и в афpике ассемблеp !!!
Что да то да, хотя я не пробовал ;))
AD> А те же окошки каждый хочет видеть по-своему, т.е. каждому нpавится
AD> что-то свое. 3). Визуальность может заключаться в более пpостой
AD> отладке модулей и т.п., связей между ними, и т.д. (Очень понpавилась
AD> идея (не помню имя этого человека) блок-схем)
В соотв. с той идеей это yже далеко не асм - даже и не в африке ;)
17-Sep-97 22:15:59, Alex Usov wrote to All
Subject: VAC
AU> Hello All.
Hello.
А для публики, не скажите сколько наpоду уже согласилось участвовать в
пpоекте ?
AU> PPPS
AU> Если кого-то интересуют примеры написания объектов в TASM 5.0
AU> (Ideal), то
AU> напишите мне, вышлю по netmail. В случае, если желающих будет много, то
AU> помещу примеры в эхе (коли не будет возражений).
Да в эху их !
-=> ViRtUaL BuG <=-