стоп, а разве в c++ нету способов указать порядок наследования при множественном базовом классе, ну это, виртуальный базовый класс разве не решает? а не
хм

(Reply to this) (Thread)

ваще-т порядок наследования в исходниках не налагает на внутреннее представление никаких ограничений. мало ли, как я себе унутре захочу это дело делать? хоть копированием vmt, хоть кучей указателей в любом порядке, хоть хером лысым. лишь бы компилятор сгенерил правильный код в итоге.

(Reply to this) (Parent)

Я не особо давно сам использовал недокументированные особенности, так как API не позволяло делать банальные вещи. Ну, это не ядро Окон было, но всё-таки встроенная в систему микрософтовская хрень.

Но твоей мысли я не понял.

(Reply to this) (Thread)

тут две мысли. первая — смехотворность отмазок:
«And, as Larry noted, this would prevent us from ever changing the structure.»
ага. про эмуляторы старых апей мы не в курсе. потому что нормального, блядь, механизма наподобие LD_SO_PRELOAD за 20 лет так и не придумали. молодцы.

«There are some settings which intentionally have no API because that would allow bad people to manipulate them.»
это ещё гениальней. «bad people» расковыряют, что им надо, без особого труда. а нормальные люди будут ебстись в гамаке, стараясь не наебнуться.

«Changing it on the fly would mean having to replace one object with the other on the fly.»
угу. как будто это кого-то ебёт, окромя аффтараф контрола (внутренности которого хуй наружу торчат всё равно). ну и замените у себя там внутри, блядь — хуле МЕНЯ должно ебать, как что у вас там сделано, если оба контрола даже называются одинаково, отличие только в одном ФЛАГЕ. не другое имя, не другой апи — один флаг, бля. сделали такую «маскировку»? молодцы, доведите дело до конца. мудачьё.

«Changing LBS_SORT on the fly means that you can create inconsistent data structures: The listbox thinks it's sorted (and therefore can use binary search and other optimizations) when in reality it isn't sorted (because you started with an unsorted listbox and then flipped the LBS_SORT bit).»
дададада. сортирнуть список по смене флажка — это rocket science, по-любому.

короче, пидарасы и мудачьё.


а по поводу ядра — это свосем другой скандал, с Аланом Коксом и уходом Алана с поста майнтайнера tty.

(Reply to this) (Parent) (Thread)

А про ядро дашь ссылку?

В общем-то, я не понимаю, причём тут открытые исходники и т.п.: добавлять новые структуры в чужую библиотеку очень мило, но только в упоминаемых случаях придётся обновлять её до конца жизни и всё такое.

Про "bad people": механизмы защиты есть какие-то, когда требуется самоличный ввод данных пользователем. Делать для них API странно. Какие-то такие моменты должны быть (пока "bad people" не пробрались на уровень ядра, например).

Ну а виноваты в исходных примерах, по моему:
а) 100% дефрагментаторы, потому что целостность данных много важнее дополнительной дефрагментации "для красоты"
б) 100% херакеры, потому что если не нравится, можно и другую оболочку нарисовать
в) 100% херакеры
(Недаром он сам примеры привёл.)

А про изменение стиля и LBS_SORT отмазки нелепые, конечно.

Но рассуждения про "in real life" довольно показательны: эта стратегия у них работает же.

Про API я бы вот что добавил: если прилагаемые к ОС программы (не само ядро, в каком-то умеренно широком смысле) или какой-нибудь МС Офис используют недокументированные возможности для получения функциональности, то это повод и самим их использовать, если получиться, но, главное, если возможно, за злоупотребление монополией засудить или хотя бы бить в барабаны.

(Reply to this) (Parent) (Thread)

>обавлять новые структуры в чужую библиотеку очень мило
это ИХ библиотеки.

>но только в упоминаемых случаях придётся обновлять её до конца жизни и всё такое.
держать себе слой эмуляции. а потом выкинуть.

>Про "bad people": механизмы защиты есть какие-то, когда требуется самоличный
>ввод данных пользователем.
ага. там речь шла, емнип, про то, что юзер из гуёв может модем выбрать, а софтине API для этого не дали. и делался простой вывод: «всё, что можно сделать из официальных гуёв, должно иметь официальное API». на что начали бредить про «плохих парней».

>Ну а виноваты в исходных примерах, по моему:
m$, m$, идиот-программер.

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

>А про ядро дашь ссылку?
на говнонет.

(Reply to this) (Parent) (Thread)

держать себе слой эмуляции. а потом выкинуть.
Ну, в Просеке сделали что-то: http://www.winvistaclub.com/f16.html
Так как-то проверять версию, таскать за собой нужные версии dll-лек и т.п. тоже можно.

И как это решило бы проблемы 1 (дефрагментацию) и 2 (изменение внешнего вида основной программы, к тому же системной)? (В проблеме 3, конечно, достаточно простое решение было и без хаков.)

на что начали бредить про «плохих парней»
Ну да. Есть и "плохие парни" (когда отсутствие API оправданно), и полные лакун API. И то, и то. Отмазка такая, перевод темы.

как вечный двигатель
Перераспределяет деньги в нужном владельцам Микрософта направлении.

(Reply to this) (Parent) (Thread)

>Ну, в Просеке сделали что-то
WinSxS — это совсем другая песня.

>И как это решило бы проблемы 1 (дефрагментацию)
очень просто: дали бы нормальное описание структур и нормальный API — никто бы не лазил корявыми пальцами в кишки.

>2 (изменение внешнего вида основной программы, к тому же системной)
дали бы нормальный API… ну, ты понял.

(Reply to this) (Parent) (Thread)

очень просто: дали бы нормальное описание…
По-моему, в GPL ничего не написано о том, что разработчик даёт подробное описание структур, нормальный API и гарантию совместимости.

WinSxS — это совсем другая песня.
Ну, для хранения предыдущих версий библиотек же используется, чтобы можно было их вызывать при необходимости (что при штуках типа дефрагментации, конечно, не помогает).

(Reply to this) (Parent) (Thread)

>По-моему, в GPL ничего не написано о том, что разработчик даёт подробное описание
>структур, нормальный API и гарантию совместимости.
там дают исходники. постольку пидарасы из m$ исходников не дают — пусть дают нормальный API и описания.

>Ну, для хранения предыдущих версий библиотек же используется
потому что в m$ — идиоты. сделать версионность нормально, как в том же пингвине — тупо приписав версию в конец библиотеки и символическую ссылку — не судьба. да и дать нормальный инструмент «перекрытия» библиотек — тоже. идиоты ибо.

(Reply to this) (Parent) (Thread)

там дают исходники.
Ну и что? Ситуация с дефрагментацией такая же тогда вполне возможна.

да и дать нормальный инструмент «перекрытия» библиотек
С дефрагментацией это не помогло бы.

"Перекрытие" библиотек помогает, если программа всё в себе делает. А если ты с помощью библиотеки работаешь с устройством, то запросто может получиться, что старая библиотека с ним просто не может работать вообще.

(Reply to this) (Parent) (Thread)

>Ну и что? Ситуация с дефрагментацией такая же тогда вполне возможна.
нет. потому что в исходниках есть API. соответственно, или API не поменялся, и тогда похуй, или API поменялся, и тогда софтина просто не соберётся.

>С дефрагментацией это не помогло бы.
см. выше.

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

(Reply to this) (Parent) (Thread)

нет. потому что в исходниках есть API. соответственно, или API не поменялся, и тогда похуй, или API поменялся, и тогда софтина просто не соберётся.
В исходниках есть API. Но нет такого, которое позволяет перемещать упомянутые виды файлов. Зная исходники (или поковырявшись с отладчиком, что не сильно отличается), граждане реализуют операцию с помощью низкоуровневых команд. А в новой версии такая комбинация вызовов низкоуровневых команд приводит к другому результату (сбою и потере данных).

(Reply to this) (Parent) (Thread)

>А в новой версии такая комбинация вызовов низкоуровневых команд приводит к
>другому результату (сбою и потере данных).
вывод: автор кода фс — мудак и гондон, чо ниясна-та? что ломаешь — ломай так, чтобы с новым кодом или не собиралось старое, или собиралось, но падало до того, как успеет что-то изгадить.

(Reply to this) (Parent) (Thread)

А причём тут файловая система? Низкоуровнево что-то писать на диске (в нужный сектор, например) — ясно, что где-то такая возможность должна даваться (чтобы разбивать на разделы, форматировать, чтобы сама файловая система была реализована). Если её используют для обхода ограничений файловой системы (начитавшись исходников, предположив, что где находится), то при чём тут разработчик файловой системы?

(Reply to this) (Parent) (Thread)

а при том, что работаем мы с FS. не поверишь. и у нас — в случае GPL — есть исходники FS. а в них — снова не поверишь — API. которое избавляет от писанины по секторам.

(Reply to this) (Parent) (Thread)

Ну да, сложно же понять, что я пишу: и API не предусматривают некоторых возможностей. Тогда умники узнают что-то с помощью API, рассчитывают по старым внутренним формулам (прочитанным из исходников или с помощью отладки), а далее пишут в сектора, адресуются по какому-нибудь номеру, предполагая, что по нему обязательно находится именно то-то и т.п.

GPL не гарантирует наличие API со всеми прибамбасами (и без глюков). Ситуация не отличается принципиально от Окон.

(Reply to this) (Parent) (Thread)

тогда они проверяют версию FS. с описаным дефрагментатором ситуация другая: версия FS не поменялась.

так, для информации: любая FS имеет внутреннее апи для лочки. если бы m$ это давали — дефрагментатор «залочил» бы FS, сделал, что надо, и «разлочил». но…

(Reply to this) (Parent) (Thread)

Ага, конечно: версия ОС-то изменилась.

Если можно "лочить", то разумнее запустить дефрагментацию вообще без запуска всевозможного ПО и самой ОС. Такие дефрагментаторы, насколько я помню, тоже были (под Окна-95/98/ME — естественно, с ядром NT — не знаю).

Но тут-то дефрагментатор хотел "по-живому" резать. И текст не свидетельствует о том, что с блокированием операции бы удались: утверждалось, что из-за неверных предположений о расположении или строении структур данных, данные программой портились.

Мне как программисту под Окна конечно забавно, что ты выдаёшь индульгенции тем, кто пишет сколь угодно безумно, сваливая всю вину на МС.

(Reply to this) (Parent) (Thread)

>Ага, конечно: версия ОС-то изменилась.
и что? у меня вот ядро кучу версий сменило, а raiserFS как работала — так и работает, ничего не сломалось. чудо, правда?

>утверждалось, что из-за неверных предположений о расположении или строении
>структур данных, данные программой портились.
внимательно почитай:
а) верных;
б) если бы дали нормальную документацию и API — не надо было бы гадать.

я не понимаю: ты идиотничаешь, троллишь, или?

(Reply to this) (Parent) (Thread)

я не понимаю: ты идиотничаешь, троллишь, или?
Я не вижу, как GPL или ей подобное в этой ситуации помогает.

у меня вот ядро кучу версий сменило
Вряд ли ты использовал ReiserFS с ядром Линукса версии 1.*.*. Или использовал?
В документации Окон версия файловой системы чётко связывается именно с ОС.
И у NTFS.SYS тоже есть версия, которую легко проверить. И она наверняка изменялась (хотя бы потому, что явно связана с версией ОС на уровне своих цифр).

верных
То есть: ошибок не возникло, данные не портились?

если бы дали нормальную документацию и API
Ещё раз: какая разница, если программа хотела делать непредусмотренное?

(Reply to this) (Parent) (Thread)

не, дальше беседуй сам с собой. мне тяжело беседовать русскими словами не по-русски.

(Reply to this) (Parent)

(lkml.org)

Да, какой-то отстой. Не хочу быть программистом под Линукс.

(Reply to this) (Parent) (Thread)

это не «отстой», это линус мудак, увы. линус давно уже мудак, правда, и сраный проприетарщик. надеюсь, однажды он таки кого-то хорошо достанет и ядро форканут.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)