Инсталляция окамла под виндой

[metaclass]

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

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

Так вот в окамле в таком случае оказалось, что там, мало того что пути пишутся в реестр, так еще и переменная окружения используется для поиска либ. С ходу не вижу, почему бы не сделать при отсутствии оных переменных и ключей реестра использование дефолтных значений вроде "папка_с_exe\..\lib\".
Т.е. что под виндами, что в линуксе авторы софта как-то очень уж надеются на стандартную инсталляцию. В некоторых особо сложных случаях это допустимо, но я обычно стараюсь делать прогу запускаемой, даже если психи ее просто скопировали, так проще жить как самому, так и пользователям.

Comments

[gds.livejournal.com]

надо использовать native code: не понадобится писать пути в реестр (не нужны, чтобы найти .exe), не требуется OCAMLLIB для поиска слинкованного, а нужные .dll (если линкуется не статически) нужно класть рядом с готовой программой. Я так распространяю юзерам-дебилам, все довольны.

[oldmann.livejournal.com]

именно такими повадками создаётся dll Hell.

[metaclass.livejournal.com]

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

[oldmann.livejournal.com]

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

[gds.livejournal.com]

из-за апгрейда системы? Ну так и софт надо апгрейдить, если что-то серьёзное ломают в системе. Не пофиг ли, где dll лежат, если они явно нестандартные и с другими программами не перекрываются.

[oldmann.livejournal.com]

как минимум с гуём и вводом-выводом перекрываются.
если писать свой гуй и использовать direct hardware access, это уже встроенная система получается, виндовс не нужэн.

[gds.livejournal.com]

если меняются интерфейсы гуя или ввода-вывода несовместимым для программы образом, нет разницы, куда класть .dll, которые не пересекаются с другими программами (не с ОС) -- всё равно оно поломается, и апгрейд какой-либо другой программы ситуацию не спасёт.

[fas-tm.livejournal.com]

в общем то верно. Но есть нюансы.
Поставленный рантайм питона в винде был обновлен. Старый софт отказался работать. Юзеры предали анафеме разработчиков.

[aamonster.livejournal.com]

Не-не-не, именно так он не создаётся. Для настоящего dll hell dll-ки от одной программы должны перекрывать dll-ки от другой, приводя к непредсказуемому результату.