Исходники ХР сейчас наверно мало кому будут полезны.
Есть Wine, ReactOS.
В вайне основные проблемы сейчас вроде бы с отсутствием некоторых новых фич, ну и даже реализовать/улучшить недостающие старые им это вряд ли поможет, там жесткие правила о том, что разрешен только clean room reverse engineering.
Оо-как.
Только не понял что такое clean-room и Wine ?
Wine это реализация WinApi, которая позволяет запускать многие виндовые программы на линуксе.
clean room reverse engineering — reverse engineering без подглядывания в исходники (даже дизасм и т.п.).
Так без дизасма не получится реверс…
Насколько понимаю договоренности:
дизассемблирование не является кражей если не были использованы исходные тексты.
Смотреть что происходит при например вызове какой-нибудь функции, сделать свою функцию с таким же интерфейсом, которая повторит поведение.
Например, внутри функции создания файла вызывать аналогичную линуксовую функцию, адаптировав параметры под нее, заменив возвращаемые коды ошибок и т.п., чтобы вела себя точно как виндовская функцию. И тогда виндовская программы будет работать с такой библиотекой как будто она на винде.
По ссылке выше
Российское законодательство явно запрещает использование декомпилирования в рамках данной методологии[1] в отношении ПО в любых целях, кроме как для интеграции с исследуемым ПО.
Так а если некий некто проворачивает что-подобное не в России а в Сомали например, там свои законы…
вопрос ведь не о законодательстве конкретной страны, а в общепринятых международных соглашениях.
Если правильно понимаю исследования при помощи дизассемблера не запрещены в международном праве.
А Вы, простите, EULA на продукт читали? Или для Вас оно не имеет юридической силы?
Это как раз наше законодательство - мягкое, оно оговаривает случаи, когда декомпиляция разрешена в обход EULA
Так это большой опенсорс проект, нельзя всех в Сомали переместить )
И его используют в т.ч. и в коммерческих продуктах: CrossOver, Valve Proton. С подобным подходом наверняка были бы проблемы.
Ну и вообще идея видимо в том, чтобы гарантировать отсутствие проблем с законом, навсегда, а не полагаться на какие-то существующие сейчас лазейки и серые зоны.
Которые еще не факт, что дадут преимущество в итоге.
https://wiki.winehq.org/Disassembly
Although at first, disassembly and decompilation may seem like very useful techniques for Wine developers to use, they should probably only be seen as a last resort for a few different reasons. The purely practical reason is that in most cases, compilation strips and optimizes away much of what makes the original source code easy for a human to understand. It often requires a lot of analysis, work, and skill just to have a reasonable guess at what a bit of diassembled code is doing. Other debugging techniques will usually allow you to narrow down your problem faster and more clearly. This is especially true for native Windows DLLs, where disassembly is almost always useless (in addition to bringing up the issue below).
The other problem is more legal in nature. Because Wine is very strict about Clean Room Guidelines, in order to keep from violating any Microsoft copyrights, any contamination of the “cleanroom” by a developer puts the whole project at risk. While this shouldn’t be an issue so long as you are only disassembling a third-party application, even briefly studying disassembled Microsoft code for a feature that Wine plans to implement could lead to legal trouble. While in theory it is still possible for someone that has disassembled Microsoft code to document what the code does generally, in their own words, this can become a legal grey area. If in doubt about whether you might violate the Clean Room Guidelines, or if you think you may but would still like to help the project somehow, please ask on the Wine developer’s mailing list.