С помощью этого учебного материала мы научимся писать кросс-платформенный код на Си, используя системные функции популярных ОС (Windows, Linux/Android, macOS и FreeBSD): управление файлами и файловый I/O, консольный I/O, пайпы (неименованные), запуск новых процессов. Мы напишем свои небольшие вспомогательные функции поверх низкоуровневого системного АПИ (API), для того чтобы наш основной код, используя эти функции, мог работать на любой ОС без изменений. Этот учебный материал — начального уровня. Я делю сложные вещи на части, чтобы примеры кода здесь не были слишком заумными для тех, кто только что начал программировать на Си. Мы обсудим различия между системными АПИ и разберёмся, как создать кросс-платформенный программный интерфейс, который скрывает все эти различия от пользователя этого интерфейса.

In this tutorial we'll learn how to write cross-platform code in C using the system functions on popular OS (Windows, Linux/Android, macOS & FreeBSD): file management functions and file I/O, console I/O, pipes (unnamed), execution of the new processes. We're going to write our own small helper functions on top of low-level userspace system API and use them so that our main code can run on any OS without modifications. This tutorial is Level 1, the easiest. I split the difficult stuff into parts so the code samples here shouldn't be overwhelming for those who has just started to program in C. We'll discuss the differences between the system API and how to create a cross-platform programming interface that hides all those differences from the user.

Если ты тоже, как и я, любишь возиться с аудио файликами, слушать, записывать, конвертировать и т.д., то эта статья для тебя. Здесь я расскажу, как можно легко выполнять различные действия с аудио из командной строки, причём делать это одинаково удобно и эффективно и на Линуксах, и на Винде. Для этого мы будем использовать программу fmedia. Она кросс-платформенная и портативная, быстрая и не требует ничего лишнего - в общем, в самый раз для тех людей, кто одержим идеей разумной минималистичности и экономии ресурсов.

В чём в принципе бонус интерфейса командной строки перед графическим?

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

* Во-вторых, любую команду можно исполнять на удалённой машине, подключённой по SSH, например.

* К тому же, такие программы, как правило, гораздо менее требовательны к ресурсам компьютера, а это очень важно когда у нас есть только лишь старенький ноутбук. Или когда мы слушаем музыку на ноуте, работающем на батарее, и требуется продлить его время работы. Например, я на своём ноуте с Федорой могу хоть целый день слушать музыку на батарее через fmedia - реально надолго хватает заряда, главное - погасить экран.

* Нет никаких ограничений на максимальное количество файлов в активном плейлисте. Можно играть плэйлист с тысячей трэков, можно с миллионом - на скорость работы это никак не влияет.

Hearing is one of the few basic senses that we humans have along with the other our abilities to see, smell, taste and touch. If we couldn't hear, the world as we know it would be less interesting and colorful to us. It would be a total silence - a scary thing, even to imagine. And speaking makes our life so much fun, because what else can be better than talking to our friends and family? Also, we're able to listen to our favorite music wherever we are, thanks to computers and headphones. With the help of tiny microphones integrated into our phones and laptops we are now able to talk to the people around the world from any place with an Internet connection. But computer hardware alone isn't enough - it is computer software that really defines the way how and when the hardware should operate. Operating Systems provide the means for that to the apps that want to use computer's audio capabilities. In real use-cases audio data usually goes the long way from one end to another, being transformed and (un)compressed on-the-fly, attenuated, filtered, and so on. But in the end it all comes down to just 2 basic processes: playing the sound or recording it.

Today we're going to discuss how to make use of the API that popular OS provide: this is an essential knowledge if you want to create an app yourself which works with audio I/O. But there's just one problem standing on our way: there is no single API that all OS support. In fact, there are completely different API, different approaches, slightly different logic. We could just use some library which solves all those problems for us, but in that case we won't understand what's really going on under the hood - what's the point? But humans are built the way that we sometimes want to dig a little bit deeper, to learn a little bit more than what just lies on the surface. That's why we're going to learn the API that OS provide by default: ALSA (Linux), PulseAudio (Linux), WASAPI (Windows), OSS (FreeBSD), CoreAudio (macOS).

Было бы здорово иногда иметь под рукой программку, которая в наше отсутствие умеет записывать звук со встроенного микрофона нашего ноутбука и передавать его по сети на другой наш комьютер. А тот, в свою очередь, этот звук умел бы воспроизводить в режиме реального времени. Давай попробуем самостоятельно написать такую программу, тем более что это, как оказывается, не так уж и сложно.

Что мы в итоге хотим получить и какой алгоритм работы реализовать:

1. Сервер, который запускается на той машине, пространство вокруг которой мы хотим прослушивать. Он тихо ждёт, пока к нему не подключится клиент. Затем он открывает устройство записи звука, настроенное по умолчанию в системе, и начинает передавать аудио поток на машину клиента. При отключении клиента от сервера, звуковое устройство закрывается, чтобы не тратить ресурсы зря.

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

When talking about high-performance software we probably think of server software (such as nginx) which processes millions requests from thousands clients in parallel. Surely, what makes server software work so fast is high-end CPU running with huge amount of memory and a very fast network link. But even then, the software must utilize these hardware resources at maximum efficiency level, otherwise it will end up wasting the most of the valuable CPU power for unnecessary kernel-user context switching or while waiting for slow I/O operations to complete.

Thankfully, the Operating Systems have a solution to this problem, and it's called kernel event queue. Server software and OS kernel use this mechanism together to achieve minimum latency and maximum scalability (when serving a very large number of clients in parallel). In this article we are going to talk about FreeBSD, macOS and kqueue, Linux and epoll, Windows and I/O Completion Ports. They all have their similarities and differences which we're going to discuss here. The goal of this article is for you to understand the whole mechanism behind kernel queues and to understand how to work with each API.

I reinstalled both Windows and Linux (Fedora) recently on a notebook PC, and I decided to write the summary article about my experience with both OS. I'm also going to describe how to configure each OS via command-line and set up a dual-boot system.