Здравствуйте, Erop, Вы писали:

Pzz>>>>В виндовсе чтобы записать в файл...
Pzz>>А при чем здесь взаимодействие с железом?

E>Ты что-то про запись в файл писал, вроде...

Файлы бывают разные. Потом, про отложенную запись слышали? Запись в файл обычно кончается обновлением странички дискового кеша.

Здравствуйте, Pzz, Вы писали:

Pzz>Файлы бывают разные. Потом, про отложенную запись слышали? Запись в файл обычно кончается обновлением странички дискового кеша.

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

Здравствуйте, Erop, Вы писали:

Pzz>>Файлы бывают разные. Потом, про отложенную запись слышали? Запись в файл обычно кончается обновлением странички дискового кеша.

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

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

Здравствуйте, Pzz, Вы писали:

Pzz>В нормальных системах этим можно управлять. Если каждая запись кончается модификацией физического содержимого носителя до того, как управление возвращается вызывающей программе, это будет работать просто чудовищно медленно. И даже по закрытию файла далеко не всегда есть смысл сбрасывать данные на диск. Например, нет особого смысла так уж тщательно заботиться о судьбе всяких там временных файлов (скажем, объектных файлов) в ущерб скорости работы — в случае аварии их проще заново пересоздать.

Ты, собственно, что пытаешься доказать? Что под линухом бессмысленная прога, которая миллион раз подряд пишет в одно и то же место файла будет работать сильно быстрее?

Здравствуйте, Erop, Вы писали:

E>Ты, собственно, что пытаешься доказать? Что под линухом бессмысленная прога, которая миллион раз подряд пишет в одно и то же место файла будет работать сильно быстрее?

А Вы что пытаетесь доказать? Что у виндовса каждый WriteFile синхронно апдейтит диск? Да не в жизнь не поверю. Даже мелкософт не может быть так плох.

Здравствуйте, Pzz, Вы писали:

Pzz>А Вы что пытаетесь доказать? Что у виндовса каждый WriteFile синхронно апдейтит диск? Да не в жизнь не поверю. Даже мелкософт не может быть так плох.

Я утверждаю, что твоя критика того, как устроено файловое API в винде несостоятельна...

Здравствуйте, Erop, Вы писали:

E>Я утверждаю, что твоя критика того, как устроено файловое API в винде несостоятельна...

Ну обоснуйте, коль утверждаете...

Речь, кстати, заметьте, идет не об API, а об архитектуре подсистемы ввода-вывода.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, _d_m_, Вы писали:

E>>>1) Так можно сделать только в том случае, если у используемой библиотеки нет статической части. Иначе .lib по .dll не восстанавливается в принципе... Про чисто .lib-библиотеки я и не говорю вовсе.

___>>Какой еще статической части?
E>Если ты чего-то не знаешь или не замечаешь, ещё н езначит, что этого нет и не бывает.
E>.lib, предназначеннадя для связи с .dll (её обычно import lib называют) у сложных библиотек часто содержит не только перевызовы функций, но и какие-нибуудь ещё данные или код. Обычно это называют "статической частью DLL"

Так вот насчет невежества, какая еще статическая часть в import library? И для чего она там нужна? Ссылки, примеры. А я то программирую уже много лет и как-то впервые такое узнаю. Вобщем, не порите чушь ей же больно.

___>>How To Create 32-bit Import Libraries Without .OBJs or Source
E>Очень хорошо. Попробуй породить import lib для рантайма, например, или для MFC...

Ну дак в чем проблема? Давай не будем брать MFC не потому, что мы якобы не сможем содать для них import library, а потому что там ф-ций дофига. Сделай нам "невозможную" библиотечку с одной ф-цией. Ага?

Здравствуйте, _d_m_, Вы писали:

___>Так вот насчет невежества, какая еще статическая часть в import library? И для чего она там нужна? Ссылки, примеры. А я то программирую уже много лет и как-то впервые такое узнаю. Вобщем, не порите чушь ей же больно.
Это может быть не чистая import library.

Делается в полпинка — берем скомпилированую import library и библиотекарем добавляем в неё obj-файлы с реализацией функций.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, _d_m_, Вы писали:

___>>Так вот насчет невежества, какая еще статическая часть в import library? И для чего она там нужна? Ссылки, примеры. А я то программирую уже много лет и как-то впервые такое узнаю. Вобщем, не порите чушь ей же больно.
C>Это может быть не чистая import library.

C>Делается в полпинка — берем скомпилированую import library и библиотекарем добавляем в неё obj-файлы с реализацией функций.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Erop, Вы писали:

E>>Я утверждаю, что твоя критика того, как устроено файловое API в винде несостоятельна...

Pzz>Ну обоснуйте, коль утверждаете...

Pzz>Речь, кстати, заметьте, идет не об API, а об архитектуре подсистемы ввода-вывода.

О реализации которой в винде ты, судя по твоим постам, не имеешь ни малейшего представления. И что при таком раскладе вообще можно обосновать?

Здравствуйте, The Lex, Вы писали:
TL>А каком еще "ГУЙ"!? "ГУЙ" — это зло! "ГУЙ" — это для ламеров!

И не говори. настоящие кул-хацкеры даже порнушку в ASCII смотрят

Здравствуйте, Erop, Вы писали:

E>Я о теме топика. Зачем можно использовать исходники винды в работе?
E>Соответсвенно обсуждалась тема самопальных патчей. Но собрать один компанент без его зависимостей может быть очень затруднительно. Тут люди из линуха говорили, что не может, но я указал на два обстоятельства о которых они забыли не знали...

E>Одно из них -- это статические части dll. Такие части, например, есть и в MS С-рантайме и в MFC...
E>И во многих других dll, не только M$овских тоже, кстати...

E>Желающие ещё примеров отправляются с целью самообразования в dumpbin

E>А вот ты о чём я пока не догнал

Знаешь... Ты вообще как бы представляешь что такое "поставлять софт в исходниках"?

Здравствуйте, kochetkov.vladimir, Вы писали:

Pzz>>Речь, кстати, заметьте, идет не об API, а об архитектуре подсистемы ввода-вывода.

KV>О реализации которой в винде ты, судя по твоим постам, не имеешь ни малейшего представления. И что при таком раскладе вообще можно обосновать?

Что это Вы лезете в середину чужого спора, и сходу сливаете?

Здравствуйте, ArtDenis, Вы писали:

TL>>А каком еще "ГУЙ"!? "ГУЙ" — это зло! "ГУЙ" — это для ламеров!

AD>И не говори. настоящие кул-хацкеры даже порнушку в ASCII смотрят

Боян. Порнушка на тех монстрах была — в виде текстов соотв. содержания.

Здравствуйте, ArtDenis, Вы писали:

AD>И не говори. настоящие кул-хацкеры даже порнушку в ASCII смотрят

"Декамерон", например...

Здравствуйте, The Lex, Вы писали:

E>>А вот ты о чём я пока не догнал
TL>Знаешь... Ты вообще как бы представляешь что такое "поставлять софт в исходниках"?
1) Представляю.
2) И давно тебе офис в исходниках последний раз поставляли?

Здравствуйте, _d_m_, Вы писали:

___>Это понятно, теоретически — да. Но зачем? Эти объектники уже часть нашего, компилируемого модуля, но никак не ссылаемой библиотеки (которые мы зачем-то взяли и засунули в иморт либу ).

Ну в больших библиотеках обычно находится зачем.
Самая простая из нужд -- добавляют экспортируемый объект с уникальным именем, по которому можно понять с какой версией твоей библиотеки был слинкован этот клиент и, соответсвенно как-то учесть это в своём поведении...

Ещё есть популярная мулька такая. Положим в твоей dll в отладочном режиме регится какая-то дебажная инфа. Хорошо бы список этих данных ассоциировать с сожержащей их dll, чтобы когда её отгрузят не попасть в просак...

Тоже часто через статическую часть import library решают...

Я же привёл тебе два живых примера от M$ -- crt и MFC...
Bсходники и того и другого доступны. Посмотри как там import lib генерится и САМ ВСЁ ПОЙМЁШЬ
Тебе же хватит квалификации. Тебе только понты мешают это сделать, IMHO.
А вот это-то, как раз, для профессионала, IMHO, и непреемлемо

Здравствуйте, DKM_MSFT, Вы писали:

Иногда не ясно, как правильно юзать API. Я столкнулся конкретно с DHCP API. Док почти нет. Поддержка отсутствует. Исходники нужны и как пример кода.

Здравствуйте, LaptevVV, Вы писали:

LVV>А МС конкретно ВРЕТ и обманыват — всей своей рекламой. Так что я против обманщиков.
Чем конкретно тебя MS обманула и, возвращаясь к сути разговора, чем тебе помогут исходники винды с этим побороться?

LVV>Таки не поняли, что не против винды, а против вранья и навязывания не нужных мне вещей, за которые еще и бабки вынуждают платить. Неужели вы, такой продвинутый, этого не видите?
Вот есть автомобиль. Для конкретики, славная кампания хонда поставляет свой цивик всего в 4х модификациях. Я не могу взять круиз-контроль, но отказаться от литых дисков. Они тоже навязывают и обманывают?!
Валера, не надо впадать в праведный гнев, MS здесь в своем праве — не хочешь, не покупай. Но однакож покупают, потому, что во первых это-таки не дорого, а во вторых это на три головы качественнее, цельнее и логичнее сделано, чем аналоги. Тебе какая-нибудь мелочь нужна раз в три года, но когда она тебе все-таки понадобилась — тебе достаточно просто на кнопку нажать, а не лазить в поисках исходников под нужный билд, потом компилировтаь и развертывать все это.
При этом ты из компонентов винды, точно так же можешь создать дистрибутив только с теми компонентами которые тебе нужны, выкинув все лишнее, включая сервисы, причем делается это на раз-два — это уж если совсем чешется.
Вот что я вижу.