Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
Сообщение от opennews (??), 01-Фев-24, 16:40
Компания Red Hat опубликовала стабильный релиз пакета  Cygwin 3.5.0, включающего DLL-библиотеку для эмуляции базового Linux API в Windows, позволяющую с минимальными изменениями собирать созданные для Linux программы. В пакет также входят непосредственно собранные для выполнения в Windows стандартные Unix-утилиты, серверные приложения, компиляторы, библиотеки и заголовочные файлы... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60535
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 01-Фев-24, 16:40	+1 +/–
> Разрешён доступ к устройствам консолей (/dev/consN) из процессов, присоединённых к другим консолям или pty-терминалам. Изменение позволило обеспечить возможность запуска в консоли утилит GNU screed и tmux. Либо я что-то не понимаю, либо... короче, я сто лет юзаю msys2 и там tmux всегда работал
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8

2. Сообщение от banonymous (?), 01-Фев-24, 16:47	+5 +/–
Нет поддержки Windows XP? В топку!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #29

3. Сообщение от Аноним (3), 01-Фев-24, 16:58	+1 +/–
Я тоже считаю, что это полное безобразие. Кому он нужен такой? XP x64 прекрасно поддерживает сколько угодно памяти, а также полностью поддерживает unicode. А свои "инновации" ... придержите до лучших времён.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5, #39

5. Сообщение от Аноним (5), 01-Фев-24, 17:18	+2 +/–
Объективно любой код тех времён максимально проблемный. Да-да, в то время как как раз и начали прозревать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #7, #9

7. Сообщение от Аноним (8), 01-Фев-24, 17:31	+2 +/–
Мозг просит подробностей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (8), 01-Фев-24, 17:33	+/–
Держи плюс, приятель. Но по теме, msys и cygwin - это вроде проекты-конкуренты, не? (я не очень в теме)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13, #52

9. Сообщение от Аноним (9), 01-Фев-24, 17:37	+3 +/–
Ты действительно считаешь, что в коде Win 12 меньше проблем чем в семерке?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #11

10. Сообщение от Аноним (10), 01-Фев-24, 17:38	+/–
Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14

11. Сообщение от Аноним (5), 01-Фев-24, 17:50	–1 +/–
> Ты действительно считаешь, что в коде Win 12 меньше проблем чем в > семерке? Всё так. Я действительно считаю, что 12 менее уязвима для малвари и содержит меньше деструктивных багов, таких как рассыпание MFT. А так же 12 более производительна, работает с современным железом, и, не самое последнее, нормально подерживает юникод. Конечно же, современные технологии тоже. Ещё не деградирует так сильно при обновлениях, но это уже не актуально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

12. Сообщение от penetrator (?), 01-Фев-24, 17:52	+3 +/–
я может что-то не понял, но разве нативный код не зависит от хидеров, который есть только в линухе? кто будет это транслировать в Win32 API?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #15

13. Сообщение от Аноним (13), 01-Фев-24, 17:55	+1 +/–
Спс :) Да я тож хз, но мне казалось, что msys2 ющает сингвинские либы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #32, #42

14. Сообщение от Аноним (5), 01-Фев-24, 17:56	+2 +/–
> Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно? Это неэмулятор линукса. Если какой-то софт поддерживает сборку без линукса, то, как правило, он оказывается менее функциональным в таком виде. И с кучей особенностей. В msys2 к примеру, всгда было разделение, что-то можно собрать "нативно", что-то только с прослойкой. А какой-то софт вообще можно собирать не гцц, а майкрософтовскими компиляторами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #49

15. Сообщение от Аноним (5), 01-Фев-24, 17:59	+/–
> я может что-то не понял, но разве нативный код не зависит от > хидеров, который есть только в линухе? кто будет это транслировать в > Win32 API? mingw-w64 как раз и является прослойкой хидеров, сабж дополнительная либа-прослойка неэмулятора линукс и репозитории собранных файлов. Дело не в хидерах, а в недоступных апи в либц венды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #33

16. Сообщение от Mr.Who (?), 01-Фев-24, 18:01	–4 +/–
FreeBSD пишется под macOS, а Linux - под виндой. Всё, что нужно знать о стремлении этих людей делать десктопные ОС.
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 01-Фев-24, 18:07	+/–
>Выпуск примечателен прекращением поддержки Windows 7 И эти туда же. Ну и чем мешало? Опять красношапка со своим запланированным устареавнием. Ничему, что они касаются, доверять нельзя.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #25, #40

18. Сообщение от Аноним (18), 01-Фев-24, 18:22	+3 +/–
В чем проблема обновить древнюю ОС? И что мешает поставить Linux в dual boot, и дальше пользоваться своим nero burning rom, и решать современные задачи?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #24

19. Сообщение от AKTEON (?), 01-Фев-24, 19:14	+4 +/–
Зачем оно, если есть WSL, а там где его нет, теперь нет и Cygwin ??
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21

20. Сообщение от Аноним (20), 01-Фев-24, 19:25	+3 +/–
Да установите уже Linux !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

21. Сообщение от Аноним (21), 01-Фев-24, 19:46	–2 +/–
>там где его нет, теперь нет и Cygwin Не дождетесь, все там есть. WSL нужен детям на ворованной винде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23, #31

23. Сообщение от Аноним (23), 01-Фев-24, 20:08	+1 +/–
Чтобы что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

24. Сообщение от anonymous (??), 01-Фев-24, 20:19	+/–
В том, что виндовс 7 используется как ось для виртуалки, чтобы с минимальными затратами оперативки запускать виндовс-онли программы. Раньше использовалась XP, которая жрала в три раза меньше памяти, но её софт перестал поддерживать. Новая ось в виртуалке нафиг не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #37

25. Сообщение от Аноним (25), 01-Фев-24, 20:58	+/–
Windows 7 официально EoL с 14 января 2020, о чём MS заявила ещё в момент выпуска семёрки. Зачем проекту поддерживать то, что 4 года не поддерживается производителем? И как именно в этом виноват Ред Хат? Не говоря уже о том, что старые версии у тебя никто не отбирает и они дальше будут работать как работали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #30, #46

27. Сообщение от turbodog (-), 01-Фев-24, 21:26	+/–
Желающих пользоваться поделиями фридрисктоп.орг всё меньше и меньше.
Ответить | Правка | Наверх | Cообщить модератору

28. Сообщение от turbodog (-), 01-Фев-24, 21:29	+2 +/–
За это не платят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

29. Сообщение от _kp (ok), 01-Фев-24, 22:27	+2 +/–
Даже простая работа, на уровне консольного приложения, в ХП, 7ке, и 10ке прилично отличается. И даже если без Цигвина желать приложение, то тут или не использовать весьма полезные новшества, или  писать херовое ПО под ОС начала века. Так, пока мы далеко в API не лезли, и речь была и простом консольном приложении. Очевидное решение ограничиться поддержкой Windows10+. (Про Win8.1 понятия не имею)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

30. Сообщение от _kp (ok), 01-Фев-24, 22:30	+1 +/–
Если бы и "поддерживалось", то толку с того, у 7ки API прилично другое. И тут или забить на старое, или игнорировать новое. Выбор очевиден.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

31. Сообщение от Аноним (32), 02-Фев-24, 01:04	+3 +/–
>WSL нужен детям на ворованной винде. WSL спокойно работает из коробки даже в Windows Home Single Language. Ибо начиная ещё с Win10 18xx Hyper-V разделили на 2 части - "платформу виртуализации Windows" (виндовый аналог KVM/Xen), и непосредственно саму Hyper-V (теперь уже как аналог Virt-Manager для этой самой "платформы виртуализации"). И вот первое спокойно работает и на Windows Home, вместе с WSL, Docker Desktop, и прочими плюшками, из коробки, и на 100% легально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #34

32. Сообщение от Аноним (32), 02-Фев-24, 01:09	+/–
>мне казалось, что msys2 ющает сингвинские либы Не совсем. В репозиториях есть разные пакеты, которые зависит от типа рантайма, в котором это добро и запускается. Есть и с сигвиновскими либами, и напрямую скомпиленные под Винду, и даже варианты, собранные через компиляторы от самих мелкомягких (насколько я помню).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

33. Сообщение от penetrator (?), 02-Фев-24, 06:01	+/–
так хидеры фактически описывают таблицу экспорта, те же шары вид сбоку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #35, #43

34. Сообщение от Аноним (34), 02-Фев-24, 08:18	+1 +/–
Порой запускать виртуалку ради запуска небольших приложений не очень хорошая идея
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #41

35. Сообщение от n00by (ok), 02-Фев-24, 08:26	+1 +/–
Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и эмулирует её через memcpy() (или уже передалали на резерв+коммит?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #44

37. Сообщение от фф (?), 02-Фев-24, 09:57	+/–
а зачем вам в виртуалке цигвин? Нельзя обрабатывать ввод/вывод вин-онли программы на хосте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

38. Сообщение от Scalpi (?), 02-Фев-24, 12:48	+/–
Так это  Red Hat разрабы, я то всё думал почему оно на моей машине не заводится. Теперь всё встало на свои места.
Ответить | Правка | Наверх | Cообщить модератору

39. Сообщение от Аноним (39), 02-Фев-24, 16:58	+/–
На всякий случай напомню, что XP всего лишь на три года младше Win98.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

40. Сообщение от Аноним (39), 02-Фев-24, 16:59	+1 +/–
Я вот чего не понимаю. Если вы сидите на системе пятнадцатилетней давности, чем вас не устраивает Cygwin пятнадцатилетней давности?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

41. Сообщение от Аноним (39), 02-Фев-24, 17:00	–1 +/–
Эта «виртуалка» пошустрее сабжа работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

42. Сообщение от Александр (??), 03-Фев-24, 00:49	+/–
Когда-то давно msys отделились от cygwin из-за разных целей. Cygwin в максимальную совместимость, msys в меньшую монструозность. Я думаю с тех времён что-нибудь и осталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

43. Сообщение от Александр (??), 03-Фев-24, 00:51	+/–
Не совсем. Windows не совместим с POSIX. Cygwin и msis - это по сути POSIX подсистема и окружение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #45

44. Сообщение от penetrator (?), 04-Фев-24, 07:08	+/–
> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и > эмулирует её через memcpy() (или уже передалали на резерв+коммит?) системные либы в винде вообще не экспотируют что-то типа mremap там везде паскалевская нотация и два варианта функций с уникодом и без (W / A), а еще STDCALL, там свое апи и ты вообще не туда полез, я говорю что заголовочные файлы для сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе не имеют смысла
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #47

45. Сообщение от penetrator (?), 04-Фев-24, 07:11	+/–
> Не совсем. Windows не совместим с POSIX. Cygwin и msis - это > по сути POSIX подсистема и окружение. строго говоря до Windows 8 там была Microsoft POSIX subsystem, потом воткнули WSL но это вообще никак не связано с тем что я написал изначально
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

46. Сообщение от penetrator (?), 04-Фев-24, 07:13	+/–
> Windows 7 официально EoL с 14 января 2020, о чём MS заявила > ещё в момент выпуска семёрки. Зачем проекту поддерживать то, что 4 > года не поддерживается производителем? И как именно в этом виноват Ред > Хат? Не говоря уже о том, что старые версии у тебя > никто не отбирает и они дальше будут работать как работали. поддерживалась до 1 января 2023 года клиент, и 2024 года сервер 2008 R2, но все за денежку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

47. Сообщение от n00by (ok), 04-Фев-24, 10:58	+/–
>> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и >> эмулирует её через memcpy() (или уже передалали на резерв+коммит?) > системные либы в винде вообще не экспотируют что-то типа mremap там везде > паскалевская нотация и два варианта функций с уникодом и без (W > / A), а еще STDCALL, там свое апи Не надо путать конвенцию вызова (Pascall там нет, в 32-х разрядной Windows была stdcall и в редких случаях fastcall) и предоставляемые системные сервисы (API). Ближайшим аналогом mmap() является NtMapViewOfSection() или обёртка над ней VirtualAllocEx() из Win32 API. То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос, транслятор выдаст рабочий exe-шник, при инициализации процесса он слинкуется с чем надо. C mremap() так просто не получится (работать будет, но не так быстро как в Linux). > и ты вообще не туда полез, я говорю что заголовочные файлы для > сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе > не имеют смысла Не знаю, кто куда полез, но вот первое попавшееся "описание таблицы экспорта" #define malloc(foo) HeapAlloc(GetProcessHeap(), HEAP_NO_SERIALIZE, foo)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #50

48. Сообщение от Аноним (48), 04-Фев-24, 11:06	+/–
В винде давно есть WSL, Cygwin был нужен скорее на 7-ке.
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Аноним (49), 04-Фев-24, 14:01	+1 +/–
Начни читать отсюда: https://ru.wikipedia.org/wiki/POSIX Windows - это не UNIX-подобная ОС. У нее по-другому работает ядро. Причем есть было несколько операционных систем, которые называли Windows. Та из них, которая Windows NT - это скорее VMS-подобная ОС. https://ru.wikipedia.org/wiki/OpenVMS В обоих ОС совместимость с POSIX была всегда сбоку, у них своё юзерспейсное API, своя логика системных вызовов и специфика работы с модулями ядра и шинами данных. То есть API POSIX для Windows NT исторически был модулем ядра, который предлагает альтернативное API. Работал, кстати, из рук вон плохо, потому что Microsoft не писал свою реализацию POSIX в Windows NT, он её зааутсорсил и потом как попало обновлял. Те кому был нужен POSIX на Windows применяли специфические разделяемые библиотеки в пространстве пользователя, а не то барахло, что было в ядре Windows, например тот же Cygwin. Дальше нужно держать в уме 2 тезиса: - Windows (юзерспейсные части ядра, системные службы, Desktop) работает на C++ и в их компиляторе есть поддержка подмножества стандарта языка С99, которое входит в стандарты С++ - POSIX - это стандарт системного API строго для языка С. Вам нужен компилятор языка С на Windows, разделяемые библиотеки С (а не С++) для вашего POSIX-софта, наличие системных вызовов или их трансформация сквозь разделяемые библиотеки того же Cygwin, который это превращает в вызовы Windows NT. Вот зачем он нужен. Затем в какой-то момент времени (клиенты просили docker на Windows) Microsoft снизошел переписывать реализацию POSIX, но ему не нужен был настоящий POSIX, ему нужно было эмулировать системные вызовы конкретно Linux. Так появился WSL и был добавлен вторичный clang как бэкенд для С2-коппилятор. WSL некоторое время был конкурентом Cygwin, потому что в ядро Windows добавили поддержку ELF. Даже перекомпилировать ПО было не нужно, просто ставь свои бинарные библиотеки. Это уже уровень "Wine-наоборот". https://learn.microsoft.com/en-us/shows/one-dev-minute/windo... А потом Microsoft WSL из-за стоимости сопровождения. Гоняться за изменениями в Linux и писать базы совместимости софта для WSL столь же неблагодарное занятие, сколько и то чем занимается Wine/Crossover. Так появился WSL2, который запускает полноценное ядро в виртуальной машине. Только я сразу предупреждаю, не ищите заговора, там чисто технически чудовищный объем тащить WSL. В WSL очень медленное I/O, но быстрые вычисления. В WSL2 наоборот. Для большинства приложений I/O важнее чем скорость исполнения инструкций. Ну и главное нужно понять, что POSIX - это очень старое системное API, которое: - изначально придумывалось для борьбы с зоопарком в мире UNIX - архитектурно оптимизировано для компьютеров, которых больше не производят - ужасно работает с локализацией - имеет плохую поддержку мультитрединга. Современные процессоры с ассиметричными ядрами и NUMA это не про POSIX. pthreads, который появился очень поздно, не часто применяется. Вся архитектура многозадачности вменяет вам shared memory и архитектуру fork-join, где вы порождаете дочерние процессы на каждый чих, https://en.wikipedia.org/wiki/Fork%E2%80%93jo... И вот смена локали в приложении ломает тут абсолютно всё. На современном процессоре, рассчитанном на треды, ядра группируются в кластеры и подключаются к нескольким контроллерам памяти, также внутрь группы добавляеются шины PCI Express - все это создаёт узел NUMA. Архитектура ccNUMA, которая стала повсеместной даже в консьюмерском сегменте ПК не совместимо с концепциями shared memory и fork от слова "совсем", поэтому POSIX как таковой не применяется даже в Linux. Linux - это POSIX-совместимая ОС, но она имеет такое количесвто adhoc-линуксизмов, что код написанный для Linux требует прослойки-линуксатора в другой POSIX ОС. Поэтому поддержка Linux и поддержка POSIX это "две большие разницы". А теперь посмотрите на это с точки зрения разработчика. Если разработчик пишет кроссплатформенное приложение "MyLovelyApp" он может: 1. Создать группу проектов, которые называет одним и тем же именем "MyLovelyApp", но это на самом деле разные программы для разных ОС, которые имеют 80% общей кодовой базы, и 20% ОС-зависимых обвязок. Тогда в каждую ОС нужно собирать такой софт по-разному. Путь Google Chrome, например. 2. Воспользоваться разделяемыми библиотеками и кроссплатформенным компилятором, которые снимут бремя по написанию ОС-зависимого бойлерплейта. Например, это Qt и то подмножество чисто юзеспейсных вопросов, который может msys2, хотя прежде всего речь про mingw. 3. Привязать себя к стандарту POSIX и попытаться сэмулироваться средствами ОС. То есть заставить пользователя поставить поставить POSIX-модули ядра, линуксаторы и прочий WSL. 4. Привязать себя к стандарту POSIX и поcтараться сделать полную эмуляцию всех POSIX функций, которые используются в приложении "MyLovelyApp" даже в ущерб производительности. Это путь Cygwin. Если вам понятнее Wine, то он работает также. Wine - это прежде всего реализация Win32, которая может быть подключена как разделяемая библиотека в юзерспейсе к вашему Windows-специфичному коду. Teamviewer для Linux - хороший пример. То есть cygwin - это wine наоборот. В ядро Wine не лезет и слоем эмуляции в том смысле, в котором это делает та же WSL. Опять же, cygwin можно использовать также как используют пакеты wine в дистрибутивах линукс, сформировать кусочек ОС в префиксе и поставить кучу софта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #51

50. Сообщение от penetrator (?), 04-Фев-24, 19:33	+/–
> в 32-х разрядной Windows была stdcall а в 64 битной по-другому? ясно понятно ))))))) #define WINAPI      __stdcall > То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос это не означает, что не будет таких функций которые нельзя заинлайнить через макрос и им не нужна библиотека A header file is a file with extension .h contains C function declarations and macro definitions. Все что не макрос (константа и бла бла бла), то декларация экспортируемой функции библиотеки, для которой этот хидер файл написан. Азы сей... нах это жевать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #53

51. Сообщение от EULA (?), 05-Фев-24, 07:17	+/–
Никто не мешает через Cygwin сменить права POSIX на файлы в NTFS или процессы, и в итоге System не будет иметь возможности что-то сделать с файлом или процессом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

52. Сообщение от Аноним (52), 05-Фев-24, 16:02	+/–
cygwin опирается на эмуляцию POSIX API под виндой. В нём работает mc, есть каталог /dev, alsa и X11. Что-то похожее на WSL1, только целиком в userspace. msys - это порт линуксовых программ в win32. Для coreutils, make, gcc много не надо. Вызов fork использовать нельзя, а вот open/read/write/close имеются в msvcrt.dll (со своими заморочками). Много чего и в msys "доэмулируется", но масштабы не такие как в cygwin (cygwin претендует на полноценная совместимость с POSIX и Linux). P.S. Чтобы понятнее - msys увидит файл C:\mydir\readme.txt (может и C:/mydir/readme.txt, но так и сама винда много где может), а cygwin увидит что-то типа /mnt/disk_c/mydir/readme.txt.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

53. Сообщение от n00by (ok), 05-Фев-24, 16:42	+/–
>> в 32-х разрядной Windows была stdcall > а в 64 битной по-другому? ясно понятно ))))))) Да как бы не до смеху. Набрать в поисковике "windows 64 calling convention" и прочитать The first four arguments are placed onto the registers. That means RCX, RDX, R8, R9 (in that order) for integer, struct or pointer arguments, and XMM0, XMM1, XMM2, XMM3 for floating point arguments. Additional arguments are pushed onto the stack (right to left). В fastcall использовались первые два регистра из списка. В __stdcall всё идёт через стек. > #define WINAPI      __stdcall Это откуда и к чему? >> То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос > это не означает, что не будет таких функций которые нельзя заинлайнить через > макрос и им не нужна библиотека Я вот реально не пойму, что тут написано. Какая библиотека? Вот реализация стандартной библиотеки плюсов (в т.ч. включает и сишную) https://github.com/icestudent/ontl практически всё header-only, которой нужна только ntdll.dll. Так же возможно и POSIX туда добавить. > A header file is a file with extension .h contains C function > declarations and macro definitions. > Все что не макрос (константа и бла бла бла), то декларация экспортируемой > функции библиотеки, для которой этот хидер файл написан. Азы сей... нах > это жевать? И я не знаю, зачем жевать азы, когда есть стандарт. Там, внезапно, не обнаруживается определение термина "header file". Есть понятие единица трансляции, и директива #include может включать в неё что угодно, лишь бы препроцессор прожевал: 6.10.2 Source file inclusion Constraints 1 A #include directive shall identify a header or source file that can be processed by the implementation.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #54

54. Сообщение от penetrator (?), 05-Фев-24, 22:32	+/–
из виндового SDK, там всегда был __stdcall в сырцах и для 32-битных функций и 64-битных функций, но есть нюанс, который называется Microsoft x64 calling convention When compiling for the x64 architecture in a Windows context (whether using Microsoft or non-Microsoft tools), stdcall, thiscall, cdecl, and fastcall all resolve to using this convention. ----- ну не понимаешь так не понимаешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #55

55. Сообщение от n00by (ok), 06-Фев-24, 07:53	+/–
Не понимаю. Будь добр и объясни, зачем ты мне это пишешь? Напомню, что ты начал с "там везде паскалевская нотация". Намекаешь, что понял свою ошибку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема