Понял. Файловая система Windows ведет себя по-разному в зависимости от архитектуры вашего процесса. Эта статья объясняет все это - в частности:
Но как быть с 32-битными приложениями, жестко закодированными по системному пути и работающими в 64-битной Windows? Как они могут найти новую папку SysWOW64 без изменений в программном коде, вы можете подумать. Ответ заключается в том, что эмулятор перенаправляет вызовы в папку System32 в папку SysWOW64 прозрачно, поэтому даже если папка жестко запрограммирована в папку System32 (например, C: \ Windows \ System32), эмулятор убедится, что вместо нее используется папка SysWOW64. , Поэтому тот же исходный код, который использует папку System32, может быть скомпилирован как в 32-битный, так и в 64-битный программный код без каких-либо изменений.
Попробуйте скопировать calc.exe
в другое место ... затем снова запустите те же инструменты. Вы получите те же результаты, что и Java. Что-то в файловой системе Windows дает инструментам данные, отличные от данных для Java ... Я уверен, что это связано с тем, что они находятся в каталоге Windows, и поэтому, вероятно, обрабатываются "по-другому" .
Кроме того, я воспроизвел его на C # ... и обнаружил, что это зависит от архитектуры процесса, который вы запускаете . Итак, вот пример программы:
using System;
using System.IO;
using System.Security.Cryptography;
class Test
{
static void Main()
{
using (var md5 = MD5.Create())
{
string path = "c:/Windows/System32/Calc.exe";
var bytes = md5.ComputeHash(File.ReadAllBytes(path));
Console.WriteLine(BitConverter.ToString(bytes));
}
}
}
А вот консольный сеанс (без болтовни от компилятора):
c:\users\jon\Test>csc /platform:x86 Test.cs
c:\users\jon\Test>test
60-B7-C0-FE-AD-45-F2-06-6E-5B-80-5A-91-F4-F0-FC
c:\users\jon\Test>csc /platform:x64 Test.cs
c:\users\jon\Test>test
10-E4-A1-D2-13-2C-CB-5C-67-59-F0-38-CD-B6-F3-C9