Названия системных функций

High-level languages programming questions
  • CleverMouse wrote: NASM-овцам это не помешало определить свои имена.
    Правильно и сделали! Вот правда, они привязывали имена к числовым значениям.
    А я подразумевал привязку имён к макросам (процедурам, функциям).
    Правильно ли я делаю ?!
    Например :
    приставка для длинного имени "fk" (маленькие и без всяких нижних чёрточок, думаю так аккуратней будет сочитаться с началом процедуры которое с большой буквы). Кстати какую приставку предлагаете вы?
    Все функции, которые "прямые", их названия начинаются = "fk"+короткое имя функции.
    Например, короткое имя "PutPixel" Тогда, длинное имя = fkPutPixel и соответственно
    fkPutPixel = mov eax, 1 int 0x40
    и так каждая процедура (с длинным именем), везде в СИ, АСМе, Дельфи и т.д. это длинное имя соответствует такому "прямому" вызову с такой же передачей параметров!
    Далее идет короткое имя PutPixel, (функция, процедура, макрос, неважно что иммено), котораям по своей сути полная аналогия fkPutPixel, вот только с усовершенствованным , приёмом-передачей данных т.е. PutPixel( Dword x, Dword y, Dword colour )
    И как будет реализована PutPixel внутри, вот так:

    Code: Select all

    {
    	__asm{
    		mov eax, 1
    		mov ebx, x
    		mov ecx, y
    		mov edx, colour
    		int 0x40
    	}
    }
    
    ... или используя fkPutPixel, значит вот так:

    Code: Select all

    {
    	__asm{
    		mov ebx, x
    		mov ecx, y
    		mov edx, colour
    		fkPutPixel
    	}
    }
    
    ЭТО, КАК ВИДИТЕ, БЕЗ ОСОБОЙ РАЗНИЦЫ! Тем более для компиляторов, верно ?
    Главная цель этого всего, то, что функции:
    fkPutPixel и PutPixel аналогичны, с разницей лишь в передачи данных! Ну понятное дело, что базируется PutPixel на fkPutPixel . И что в любой среде программирования, я могу использовать любую из них ( хоть fkPutPixel, хоть PutPixel, хоть чередуя, в зависимости от ситуации), а написанное в одной среде смогу "безболезненно", "перебрасывать" в другую среду!
    Я надеюсь вы уловили мою мысль!? Т.е. полная стандартизация процедур, по всем средам и "прямых" процедур с длинным именем и с коротким именем, базирующихся на тех "прямых" процедурах. И к тому же, зная короткое имя процедуры, мы знаем на какой процедуре с длинным именем она базируется (добавив к началу названия "fk") и наоборот.
  • CleverMouse wrote: Сокращать слово Background, учитывая, что в большинстве приложений эти функции вообще не нужны, и даже там, где нужны, они вряд ли встречаются в десяти разных местах кода, - довольно странная идея.
    Ну я бы не сказал, что это идея..... :-) Я С ТОБОЙ ВПОЛНЕ СОГЛАСЕН, в том, что чем реже используется процедура тем, имя её может быть чуть ли не целым предложеним! :-) Я просто не вник, насколько какая процедура может часто использоваться!

    CleverMouse wrote: Название GetPixel/SetPixel большинство программистов поймут даже без документации, расходовать дополнительные усилия мозга на запоминание, что здесь оно называется каким-то странным термином Pxl или Pix, означает отвлечь эти усилия от чего-то более важного.
    ЕЩЕ РАЗ ВЫДЕЛЮ:
    CleverMouse wrote: Название GetPixel/SetPixel большинство программистов поймут даже без документации,
    CleverMouse, так я такое и хочу! Я такого и добиваюсь! Т.е. назание не должно быть сильно растанутое, ну зачем ? Оно должно быть сокращено до понимания (без документации). Я не изобретаю велосипед! И как по мне, так, что GetSizeScreen, что GetScreenResolution
    GetScrRes (GetResScr)
    или ( SetSizeScreen и BackgroundSetResolution), извините за выражение, - один хрен! Я просто хочу, чтобы мы совместоно "узаконоли" :-) какой именно "набор букв" должен быть у имени, чтобы это никому "не резало" глаза или слух! Ну, как видишь, есть такие кому режет, такое как GetSizeScreen ! :-)
  • А почему экран в одном случае называется screen а в другом background?
    Я имею ввиду функции GetScreenResolution и BackgroundSetResolution.
  • Pathoswithin wrote: В принципе, ничего не мешает и для ассемблера сделать .inc в котором названия равны цифрам, тогда первым параметром в mcall можно будет писать имя. Хотя мне цифры больше нарвятся.
    Да дело не в том, чтобы сделать имена константами, см. здесь: viewtopic.php?f=33&t=3202&start=15#p63343
    Pathoswithin wrote: Насчёт длины имени можно сильно не беспокоится, сейчас в моде редакторы с автозавершением, а у консерваторов есть ctrl-c/ctrl-v. Но вот использовать сокращения точно не стоит, сам много раз не мог понять названия меток.
    Согласен, что не надо сильно беспокоится за длину, но извени меня, аббривеатура состоящая из 30 символов, помоему это уже слишком! Задолбёшься читать! :-) Да и полэкрана занимает при применении в коде.
    Pathoswithin wrote: Мои предложения:
    По возможности учёл. См. ниже. Но Background "затолкал" в конец аббривиатуры, sysfuncs.txt так советовал :-) да и мне это словечко (по длине и набиранию его на клавиатуре) не очень-то нравится. :-)
    А если серьёзно, то как я писал, что название должно начинаться с дейстивия, т.е. Set, Get, Draw и т.д.
    Pathoswithin wrote: Background = 15
    .SetSize = 1
    .PutPixel = 2
    .Refresh = 3
    .SetMode = 4
    .PutImage = 5
    .Map = 6
    .Unmap = 7
    Точки применять не нужно, так как не во всех средах, они могут быть в составе имени константы или переменной. В дельфи точки обращения к полям типа(Type record) или к полям объекта
    .....
    TForm1 = class(TForm)
    mmo1: TMemo;
    ........
    обращение например mmo1.Lines.Add(s )
    Pathoswithin wrote: Сверяйся с английскими названиями из sysfuncs.txt, и далее в том же духе.
    А вот это хорошее предложение от CleverMouse и от тебя по поводу sysfuncs.txt !
    Уже сверил! :-) Выкладываю, поправленную в основном по sysfuncs.txt!
  • IgorA wrote:А почему экран в одном случае называется screen а в другом background?
    Я имею ввиду функции GetScreenResolution и BackgroundSetResolution.
    Всё рассматриваем, правим. Вот сейчас заново выложу! Спасибо за замечания! Обязательно принимай участие далее! Хорошо ? :-)
  • ALEXS1983 wrote:Далее идет короткое имя PutPixel, (функция, процедура, макрос, неважно что иммено)
    Не надо коротких имён. У них слишком большой шанс совпасть с чем-то уже существующим. В достаточно большой программе может запросто уже оказаться функция с именем GetKey, которая наверняка не будет совпадать с интерфейсом системной функции Колибри. В Windows, к примеру, есть макрос GetMessage, и он постоянно даёт проблемы при переносе программ с Linux, которые решили определить свою функцию GetMessage, для целей, никак не связанных с сообщениями Windows. Вот, например, навскидку.
    Сделаем мир лучше!
  • Проверяем еще раз. Первый блок, - функции с 01-10 .
    Второй, - с 11-18.
    Да будем уже "двигать" далее. Функций еще предостаточно! :-)
    При желании сильно "заморочится" :-) на каком-то названии, - найдётся на чём! :-)
    Spoiler:CreateWindow - Функция 0 - определить и нарисовать окно.
    PutPixel - Функция 1 - поставить точку в окне.
    GetKey - Функция 2 - получить код нажатой клавиши.
    GetSysTime - Функция 3 - получить системное время.
    DrawText - Функция 4 - вывести строку текста в окно
    Pause - Функция 5 — пауза.
    old_ReadFileRD - Функция 6 - прочитать файл с рамдиска
    PutImage - Функция 7 - вывести изображение в окно
    DefineButton - Функция 8 - определить/удалить кнопку.
    ProcessInfo - Функция 9 - информация о потоке выполнения.
    WaitEvent - Функция 10 - ожидать события
    Spoiler:CheckEvent - Функция 11 - проверить, есть ли событие, без ожидания.
    BeginDrawWindow - Функция 12 - Подфункция 1 - начать перерисовку окна.
    EndDrawWindow - Функция 12 - Подфункция 2 - закончить перерисовку окна
    DrawRec - Функция 13 - нарисовать прямоугольник в окне
    GetScreenSize - Функция 14 - получить размеры экрана.
    SetSizeBackground - Функция 15, подфункция 1 - установить размер фонового изображения
    PutPixelBackground - Функция 15, подфункция 2 - поставить точку на фоновом изображении.
    RedrawBackground - Функция 15, подфункция 3 - перерисовать фон.
    SetModeBackground - Функция 15, подфункция 4 - установить режим отрисовки фона.
    PutImageBackground - Функция 15, подфункция 5 - поместить блок пикселей на фон.
    MapBackground - Функция 15, подфункция 6 Спроецировать данные фона на адресное пространство процесса.
    UnmapBackground - Функция 15, подфункция 7 Закрыть проекцию данных фона на адресное пространство процесса.
    RDtoFloppy - Функция 16 - сохранить рамдиск на дискету.
    GetButton - Функция 17 - получить код нажатой кнопки.
    TerminatProcessThread - Функция 18, подфункция 2 - завершить процесс/поток по слоту.
    ActiveWindowThread - Функция 18, подфункция 3 - сделать активным окно заданного потока.
    GetTactsSec - Функция 18, подфункция 4 - получить счётчик пустых тактов в секунду.
    GetCPUclockRate - Функция 18, подфункция 5 - получить тактовую частоту.
    RDtoHDD - Функция 18, подфункция 6 - сохранить рамдиск в файл на жёстком диске.
    GetNumbActiveWindow - Функция 18, подфункция 7 - получить номер активного окна.
    Speaker - Функция 18, подфункция 8 - отключить/разрешить звук спикера.
    InfoSpeaker - Функция 18, подфункция 8 - отключить/разрешить звук спикера. Подподфункция 1 - получить состояние
    SwitchSpeaker - Функция 18, подфункция 8 - отключить/разрешить звук спикера. Подподфункция 2 - переключить состояние.
    ShutdownSysParam - Функция 18, подфункция 9 - завершение работы системы с параметром.
    WindowMinimize - Функция 18, подфункция 10 - свернуть окно приложения.
    InfoDiscSubSys - Функция 18, подфункция 11 Получить информацию о дисковой подсистеме.
    VerKernel - Функция 18, подфункция 13 - получить версию ядра.
    waitScreenRetrace - Функция 18, подфункция 14 Ожидать начала обратного хода луча развёртки монитора.
    CursorMouseCentrScreen - Функция 18, подфункция 15 - поместить курсор мыши в центр экрана
    GetSizeFreeRAM - Функция 18, подфункция 16 Получить размер свободной оперативной памяти.
    GetSizeFullRAM - Функция 18, подфункция 17. Получить размер имеющейся оперативной памяти.
    TerminatProcessThreadID - Функция 18, подфункция 18 Завершить процесс/поток по идентификатору.
    GetMouseSpeed - Функция 18, подфункция 19 - получить/установить настройки мыши. Подподфункция 0 - получить скорость мыши.
    SetMouseSpeed - Функция 18, подфункция 19 - получить/установить настройки мыши. Подподфункция 1 - установить скорость мыши.
    GetMouseDelay - Функция 18, подфункция 19 - получить/установить настройки мыши. Подподфункция 2 - получить задержку мыши.
    SetMouseDelay - Функция 18, подфункция 19 - получить/установить настройки мыши. Подподфункция 3 - установить задержку мыши.
    SetMousePos - Функция 18, подфункция 19 - получить/установить настройки мыши. Подподфункция 4 - установить положение курсора мыши.
    SimulMouseKey - Функция 18, подфункция 19 - получить/установить настройки мыши. Подподфункция 5 - симулировать состояние клавиш мыши.
  • CleverMouse wrote:
    ALEXS1983 wrote:Далее идет короткое имя PutPixel, (функция, процедура, макрос, неважно что иммено)
    Не надо коротких имён.
    В данном контексте ты не правильно понял смысл.
    Я там писал про то, что существует функция, макрос, процедура, не важно что это! И как его не назови она считается (в том контексте) коротким именем! А длинным именем (в том контексте) считается = fk+короткое имя....
    Другими словами:
    приставка к имени "fk"
    Короткое имя: PutPixel
    длинное имя: fkPutPixel

    Короткое имя (PutPixel) , - (одна)процедура явно приближённая к СИ и дельфи по способу приёма-передачи данных вот таком виде: т.е. PutPixel( Dword x, Dword y, Dword colour )
    Длинное имя (fkPutPixel) - (другая) процедура, использующая "прямой" доступ к сис.функциям КОС, т.е. вот так вот = mov eax, 1 int 0x40
  • Ребята, ну неужели я недоступно объяснил насчёт процедур с короткими и длинными именами ?!
    Ну вот пример, на дельфи, может так поймёте:
    Spoiler:

    Code: Select all

    unit KOSystem;
    
    interface
    {параметры процедуры  (w,d,e,r,f:Cardinal); - "отфонарные", как пример!!  }
    
    {Прямые процедуры КОС, к имени которых добавлена приставка "fk"
    поетому называю их с длинным именем по сравнению с теми, которые без
    этой приставки }
    Procedure fkCreateWindow;  //- Функция 0 - определить и нарисовать окно.
    Procedure fkPutPixel; //- Функция 1 - поставить точку в окне.
    Procedure fkGetKey; //- Функция 2 - получить код нажатой клавиши.
    
    { Процедуры с коротким именем, по сравнению с теми процедурами,
    у которых есть приставка "fk" эти процедуры используют
    аналогичные процедуры "fk"+"своё короткое имя" см. в теле процедуры
    }
    Procedure CreateWindow(w,d,e,r,f:Cardinal); //- Функция 0 - определить и нарисовать окно.
    Procedure PutPixel(w,d,e,r,f:Cardinal); //- Функция 1 - поставить точку в окне.
    Procedure GetKey(w,d,e,r,f:Cardinal); //- Функция 2 - получить код нажатой клавиши.
    
    implementation
    Procedure fkCreateWindow; INLINE;{INLINE применять при необходимости,
                                   INLINE - это значит процедура ведёт себя как макрос }
    begin asm
    mov eax,0
    int $40
    end end;
    
    Procedure fkPutPixel; INLINE;{INLINE применять при необходимости,
                                   INLINE - это значит процедура ведёт себя как макрос }
    begin asm
    mov eax,1
    int $40
    end end;
    
    Procedure fkGetKey; INLINE;{INLINE применять при необходимости,
                                   INLINE - это значит процедура ведёт себя как макрос }
    begin asm
    mov eax,2
    int $40
    end end;
    
    
    Procedure CreateWindow(w,d,e,r,f:Cardinal); //- Функция 0 - определить и нарисовать окно.
    begin
    {......................}
    fkCreateWindow;
    end;
    
    Procedure PutPixel(w,d,e,r,f:Cardinal); //- Функция 1 - поставить точку в окне.
    begin
    {......................}
    fkPutPixel;
    end;
    
    Procedure GetKey(w,d,e,r,f:Cardinal); //- Функция 2 - получить код нажатой клавиши.
    begin
    {......................}
    fkGetKey;
    end;
    
    end.
    
    
    Procedure fkCreateWindow; //- Функция 0 - определить и нарисовать окно.
    Procedure fkPutPixel; //- Функция 1 - поставить точку в окне.
    Procedure fkGetKey; //- Функция 2 - получить код нажатой клавиши.

    Procedure CreateWindow(w,d,e,r,f:Cardinal); //- Функция 0 - определить и нарисовать окно.
    Procedure PutPixel(w,d,e,r,f:Cardinal); //- Функция 1 - поставить точку в окне.
    Procedure GetKey(w,d,e,r,f:Cardinal); //- Функция 2 - получить код нажатой клавиши.

    Вся соль в том, что можно применять и одни и другие процедуры в программе!
    С именами не запутаешься, так как приставка к имени одна для всех "fk"!
    Мысленно "перекиньте" этот модуль на другие языки программирования.
    А также мысленно "перекиньте" программу которая использует любые из этих процедур!
    Перекинутая программа, будет работать "как часики" в других средах!
    Но вот в других средах возможно реализация внутренностей тех процедур другая.
    В эмуляторах и визуализаторах ведь прямые (mov eax,... int $40) процедуры, будут не такие уж прямые! А всё таки искусственно созданные! Т.е. "эмулирующие прямоту" (mov eax,... int $40)! Но программа ведь должна и там работать "как часики"!
    Вот от чём я толдычу!
  • Что это за ужас? У тебя получилось больше кода, чем на ассемблере.
    Для примера вида helloworld -- возможно. Но в перспективе, ООП подход даст куда меньший код и высокую скорость разработки. Если обратишь внимание, то в коде не задается ни текущее положение виджета (кнопки) т.к. оно выставляется автоматически layout-менеджером, ни нативной обработки сообщений. А совсем для фанатов, можно сделать кроссплатформенный код.

    Add:
    Если сделать универсальный фреймворк, то основная часть кода будет лежать в библиотеках. А в самих программах будут только специфичные функции. А сейчас из-за того что каждая программа сама рисует свой интерфейс попиксельно, то соответственно и размер кода раздут
    А почему экран в одном случае называется screen а в другом background?
    Я имею ввиду функции GetScreenResolution и BackgroundSetResolution.
    Первая возвращает именно физическое разрешение. Вторая - разрешение картинки десктопа. В современных осях эти параметры могут быть совершенно разными. Хоть сейчас и не поддерживается, но мониторов может быть несколько, и на каждом может быть свое разрешение и своя обоина, или общая

    Все выше сказанное мое личное имхо
  • CleverMouse wrote:Не надо коротких имён. У них слишком большой шанс совпасть с чем-то уже существующим. В достаточно большой программе может запросто уже оказаться функция с именем GetKey, которая наверняка не будет совпадать с интерфейсом системной функции Колибри. В Windows, к примеру, есть макрос GetMessage, и он постоянно даёт проблемы при переносе программ с Linux, которые решили определить свою функцию GetMessage, для целей, никак не связанных с сообщениями Windows. Вот, например, навскидку.
    Вот еще о чём забыл сказать:
    Вот я писал:
    viewtopic.php?f=33&t=3202#p63326
    Также есть мысля, что должно быть альтернативное (запасное) имя на случай, так или иначе, невозможности использования какого-то имени в какой-то среде программирования. Т. е. опять же утвердить приставку (или несколько) к альтернативному имени, например «a» и/или «a_”, и все прекрасно будем знать и понимать, что если остсутсвует имя PutPixel, то есть альтернативное aPutPixel (или a_PutPixel). Ну для начала давайте решим нужно ли альтернативное имя вообще ? Если да, то сколько и какие приставки должны быть к имени
    Поэтому, если я использую в какой-то среде GetKey и GetMessage и явно вижу и понимаю, что-то не то происходит, т.е. не те процедуры КОСа вызываются какие надо, то я лёгки движением руки.... перехожу на альтернативное (запасное) имя т.е. вот так: (aGetKey и aGetMessage) или вот так (а_GetKey и а_GetMessage) в зависимости от приставке альтернативности которую утвердить "а" или "а_" или обе или в конец процедуры "_" и проблема решается моментально! Да и процедура внешний вид не теряет! Думаешь, при таком подходе слишком большой шанс совпасть с чем-то уже существующим ?
    Тоже самое и программист "перебивая" модуль под ту систему будет знать, что GetKey и GetMessage в таком виде создавать нельзя, надо имя менять. - ну вот уже утвержено, что если не GetKey, то aGetKey или a_GetKey или GetKey_, - и думать никому не над чем не надо если сразу продумано, по какому принципу должны создаваться альтернативы!
    CleverMouse, я, конечно могу излагаться в каком-то явно "перекошенном" виде, но вдумайся, ведь я не чепуху несу! Здравой логикой вдумайся, а не вспоминая, что кто-то практикует так или не практикует! Можно же заблаговременно рассчитать возможные ситуации и накладки с именами! Даже если сейчас, нет накладки на какой-то процедуры, то "завтра" выйдет "виндовс двенадцатка" и она может появится! А предусмотрев альтернативные имена процедур (причём не одну, а несколько), - ну это надо только исключительно нацелится кому-то на вредительство, чтобы "обламать" все предусмотренные альтернативы!
  • Насчёт альтернативных имён.
    Короче :) если нет возможности применять или создавать или еще чего-то какому-то имени,то, например
    GetMessage - нельзя?!
    альтернатива, - GetMessage_ - тоже нельзя ?!
    еще альтернатива, - GetMessage_a - и эту нельзя ?!
    еще альтернатива, - GetMessage_b - ну кроче, :-) символов хватит! :-)
    И при этом все знают, что если не работает план "А", то к какому плану переходим?...
  • Не забудьте все заглянуть сюда viewtopic.php?f=33&t=3202&start=15#p63349 :-)
  • Вообще-то я и предлагал, чтобы Background была структурой с полями.
    DrawRect = 13
    System = 18
    .DeactivateWindow = 1
    .TerminateThread = 2
    .ActivateWindow = 3
    .GetIdleCount = 4
    .GetCPUFrequency = 5
    .RDtoHDD = 6
    .GetActiveWindow = 7
    .SpeakerState = 8.1
    .SpeakerToggle = 8.2

    .KernelVersion = 13
    .WaitRetrace = 14
    .CursorReset = 15
    .GetFreeRAM = 16
    .GetTotalRAM = 17
    .TerminateThreadID = 18

    Общее правило английского языка: сначала "чего?", потом "что?". Либо kernel version, либо version of the kernel.

    Обновил документацию по 18.19.

    Буква А в конце названия обычно означает ascii версию функции, W в конце — UTF-16.
  • Who is online

    Users browsing this forum: No registered users and 4 guests