Просто WinAPI это трындец какой то. Нельзя на нем писать. И из-за этого существует миллион других библиотек от MFC до VCL-я которые это прячут(у MFC правда это плохо получается).
Кстати по самой статье - я не вижу, что мешает одновремено поддерживать багосовместимость и лепить новый API. Нужно просто сделать новый, а старый эмулировать. Например как Qt сделала, если лень программу переписывать прилинкуй еще одну либу и все, будет чуть тормозней. MS темболее может себе это позволить.
Ну, положим на линуксовых или freebsd'шных syscall'ах тоже никто не пишет. Для этого есть стандартные (и не очень) билиотеки, начиная с libc.
А насчет эмуляции - это, ты, наверное, немножко погорячился. Теоретически это сделать можно, но по объёму работы сопоставимо с написанием windows заново ещё раз.
Я бы не стал WinAPI с syscall-ами сравнивать. Это как раз тот самый glibc. Syscall в Windows тоже выглядит как interrupt + циферка и про них тоже все знают и никто не пишет.
А что делать - у тебя так и будет 20 настроек над WinAPI?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: это ж
Кстати по самой статье - я не вижу, что мешает одновремено поддерживать багосовместимость и лепить новый API. Нужно просто сделать новый, а старый эмулировать. Например как Qt сделала, если лень программу переписывать прилинкуй еще одну либу и все, будет чуть тормозней. MS темболее может себе это позволить.
Re: это ж
А насчет эмуляции - это, ты, наверное, немножко погорячился. Теоретически это сделать можно, но по объёму работы сопоставимо с написанием windows заново ещё раз.
Re: это ж
А что делать - у тебя так и будет 20 настроек над WinAPI?