Couldn't you create a new "compatibility" DLL, that implements or stubs "GetLongPathNameW"? Then if you link in that DLL to the Erlang NT4 build, the call will resolve at run time. This is much less dirty, and if Erlang adds it in as an NT4 compatibility patch, everyone will be happy.<br>
<br><div class="gmail_quote">On Thu, Jul 17, 2008 at 9:21 AM, Sebastian Egner <<a href="mailto:s.egner@specs.de">s.egner@specs.de</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
Thank you for all the comments!<br>
<br>
For what it's worth, I found out that the NT4 compatibility issue is not<br>
related to Erlang/OTP specifically, but rather an general byproduct of<br>
Microsoft terminating support for NT4 in Visual C++ 8:<br>
<br>
<br>
<a href="http://forums.msdn.microsoft.com/en-US/vcgeneral/thread/2435c3ab-f732-467e-8224-5f4e3f12c10b/" target="_blank">http://forums.msdn.microsoft.com/en-US/vcgeneral/thread/2435c3ab-f732-467e-8224-5f4e3f12c10b/</a><br>

<br>
<br>
<a href="http://www.mombu.com/microsoft/windows-programmer-win32/t-vs2005-and-nt4-392831.html" target="_blank">http://www.mombu.com/microsoft/windows-programmer-win32/t-vs2005-and-nt4-392831.html</a><br>
<br>
In short, when the system loads the VC8 runtime lib MSVCR80.DLL, it<br>
tries to resolve a reference to the function GetLongPathNameW in<br>
KERNEL32.DLL, which NT4 doesn't have. The beauty of it is that this<br>
reference seems to be the only reason for most VC8 application not to<br>
run on NT4! People have reported successfully running non-unicode  VC8<br>
applications by using custom-compiled versions of MSVCR80.DLL without<br>
the call to GetLongPathNameW.<br>
<br>
This means, short of ERTS being ported back to VC 6.0, there is no hope<br>
of an 'official' version of ERTS supporting NT4, because Microsoft's<br>
licence will prevent Ericsson to include a patched runtime lib in the<br>
redistributable VC package. (Unless I am mistaken and there is a legal<br>
way of supporting NT with VC8.)<br>
<br>
Experimentally trying out R12B-3 with a patched version of MSVCR80.DLL<br>
(<dirty mode="don't try this at home">Start emacs, load MSVCR80.DLL,<br>
replace "GetLongPathNameW" by "GetModuleHandleA" (= 16 chars and<br>
linkable), save.</dirty>), and creating a proper 'erl.ini' (which the<br>
installer could not do due to an acute lack of working VMs at the time),<br>
I am informed by the VM:<br>
<br>
    C:\Program Files\erl5.6.3\erts-5.6.3\bin>erl<br>
    Windows version not supported (min required: winnt 5.0)<br>
<br>
So this clarifies the bug-report of my first email:<br>
<br>
Yes, Erlang/OTP R12B-3 does check the OS version and refuses to run on<br>
NT4. However, the check is executed in an Erlang VM, which won't start<br>
in the first place, throwing an error message that takes an expert to<br>
interpret.<br>
<br>
You could consider checking the OS version in the NSIS installer itself,<br>
e.g. using the function GetWindowsVersion:<br>
<br>
    <a href="http://nsis.sourceforge.net/Get_Windows_version" target="_blank">http://nsis.sourceforge.net/Get_Windows_version</a><br>
<br>
and deactivate the check from the VM (erts\emulator\sys\win32\sys.c:<br>
check_supported_os_version()).<br>
<br>
Kind regards,<br>
<font color="#888888"><br>
Sebastian<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)