Важная информация
Показано с 1 по 8 из 8

Тема: QBASIC и совместимость его диалектов.

  1. #1 QBASIC и совместимость его диалектов. 
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,829
    Сказал(а) спасибо
    1,810
    Поблагодарили 934 раз(а) в 796 сообщениях
    Записей в блоге
    1
    Вроде преподносят относительно корректно.
    Ну тогда я не знаю почему все бросаются на эти диалекты и хотят чтобы их программы на QBasic в них работали. А это сплошь и рядом.

    ценители QBASIC хотят его поддержки
    Нет спасибо, такой поддержки не надо и в особенности популяризации такой поддержки.

    от же FreePascal НАМНОГО мощнее своего досовского собрата
    Я про это в курсе, просто поддержка QBasic в подобных системах лишняя, ибо это кастыль, далеко на нём не уйдёшь...

    И ни в одном официальном описании языка я не видел заявлений о ПОЛНОЙ совместимости с прерыдущей версией.
    Ну тем более, значит её и нет и никогда не было.

    Я благодарен разработчикам за ту работу, которую они проделали.
    С одной стороны я мог бы быть им благодарен если бы пользовался, с другой, я далеко не благодарен им за такой подход, пусть делают свои компиляторы, но не трогают старые системы программирования, заявляя о якобы совместимости с ними.

    но даже запись в порты(!), работа с таймером и экранным режимом сработали корректно
    Насчёт работы с экраном я никогда не поверю, если почитать документацию по асму о программировании режимов CGA, EGA, VGA, VBE. Наверняка там реализован самый самый примитив, если вообше реализован, даже специализированные системы эмуляции держат далеко не всё.

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

    т.к компилятор FB под DOS генерирует 32-бит код для защищенного режима
    О боже, всё я замолкаю...

    PS: Моя позиция всем ясна, не буду разводить оффтоп, для этой дискуссии нужна отдельная тема.
    Последний раз редактировалось >Quiet Snow<; 11.09.2011 в 22:27.
    Ответить с цитированием  
     

  2. #2 QBASIC и совместимость его диалектов. 
    Гуру Аватар для Абадябер
    Регистрация
    09.12.2010
    Адрес
    Беларусь, Минск
    Сообщений
    1,219
    Сказал(а) спасибо
    302
    Поблагодарили 176 раз(а) в 144 сообщениях
    Записей в блоге
    5
    Вот, ребята, уже не в первый раз замечаю, что достаточно интересные обсуждения порой рождаются в виде оффтопика. Вот что получилось из одной моей переписки с >Quote Snow<
    Соответственно, надеюсь, что никто не будет возражать, если в этой теме, при заинтересованности моего собеседника и других участников форума, будет обсуждаться данная проблема. Тема не создается ради того, чтобы развести очередной срач - я сторонник вежливой дискуссии (хоть иногда мои высказыванию и могут звучать несколько резко), и всегда рад взглянуть на свои и чужие доводы с разных сторон - многие вещи кажутся разными, если на них смотреть под разными углами.
    Итак, с чего все началось:

    Цитата Сообщение от >Quiet Snow<
    Небольшой оффтоп:
    По поводу заявлений создателей разных диалектов о совместимости с QBasic: всё это жуткая брехня, много раз я встречал, что народ писал на них в режиме совместимости, после чего программа не работала в самом QBasic, отсюда следует, что НИ О КАКОЙ СОВМЕСТИМОСТИ РЕЧИ НЕ ИДЁТ, частичная эмуляция синтаксиса - это не совместимость. Поэтому мой совет: если вам нужен QBasic используйте именно его или более продвинутые версии QuickBasic, в противном случае используйте синтаксис тех диалектов, на которых пишете БЕЗ режима совместимости. Особенно это касается всяких новоиспечённых QB64, FreeBasic и прочих, которые совершенно НЕСОВМЕСТИМЫ с QBASIC. Потому что, постоянно, когда начинаются скрещивания, всегда вылезают косяки то там, то здесь. Причин много, как минимум одна веская: попытка сэмулировать ОС DOS и старые спецификации железа на уровне компилятора\интерпретатора(!!!), далее идёт полная невнимательность\халатность создателей этих режимов совместимости. Потому что прежде чем делать заявления о совместимости, нужно тестировать, тестировать и ещё раз тестировать, как минимум на 1000 программах и если хотя бы одна программа не компилируется\интерпретируется - всё, СОВМЕСТИМОСТИ НЕТ.
    Почему я об этом так критически отзываюсь? Да просто задолбала эта байда, наклепали кучу кастрированных недоязыков и пытаются нагло соврать, может быть все нюансы в документации оговорены, но преподносят это именно так, как преподносят - так народ и понимает, пора развеивать все эти иллюзии.
    Дружба-магия-радость!
    Ответить с цитированием  
     

  3. #3  
    Гуру Аватар для Абадябер
    Регистрация
    09.12.2010
    Адрес
    Беларусь, Минск
    Сообщений
    1,219
    Сказал(а) спасибо
    302
    Поблагодарили 176 раз(а) в 144 сообщениях
    Записей в блоге
    5
    Цитата Сообщение от Абадябер
    >Quiet Snow<, я присоединюсь к оффтопу, пожалуй =)
    Цитата Сообщение от >Quiet Snow< Посмотреть сообщение
    может быть все нюансы
    Конечно, оговорены. Например, в документации по Free Pascal очень строго оговорены все нюансы и различия между Turbo Pascal, которые нужно учесть при написании.
    Также, у меня без потерь на QB64 скомпилировалась моя игра. Кода хоть там и немного (50Кб), но даже запись в порты(!), работа с таймером и экранным режимом сработали корректно, проблем с ней небыло.
    Что касается диалектов FreeBasic, FreePascal и прочих, то они все таки генерируют кроссплатформленнный код и это для них - первостепенная задача, в отличае от совместимости со старыми версиями QBASIC. И ни в одном официальном описании языка я не видел заявлений о ПОЛНОЙ совместимости с прерыдущей версией. В хелпах по FreeBasic и FreePascal, например, всегда ПОДРОБНО оговариются подобные нюансы, и даются советы, как с этим можно бороться, и как с минимальными "потерями" подготовить явно несовместимую программу для компиляции этими компиляторами. И при этом мы получаем возможность скомпилировать программу для нескольких платформ (!), при необходимости. Всегда есть и советы - как впредь писать максимально переносимый код.
    Я благодарен разработчикам за ту работу, которую они проделали. Ибо балансировать между молотом и наковальней всегда непросто - они замутили кроссплатформленный компилятор? Отлично. Так еще и синтаксис совместимости с QB\TP ввели (ну да, может и не идеальный, но если бы реализуемо было сделать более полную поддержку - ее бы уже сделали). 20-30 мегабайт хелпов написали. И все бесплатно, на голом энтузиазме, ВСЕ исходники всегда можно скачать и модифицировать при необходимости. Чего еще просить, на что жаловаться?
    Совместимость между разными компиляторами, поддерживание разных стандартов, также как и кросс-платформленность - бич всего современного мира. В том же языке C (согласен, пример может и не совсем корректен, но все же), например, разные его компиляторы могут интерпретировать следующий код по разному: int i = 5; i = ++i + ++i; (будет или 13, или 14). И все дело не в отсутстии стандартов, которые как раз присутствуют, а в том, что эти стандарты достаточно свободные.
    А теперь представьте себя на месте разработчиков компиляторов (в частности FB и FP). Здравый смысл шепчет, что в наше время кроссплатформленность более чем желательна; ценители QBASIC хотят его поддержки; Стандарты ANSI подмигивают разработчику с ехидным лицом, мол "не забывай, анонимус, что мы есть".
    Вот и разработчики FreeBASIC\FreePascal вынуждены заниматься не только написанием максимально-совместимого с QB компилятора, но и решать вопрос переносимости, и соответствия их компиляторов современным стандартам. Подобные стремления редко обходятся дешево.
    Да просто задолбала эта байда, наклепали кучу кастрированных недоязыков
    Не сказал бы. Тот же FreePascal НАМНОГО мощнее своего досовского собрата (начиная с общей сути - компиляция идет в защищенный режим, есть динамические массивы, перегрузка операндов в функциях и.т.п), мало того, способен компилировать даже программы на Delphi (этим занимался участник нашего форума - Dimon012). Просто хочу подметить, что не совсем уважительно называть язык "недоязыком", если фактически, есть много причин, чтобы не согласиться с таким утверждением.
    может быть все нюансы в документации оговорены, но преподносят это именно так, как преподносят
    Вроде преподносят относительно корректно. Большим шрифтом, на пол страницы никто не писал "ПОЛНАЯ СОВМЕСТИМОСТЬ С QB\TP и.т.д". Мало того, если к человеку на улице подойдет тип сомнительной наружности, и предложит купить, к примеру, мобильный телефон, он тоже его купит, даже не проверив предварительно на то, рабочий ли он (и не краденый)?
    ...
    ...
    Можно, конечно
    написать функцию открытия файла на ассемблере, возвращающую результат открытия.
    , и она будет хорошо работать на QB. Однако гарантий, что она будет работать на FB нет - т.к компилятор FB под DOS генерирует 32-бит код для защищенного режима, в котором вызов прерываний ограничен (как правило, они вообще должны вызываться в защищенном режиме, через специальную функцию DPMI).
    (Сообщение №2)
    Дружба-магия-радость!
    Ответить с цитированием  
     

  4. #4  
    Гуру Аватар для Абадябер
    Регистрация
    09.12.2010
    Адрес
    Беларусь, Минск
    Сообщений
    1,219
    Сказал(а) спасибо
    302
    Поблагодарили 176 раз(а) в 144 сообщениях
    Записей в блоге
    5
    Ну тогда я не знаю почему все бросаются на эти диалекты и хотят чтобы их программы на QBasic в них работали
    Вполне возможно, что ноги у этой тенденции растут именно из того факта, что совместимость программ, скопилированных на QB с современным железом неуклонно падает. Возможно люди хотят использовать преимущества современного железа, не говоря уже о том, чтобы получить совместимость своих когда то написанных программ с этим самым железом, не мучая пользователей лишний раз необходимостью использовать эмулятор. А тут бац - в интернете всплывают компиляторы, среди плюшек которых значится "поддержка QB синтаксиса". Разумеется, люди обратят внимание на такие компиляторы.
    "Почему бы не попробовать, если бесплатно? Гарантий никто не дает, но и я никому ничего не должен". Конечно, потом на форума прибегают толпы недовольных людей, с вопросами "А почему не компилируется". Это уже следствие =)
    При этом, никто не кричал про "100%" поддержку.

    т.к компилятор FB под DOS генерирует 32-бит код для защищенного режима
    О боже, всё я замолкаю...
    И, разумеется, уже тот факт, что FB для DOS генерирует 32бит код, работающий в защищенном режиме, дает понять нам, что полная поддержка практически невозможна - идеолии работы программ в реальном (QB) и защищенном (FB) режимах процессора разительно отличаются. И тем не менее, синтаксис частично поддерживается. Программы, на прямую не пользующиеся особенностями работы в реальном режиме процессора (та же запись в порты, прямой доступ к памяти, вызов DOS-прерываний) теоретически вполне могут быть скомпилированы, если компилятор FB предоставит им поддержку на уровне синтаксиса. Ну да, может быть, где либо придется внести правки. Некоторую цену всегда приходится платить. Но вместе с этим мы что-то и получаем, ведь верно?

    Нет спасибо, такой поддержки не надо и в особенности популяризации такой поддержки.
    Ну, вы не хотите, а кому нибудь она может и нужна? Хоть даже и в таком ущербном виде - но нужна. Над некоторыми проектами можно и поколдовать с пару недель, пользуясь советами, изложенными в документации, поустанавливав несколько костылей (ну да, куда же без этого), и добиться таки правильной работы программы, написанной ранее на QBasic и скомпилированной на FB. А вот целособразность этих муток уже каждый разработчик должен решать для себя самостоятельно.

    просто поддержка QBasic в подобных системах лишняя, ибо это кастыль, далеко на нём не уйдёшь...
    Я немного с вами не согласен.. Ну как же костыль? Я бы назвал это одним из вариантов принимаемого компилятором синтаксиса.
    Костыль - по сути - неестественная надстройка, призванная некрасиво, но быстро решить проблему, вместо того, чтобы лишний раз переработать код. А поддержка синтаксиса (частичная) QB - это одна из функций FB zxD))) На мой взгляд, конечно, поправьте, если я вас неправильно понял)

    Ну тем более, значит её и нет и никогда не было.
    А я не утверждал, что она там есть полная, или когда либо была)
    Частично поддерживается синтаксис - уже лучше, чем ничего. Если приспичит портировать программу с досовского QBasic на что нибудь более современное - будет еще один вариант, кроме как переписать все заново.

    пусть делают свои компиляторы, но не трогают старые системы программирования
    Разве QBasic пострадал от действий разработчиков FB? А TurboPascal от FP? Не считая того, что сейчас олимпиады по программированию модно проводить на FreePascal, а не на Turbo, то вроде бы и нет.

    Насчёт работы с экраном я никогда не поверю, если почитать документацию по асму о программировании режимов CGA, EGA, VGA, VBE. Наверняка там реализован самый самый примитив, если вообше реализован, даже специализированные системы эмуляции держат далеко не всё.
    Ну тоесть, выходит, мне приснилось, что моя игра напрямую пишет в порты VGA данные о палитре (OUT &H3C9, red%: OUT &H3C9, green%: OUT &H3C9, blue%), а QB64 все скомпилировал под Windows без единой правки, и результат ни на йоту не отличался от того, что я имел под DOS? =). только что, как написал эти строки, сам уж усомнился. Установил Qb64, еще раз скомпилировал. Все работает. =)
    Уже, как видите, код, ориентированный на использование в реальном режиме работы процессора, был скомпилирован таким образом, чтобы выполнять аналогичное по результату действие в режиме защищенном, под управлением Windows (конечно, никакой записи в порты там не происходит вовсе - но нам про это знать не обязательно, не так ли?) Работает - хорошо. И опять же, про полную поддержку никто не кричал. Обычно в таких случаях говорят "почти полная". И уже придраться не к чему =)

    Я не понимаю какое значение имеет кроссплатформенность по отношению к совместимости, зачем мне вообще кроссплатформенность(особенно такая, а если у меня нету драйверов DPMI или я тупо не хочу чтобы они были?), зачем это, когда почти каждая вторая прога не компилируется или не функционирует должным образом(не у меня, а у неосведомлённого пипла).
    Если пипл пришел к FB, чтобы двумя щелчками компилировать свои программы, написанные им же на QB, обнаружил, что ничего не компилируется и кинул предъяву разработчикам, то что должны сделать разработчики FB? В лучшем случае, сказать "курите мануалы". Что всякий грамотный человек в идеале и должен прежде всего сделать (в смысле, ознакомиться с руководством). Потому что ни FreeBASIC, ни FreePascal никогда не позиционировались, как полноценная замена QBasic и панацея для всех жаждущих перенести свой код с доса в другую систему. Дали некий функционал, способный облегчить эту задачу, хотите - пользуйтесь, хотите - нет. А про полную поддержку никто ни кричал. Зато эти компиляторы хорошо известны своей кроссплатформенностью. Вот =)
    Дружба-магия-радость!
    Ответить с цитированием  
     

  5. #5  
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,829
    Сказал(а) спасибо
    1,810
    Поблагодарили 934 раз(а) в 796 сообщениях
    Записей в блоге
    1
    Продолжаю дискус.

    Не знаю интересна ли кому данная тема, просто хотел "расставить все точки над и" и объяснить людям от чего есть толк, а что следует обойти стороной.
    Я говорю как старый QuickBasic кодер, да QBasic можно рассматривать как QBasic только применительно к DOS. Это своеобразная игрушка, пытаться преобразовать её в серьёзный диалект - это ну как минимум странная идея, а тем паче наоборот. Современные диалекты должны жить своей жизнью, преимущественно под новые ОС и аппаратуру, пытаться в 2011 году сэмулировать тачки конца 80-х годов со всеми их заморочками и отсутствием как таковых чётких стандартов невозможно.
    Кроссплатформенность, стоит ли говорить какие пляски с бубном нужны для этого, о плюсах и минусах, просто о большой разнице программирования под разные платформы, о невозможности использования низкоуровневого программирования.
    Я например не считаю кроссплатформенность важной вещью, да платформы плодятся как кролики, но PC на текущий момент всё ещё наиболее распространённая машина и в том числе ОС Windows, на худой конец есть эмуляторы, сейчас эмулируется почти всё на почти всём, а на современных тачках даже аппаратно.

    Вот цитата с оф сайта фри бейсика, прям первые строчки:
    When used in its "QB" language mode, FreeBASIC provides a high level of support for programs written for QuickBASIC. Many programs written for QuickBASIC will compile and run in this mode with no changes needed.
    Вот как они это приподносят, мол люди высокий уровень суппорта программ на QuickBASIC(!!! даже не QBasic, а на Quick уже позарились, в котором 90% нормальных программ написаны с помощью *.QLB* библ).
    Народ ясен пень ведётся, но когда вылазиют баги это доставляет головную боль всем. Честно сказать зачем этот режим нужен я не возьмусь, если в "нормальных" программах, всё равно придётся переписывать > 50% кода, т.е. он никак не упрощает жизнь, а в свете того, что появляются баги из-за несовместимости синтаксиса, он её наоборот усложняет. Что на QBasic с его абсолютом(а ведь без этого даже банально мышку не сделать), что на QuickBasic, где куча кода на ассемблере в *.QLB.
    Вообще очень забавно видеть когда люди ничего не(или мало) знающие о QuickBasic пытаются начать с режима совместимости, тратя своё время на его изучение. При этом не получив нормальных навыков программирования на QuickBasic\QBasic, почему бы сразу, не тратя врмени изучить диалект и писать программы, ведь толку в разы больше.
    Товарищ Абадябер ещё упоминал Dpmi, что это за фигня сейчас поясню. Dpmi это такой интерфейс, с помощью которого можно перевести программу в защищённый режим, при этом пользуясь функциями DOS. Для юзанья защищённого режима в MS-DOS нужны спец. драйверы Himem.sys либо так называемый экстендер. В программу при этом помещается инициализация интерфейса DPMI через вектор 2Fh(сюда экстендер и вешает свой сервис), а сама программа пишется во flat режиме. Многие скажут что драйверы можно легко найти, но я скажу что они не всегда есть под рукой и не всегда они нужны. Наиболее надёжно писать программы для реального режима, т.к. для этого ничего не надо. А люди, которые про это не знают, даже не поймут что нужен какой-то ещё экстендер или драйвер, который нужно ещё прописать в CONFIG.SYS и должным образом настроить.
    Что сказать в завершение, DOS устарел ещё давно, единицы могут написать в досе что-то стоящее, в связи со сложностью структуры и неоднозначностью стандартов железа пытаться однозначно сэмулировать DOS бесполезно(ровно так же как и запускать программы DOS под виндами), а по факту ещё и неэффективно. Поэтому все, кто рвутся на новые диалекты - пишите под винды, макоси, линуксы и оставьте уже в покое старичка QBasic, он не виноват что программы его эмулирующие не могут его сэмулировать и вообще одним словом "не могут".
    Ответить с цитированием  
     

  6. #6  
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,829
    Сказал(а) спасибо
    1,810
    Поблагодарили 934 раз(а) в 796 сообщениях
    Записей в блоге
    1
    Костыль - по сути - неестественная надстройка, призванная некрасиво, но быстро решить проблему
    Чаще и некрасиво и не быстро, а чисто дающая возможность. Потому данная фраза и была мной употреблёна.

    OUT &H3C9, red%: OUT &H3C9, green%: OUT &H3C9, blue%
    О эти величайшие строки, но мы то знаем, что эти легендарные портики VGA не поддерживаются только дилетантами. А давайте копнём глубже, попробуем откопать какую-нибудь древнюю программу, производящюю операции с битовыми плоскостями, допустим на паскале была крутая библа XLib, которая на 200-й тачке давала большой FPS в 3D при отрисовке треугольниками, а ведь ценность такой проги тоже может быть велика для человека, или ещё, допустим захочу через спикер воспроизвести вавку, как это делалось ранее получится? Уверен нет. Этих нюансов в DOS много, DOS уникален за счёт этого, его уникальность неубиваема даже этими жалкими потугами авторов режимов совместимости. Всё это любая из DOS программ как правило может использовать, но вот досада, что скомпилировать это не удастся ни под каким предлогом. Хотя зачем что-то копать, живой пример в теме рядом, наистандартнейшая вещь.
    Последний раз редактировалось >Quiet Snow<; 12.09.2011 в 04:08.
    Ответить с цитированием  
     

  7. #7  
    Гуру Аватар для Абадябер
    Регистрация
    09.12.2010
    Адрес
    Беларусь, Минск
    Сообщений
    1,219
    Сказал(а) спасибо
    302
    Поблагодарили 176 раз(а) в 144 сообщениях
    Записей в блоге
    5
    >Quiet Snow<, было очень интересно прочитать ваше сообщение - чувствуется "тертый калач", ага =). Я по прежнему не везде согласен с вами, однако должен признать, что расставить точки над i вам отлично удалось - в общем логика довольно разумна, и теперь мне стали понятны ваши доводы. Что-то и новое узнал для себя

    Вот только:
    Dpmi это такой интерфейс, с помощью которого можно перевести программу в защищённый режим, при этом пользуясь функциями DOS. Для юзанья защищённого режима в MS-DOS нужны спец. драйверы Himem.sys либо так называемый экстендер. В программу при этом помещается инициализация интерфейса DPMI через вектор 2Fh(сюда экстендер и вешает свой сервис), а сама программа пишется во flat режиме. Многие скажут что драйверы можно легко найти, но я скажу что они не всегда есть под рукой и не всегда они нужны. Наиболее надёжно писать программы для реального режима, т.к. для этого ничего не надо
    Himem.sys никогда не предоставлял функций DPMI-хоста himem - всего лишь менеждер памяти+драйвер для поддержки этой самой XMS-памяти, а также UMB. Да, он переводит процессор в защищенный режим специальной недокуметированной командой, для того, чтобы получить доступ к этой памяти - но лишь временно, и никаким DPMI от него даже не пахнет.
    Да и экстендеров, которые нужно записывать в config.sys ни разу не встречал) Насколько мне известно, обычно они линкуются с обЪектным файлом программы, или встраиваются как либо другим образом в исполняемый файл программы, либо же находятся в отдельном - так были написаны Doom, DN3D, Quake и некоторые другие шедевры - и ни один из них не требовал прописывать что либо в config.sys при запуске =)
    Дружба-магия-радость!
    Ответить с цитированием  
     

  8. #8  
    Супер модератор Аватар для >Quiet Snow<
    Регистрация
    11.04.2011
    Адрес
    Планета земля
    Сообщений
    3,829
    Сказал(а) спасибо
    1,810
    Поблагодарили 934 раз(а) в 796 сообщениях
    Записей в блоге
    1
    Да и экстендеров, которые нужно записывать в config.sys ни разу не встречал)
    Это я про химем, я же писал и про то и про это, но видимо в тексте не понятно.

    Himem.sys никогда не предоставлял функций DPMI-хоста
    Да, значит я что-то перепутал, получается они используют один вектор в разных целях. Забавно, я думал химем обеспечивает данный интерфейс раз сидит на том же векторе, ну чтож невелика потеря, всё равно я этим не пользуюсь, лучше писать программы под Windows и не морочиться управлением защищённым режимом вручную(всмысле настройкой прерываний и всяких там LDT\GDT).
    Спасибо за поправку, я не очень много пользовался этим сервисом, обычно накручивал на Himem EMM386(вот это реальный костыль) и юзал EMS. Да и вообще пришёл к выводу, что самое простое юзать т.н. UNREAL, мы с вами уже это обсуждали в ЛС. В идеале конечно нужно иметь отконфигурированный CONFIG.SYS так, чтобы было и то и то. Может быть как н-ть на досуге займусь и сделаю сборку.

    >Quiet Snow<, было очень интересно прочитать ваше сообщение - чувствуется "тертый калач", ага =)
    Абадябер, мне тоже было интересно почитать ваши посты, зная ваши возможности, на паскале вы вообще жгёте.
    Ответить с цитированием  
     

Информация о теме
Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права
  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •