Câu hỏi Tại sao Windows 64 bit lại cần thư mục “Program Files (x86)” riêng biệt?


Tôi biết rằng trên phiên bản Windows 64 bit, thư mục "Program Files" dành cho các chương trình 64 bit và thư mục "Program Files (x86)" dành cho các chương trình 32 bit, nhưng tại sao điều này lại cần thiết?

Bởi "cần thiết", tôi không có nghĩa là "tại sao Microsoft không thể đưa ra bất kỳ quyết định thiết kế nào khác?" bởi vì tất nhiên họ có thể có. Thay vào đó, ý tôi là, "tại sao, với thiết kế hiện tại của Windows 64-bit, các chương trình 32-bit có một thư mục cấp cao nhất riêng biệt từ các chương trình 64 bit không?" Nói cách khác, "điều gì sẽ xảy ra nếu tôi bằng cách nào đó tránh được cơ chế chuyển hướng và buộc mọi thứ phải cài đặt vào thực tế C:\Program Files\? "

Có rất nhiều câu hỏi về Super User và các nơi khác khẳng định "một là dành cho các chương trình 32 bit, một là dành cho các chương trình 64 bit", nhưng không có gì mà tôi có thể tìm ra lý do. Từ kinh nghiệm của tôi, nó không hình như cho dù chương trình 32 bit có được cài đặt đúng chỗ hay không.

Có phải Windows bằng cách nào đó trình bày chính nó khác với một chương trình chạy ra khỏi "Program Files (x86)"? Có một mô tả cho thấy chính xác những gì khác nhau cho một chương trình được cài đặt trong "Program Files (x86)" thay vì "Program Files"? Tôi nghĩ rằng Microsoft sẽ không giới thiệu một thư mục mới mà không có lý do kỹ thuật hợp pháp.


175
2018-06-27 17:19


gốc


Thay vì trả lời câu hỏi của bạn, tôi sẽ hỏi - làm cách nào bạn xử lý các tệp \ program files \ common? - sgmoore
Câu trả lời một lớp (và do đó một nhận xét): vì bạn có thể dễ dàng chạy bất kỳ ứng dụng nào từ bất kỳ thư mục nào mà không biết kiến ​​trúc của nó, thì rõ ràng là không có bắt buộc lý do cho sự tách biệt này. Đó là vấn đề thuận tiện để hỗ trợ cài đặt ứng dụng kép với cả hai kiến ​​trúc. Trong một số trường hợp, nó tạo ra sự khác biệt vì chúng không nhất thiết là biên dịch lại đơn giản. Vấn đề chính là các ứng dụng 32 bit không thể tải các dll 64 bit, do đó bạn không thể cài đặt cả hai phiên bản ở cùng một nơi. Cách khác là có hai thư mục "bin" cho mỗi ứng dụng. - Sklivvz
@Synetech Tôi thậm chí đã có các chương trình cài đặt theo (x86) chỉ để có x64 nhị phân .. Đó là khủng khiếp đôi khi. - sinni800
Tôi đã luôn luôn tự hỏi tại sao Microsoft không đưa các chương trình 64 bit vào một "Program Files (x64)" thay vì * di chuyển "thư mục Program Files" thành Program Files (x86) - LawrenceC
Mớ hỗn độn thực sự về sự khác biệt 64 / 32bit là / Windows / System32 chứa nội dung 64bit, trong khi / Windows / SysWOW64 chứa các thứ 32bit… - poke


Các câu trả lời:


Câu trả lời ngắn gọn: Để đảm bảo các ứng dụng 32 bit cũ tiếp tục hoạt động theo cách tương tự như chúng đã sử dụng mà không áp đặt các quy tắc xấu xí trên các ứng dụng 64 bit sẽ tạo ra một mớ hỗn độn vĩnh viễn.

Nó không phải là cần thiết. Nó chỉ thuận tiện hơn các giải pháp có thể khác như yêu cầu mọi ứng dụng tạo ra cách riêng để tách các tệp DLL 32-bit và các tệp thực thi từ các tệp DLL 64 bit và các tệp thực thi.

Lý do chính là làm cho các ứng dụng 32 bit thậm chí không biết hệ thống 64 bit tồn tại "chỉ hoạt động", ngay cả khi các DLL 64-bit được cài đặt ở những nơi mà các ứng dụng có thể nhìn. Một ứng dụng 32-bit sẽ không thể tải một DLL 64 bit, do đó, một phương pháp là cần thiết để đảm bảo rằng một ứng dụng 32 bit (có thể là hệ thống 64-bit trước và do đó không có ý tưởng các tệp 64 bit thậm chí tồn tại) sẽ không tìm thấy một DLL 64-bit, cố gắng tải nó, thất bại, và sau đó tạo ra một thông báo lỗi.

Giải pháp đơn giản nhất là thư mục riêng biệt. Thực sự là lựa chọn duy nhất là yêu cầu mọi ứng dụng 64-bit để "ẩn" các tệp thực thi của nó ở đâu đó một ứng dụng 32 bit sẽ không nhìn, chẳng hạn như bin64 thư mục bên trong ứng dụng đó. Nhưng điều đó sẽ áp đặt sự xấu xa vĩnh viễn trên các hệ thống 64 bit chỉ để hỗ trợ các ứng dụng cũ.


89
2018-06-27 18:18



Họ không phải nhảy qua các vòng này để cho phép các chương trình 32 bit và 16 bit trên cùng một hệ thống. Tôi không nhớ là đã từng thấy ProgramFiles (16) hoặc một số như vậy. Bên cạnh đó, làm thế nào chính xác sẽ là một chương trình 32-bit "tìm một DLL 64-bit và cố gắng tải nó"? Những chương trình nào đi săn tìm các DLL ngẫu nhiên trong %programfiles%? Nếu nó là một DLL được chia sẻ, thì nó sẽ xuất hiện trong WinSxS; nếu nó không được chia sẻ, thì đó là lập trình viên để quản lý các tệp DLL riêng của họ. Một phần về nó được thực hiện như một sự tiện lợi cho các lập trình viên hợp lý mặc dù. - Synetech
IIRC Win3.1 không có thư mục tệp chương trình (hoặc hầu hết các ứng dụng đã bỏ qua nó); kết quả là sẽ không có bất kỳ ứng dụng win16 kế thừa nào tìm kiếm nội dung trong các tệp chương trình để bắt đầu. Thay vào đó các thư viện chia sẻ IIRC thường được đặt ở đâu đó trong thư mục windows. Win32 có windows \ system và windows \ system32 là một tạo phẩm của nó. - Dan Neely
Windows 3.1 không hỗ trợ tên tệp dài, do đó, nó sẽ không thể có thư mục 'tệp chương trình'. - Darth Egregious
@JarrodRoberson: Khá ngược lại, đó là vì Microsoft đánh giá cao khả năng tương thích ngược cực kỳ cao. - David Schwartz
@ Jarrod: Trên thực tế, như mọi nhà phát triển đều biết, Microsoft đánh giá khả năng tương thích ngược quá cao. Nghĩa là mọi API họ có các phương pháp kế thừa mà họ từ chối xóa và thường nghiêm trọng các lỗi mà họ từ chối khắc phục, bởi vì họ sợ phá vỡ các chương trình cũ hơn đã được viết cho API đó. Điều này cũng đúng với hầu hết các API, nhưng không đúng với bất kỳ nơi nào gần với sự tồn tại của Microsoft. - BlueRaja - Danny Pflughoeft


Nó cho phép bạn cài đặt cả phiên bản 32bit và 64bit của một ứng dụng mà không có nó ghi đè lên chính nó.


Sau khi nhìn vào câu trả lời này và bình luận chủ đề ngày hôm sau, tôi nhận ra một sự giám sát lớn có thể có trong câu trả lời của tôi. Tôi giả định một nền tảng lập trình giả và khi tôi nói về bạn trong ý kiến ​​của tôi, tôi không có nghĩa là người dùng, nhưng là lập trình viên.

Tôi không làm việc cho Microsoft và tôi không biết đầu mối thực lý do đằng sau những thư mục này là, nhưng tôi nghĩ lý do để có những thư mục này rõ ràng đến mức tôi không có vấn đề gì khi tranh luận về nó.

Vì vậy, hãy phá vỡ nó xuống!

  1. Thư mục là tuyệt vời!

    Hãy đồng ý về điều gì đó. Thư mục là tuyệt vời! Chúng tôi không cần chúng, chúng tôi có đủ tên tệp có thể để đặt mọi tệp riêng lẻ vào thư mục gốc của ổ cứng của bạn, vậy tại sao lại có thư mục?

    Vâng, họ giúp chúng tôi đặt hàng công cụ của chúng tôi. Và thứ tự là tuyệt vời. Nó giúp chúng tôi xử lý mọi thứ dễ dàng hơn. Điều này đặc biệt hữu ích khi làm việc với một máy đòi hỏi cấu trúc.

  2. Tách dữ liệu và logic là tuyệt vời!

    Một mô hình thường được tìm thấy trong lập trình, là tách dữ liệu khỏi logic. Bạn muốn một phần biết làm sao làm gì đó và bạn muốn một phần khác bạn có thể làm gì đó với


65
2018-06-27 17:31



Đó có phải là lý do ban đầu không? Tôi không thể cài đặt ứng dụng C:\Program Files\App32 và C:\Program Files\App64? - Stephen Jennings
@StephenJennings: Nhưng điều đó sẽ yêu cầu bạn phải tự đưa ra quyết định. Cách nó hoạt động là quá trình này là tự động, vì Windows biết thư mục nào cần cung cấp khi một ứng dụng gọi SHGetSpecialFolderPath để xác định vị trí cài đặt. - Der Hochstapler
@Synetech: Tại sao cài đặt vào %PROGRAMFILES% ở nơi đầu tiên? Tại sao không đặt phiên bản 32bit trên máy tính để bàn của người dùng và 64bit vào Thùng rác? Chỉ vì nó có thể được thực hiện, không có nghĩa đó là một ý tưởng hay. Xin lỗi, tôi không làm theo lý do của bạn. - Der Hochstapler
@ Synetech: Vâng, bạn đã đưa ra một ví dụ hoàn hảo về cách nó có thể được thực hiện. Một ví dụ hoàn hảo khác về cách nó có thể được thực hiện là cách nó Là thực sự đang được thực hiện ngay bây giờ. Đơn giản chỉ cần viết một tập tin đến% PROGRAMFILES% và chắc chắn rằng nó sẽ kết thúc trong thư mục bên phải là một điều. Tự kiểm tra xem thư mục nào là chính xác một là khác. Nếu bạn thực sự không thấy lợi ích của phương pháp cũ, thì tôi sẽ không thể thuyết phục bạn. Câu hỏi đặt ra là tại sao có 2 thư mục. Tôi nghĩ câu trả lời của tôi hoàn toàn hợp lý trong vấn đề đó. - Der Hochstapler
@OliverSalzburg, Không hoàn toàn. Câu hỏi đặt ra là tại sao hai thư mục cần thiết, không phải vì sao là. Trong thực tế, ông thậm chí còn in đậm nó: tại sao điều này lại cần thiết? Bạn không giải thích lý do tại sao cần thiết và ví dụ tôi đưa ra (và thậm chí là ví dụ châm biếm của riêng bạn) chỉ cho thấy rằng nó không có được thực hiện theo cách của nó. - Synetech


TL; DR:

Tóm lại, không, không phải cần thiết; họ có thể đã sử dụng một thư mục duy nhất, và không, Windows không thể hiện bản thân khác với một chương trình đang chạy từ một vị trí này sang vị trí khác.


Vâng, mọi người dường như đang ném ý kiến ​​của họ về điều này, vì vậy tôi sẽ quăng trong 2 ¢ của tôi. Những người khác đã phỏng đoán về những lý do tại sao Microsoft đã chọn tạo các thư mục cấp cao nhất riêng biệt cho các phiên bản 32 bit và 64 bit, vì vậy tôi sẽ rời khỏi phần đó (lý do tốt nhất là lời giải thích của David rằng đó là sự tiện lợi cho người lập trình). Tất nhiên ngay cả sau đó, nó không hoàn toàn giải quyết câu hỏi trực tiếp tại sao điều này lại cần thiết?, câu trả lời có lẽ là: nó không phải.

Thay vào đó, tôi sẽ giải quyết phần chính của câu hỏi

Có phải Windows bằng cách nào đó trình bày chính nó khác với một chương trình chạy ra khỏi "Program Files (x86)"?

Không thực sự, nhưng vị trí của chương trình có thể ảnh hưởng đến hành vi, nhưng không theo cách bạn nghĩ.

Khi bạn chạy một chương trình, Windows thiết lập một môi trường để chạy nó (ý tôi là về bộ nhớ, địa chỉ, vv, không chỉ các biến môi trường). Môi trường này phụ thuộc vào nội dung của chương trình thực thi (các chương trình 32 bit và 64 bit khác nhau trong nội bộ). Khi bạn chạy một chương trình 32 bit trên hệ thống 64 bit, nó chạy trong hệ thống phụ 32 bit mô phỏng môi trường 32 bit. Nó được gọi là WoW64 (WoW64 là viết tắt của Windows trên Windows 64 bit) và tương tự như cách ứng dụng 16 bit được chạy trong XP bằng cách sử dụng NTVDM.

Khi bạn chạy một chương trình có hoặc không có đặc quyền quản trị, chương trình sẽ ảnh hưởng đến cách chương trình chạy, nhưng vị trí Nên không ảnh hưởng đến nó (mặc dù có một số ví dụ về phụ thuộc vị trí như một số trình điều khiển chẳng hạn).

(Tôi đang sử dụng một máy tính khác, vì vậy tôi không thể dựa vào lịch sử trình duyệt của mình để quay lại các bước của mình, nhưng một ngày khác trong khi trả lời câu hỏi SU này Tôi đã kết thúc lúc câu hỏi SO này khiến tôi phải Google PROCESSOR_ARCHITEW6432dẫn đến câu hỏi SO này và bài đăng trên blog của Microsoft này.)

Một nơi nào đó trên đường đi, tôi đọc một bài viết StackOverflow về cách biến môi trường %processor_architecutre%  cho kết quả khác nhau tùy thuộc vào nơi bạn chạy lời nhắc lệnh từ (Tôi sẽ cố gắng tìm báo giá chính xác).

Câu trả lời hóa ra là do phiên bản 32 bit hoặc 64 bit của lời nhắc lệnh đã được chạy (tức là, từ System32\ hoặc là SysWoW64\). Nói cách khác, trong khi vị trí dường như ảnh hưởng đến hành vi của chương trình, nó chỉ vì có các phiên bản khác nhau của chương trình, không phải vì Windows xử lý thư mục theo cách đặc biệt.

Điều này có ý nghĩa bởi vì nội dung của tệp thi hành quyết định xem đó là 32 bit hay 64 bit, vì vậy bạn có thể đặt cả bản sao 32 bit và 64 bit của cùng một chương trình (ví dụ: foobar32.exe và foobar64.exe) trong cùng một thư mục và khi bạn thực thi chúng, chúng sẽ được tải chính xác (phiên bản 64 bit sẽ chạy tự nhiên và phiên bản 32 bit sẽ được chạy trong lớp mô phỏng WoW64).

FreePascal cho phép bạn cài đặt cả hai phiên bản DOS và Windows và chúng đi trong cùng một thư mục: %programfiles%\FreePascal. Nó quản lý các kiến ​​trúc khác nhau bằng cách giữ các tệp thi hành (.exe, .sys, .dll, .ovr, vv) trong các thư mục riêng biệt và chia sẻ các tệp tài nguyên như hình ảnh, tệp nguồn, v.v.) Không có lý do kỹ thuật nào cho việc này cũng không thể thực hiện đối với các phiên bản 32 và 64 bit của chương trình. Như David đã nói, nó dễ dàng hơn cho lập trình viên nếu chúng được giữ riêng biệt (tức là, sử dụng các biến để làm cho nó trông giống như chỉ có một tập hợp các tệp, v.v.)


15
2018-06-27 19:23



Trả thù xuống bỏ phiếu! Muahahaha! thở dài - Synetech
Bỏ phiếu bình chọn lạ: \. BTW giải thích tốt +1. - avirk


Một lý do khác là hầu hết các chương trình được sử dụng để sử dụng các biến môi trường như% PROGRAMFILES% để trỏ đến nơi chương trình của chúng được cài đặt. Đối với các chương trình 64 bit, nó đi đến nơi bình thường. Đối với các chương trình 32 bit, nó sẽ chuyển hướng đến chương trình mới Program Files (x86) thư mục.

Mặc dù, ít nhất là với các công cụ Net mới trong Visual Studio, bây giờ chúng có biến App.Local loại bỏ toàn bộ nhu cầu này.


11
2018-06-27 17:36



Điều đó không giải thích được. Ai chính xác là sử dụng biến môi trường và tại sao nó sẽ quan tâm cho dù một chương trình là 32-bit hoặc 64-bit? - Synetech
@Synetech - Tác giả của chương trình sử dụng biến môi trường. Vì lý do nó sẽ quan tâm là vì tham chiếu đến dlls. Bạn không thể tải một dll 32-bit trong một quá trình 64-bit và ngược lại. - Ramhound
Và làm thế nào %programfiles%, %programfiles(x86)%, hoặc là %programw6432% tạo sự khác biệt ở đó? Bất kỳ tệp DLL được chia sẻ nào đi vào thư mục WinSxS duy nhất và mọi tệp DLL không được chia sẻ đều có quyền thực thi. Điều này sẽ chỉ quan trọng nếu vì một số lý do bạn có cả phiên bản 32 bit và 64 bit của cùng một chương trình được cài đặt, và thậm chí sau đó, bạn sẽ giữ các tệp 32 bit với thực thi 32 bit và DLL 64 bit với thực thi 64 bit. Bạn có thể làm như vậy: %programfiles%\CoolApp\bin\32và% programfiles% \ CoolApp \ bin \ 64`, tại sao các thư mục cấp cao nhất riêng biệt? - Synetech
@Synetech Chắc chắn nó không; % programfiles% đã được khoảng một thời gian. Nếu bạn cài đặt chương trình 32 bit trên máy tính 64 bit, có một nơi sẽ gây ra sự cố cho ứng dụng 32 bit đó. Mặc dù WoW có thể chuyển hướng% programfile% sang phiên bản (x86) cho các ứng dụng 32 bit và phiên bản không phải x86 cho 64. - Andy
tôi nghĩ mọi người sẽ không bối rối, nếu không có chuyển hướng ngầm - kommradHomer


Giải pháp của Microsoft cho quá trình chuyển đổi này từ 32-bit lên 64-bit đã được thêm hỗ trợ kế thừa cho hầu hết các ứng dụng 32-bit. Nói cách khác, hầu hết các ứng dụng 32 bit sẽ hoạt động trong môi trường hoạt động 64 bit. Hãy nhớ rằng các hệ điều hành khác hoạt động trên kiến ​​trúc 64 bit không thể tải hoặc chạy các ứng dụng 32 bit chút nào.

Để giúp quá trình chuyển đổi dễ dàng hơn, Microsoft đã chỉ định rằng tất cả ứng dụng 32 bit nên được tải vào thư mục Program Files (x86) thay vì trộn lẫn với các ứng dụng 64 bit thực sự trong thư mục Program Files thông thường.

Nguồn 

"Điều gì sẽ xảy ra nếu tôi bằng cách nào đó tránh được cơ chế chuyển hướng và buộc mọi thứ phải cài đặt vào C: \ Program Files \" thực sự? " 

Không có gì. Hai thư mục chương trình chỉ dành cho tổ chức, hoặc để giữ cho các chương trình có hai phiên bản một phiên bản 32 bit và 64 bit riêng biệt, như Internet Explorer. Nhưng bạn có thể cài đặt chương trình 32 bit trong "Program Files" và chương trình 64 bit trong "Program Files x86" và sẽ không có gì xảy ra khi chương trình chạy giống nhau.

Wiki nói:

Một số trình cài đặt ứng dụng từ chối không gian trong vị trí đường dẫn cài đặt. Đối với các hệ thống 32 bit, tên viết tắt của thư mục Program Files là Progra ~ 1. Đối với hệ thống 64 bit, tên viết tắt của thư mục Program Files 64-bit là Progra ~ 1 (giống như trên các hệ thống 32 bit); trong khi tên viết tắt của thư mục Program Files (x86) 32 bit bây giờ Progra ~ 2.


8
2018-06-28 16:28



Hehe. Bài viết hay. Các nhận xét cho bài viết đó giống hệt như ý kiến ​​ở đây. Tệ hơn nữa, bài viết đó từ hơn hai năm trước, điều này chỉ cho thấy rằng câu hỏi này không phải là mới và nếu nó vẫn không thể được trả lời một cách có thẩm quyền, thì tôi đoán nó sẽ không bao giờ (trừ khi có ai đó trong nhóm Windows chimes). Ồ, tôi cho rằng tất cả chúng ta nên ngừng lo lắng và học cách yêu quả bom, uh, ý tôi là sống với nó. +1 Để chỉ ra bài viết và cho thấy rằng câu hỏi này đã tồn tại quá lâu. - Synetech
Cảm ơn @Synetech! Vâng, ý tưởng đằng sau việc đặt liên kết bài viết cũng giống như bạn có. Đây là một câu hỏi thời gian rất cũ nhưng IDK tại sao mọi người không thể có được nó được nêu ra. Tuy nhiên, MS nên viết một KB hoặc Tài liệu cho vấn đề này :) - avirk
Có, họ nên, đặc biệt là bởi vì nó không chỉ là các nhà phát triển yêu cầu, ngay cả người dùng bình thường tự hỏi về nó. Thật không may là tài liệu của Microsoft thường không quá tốt. - Synetech
@Synetech yup! MS tài liệu hút hầu hết thời gian. Nhưng có, họ đã viết một số bài viết hay và tôi chắc chắn rằng họ có thể đếm được;) - avirk


Lý do là để nâng cấp chương trình lên các nhà phát triển 64 bit dễ dàng hơn. Họ không phải viết bất kỳ mã tùy chỉnh nào để kiểm tra chương trình trong một thư mục khi biên dịch trong chế độ 32 bit và trong một thư mục khác khi biên dịch ở chế độ 64 bit; họ chỉ cần kiểm tra C:\Program Filesvà khi chạy dưới chế độ 32 bit, điều này tự động được thay đổi thành C:\Program Files (x86) bằng Windows 64 bit. Tương tự, các mục đăng ký được phân lập giữa các chương trình 32 bit và 64 bit.

Điều này ngăn cản xung đột từ các nhà phát triển không biết, họ chỉ thay đổi chế độ biên dịch thành 64-bit mà không suy nghĩ nhiều về nó và ngăn một lượng lớn công việc cho các nhà phát triển muốn người dùng có thể cài đặt cả phiên bản 32 và 64 bit của họ phần mềm đồng thời.


Nhưng tại sao bất kỳ chương trình nào muốn cho phép cả hai phiên bản được cài đặt đồng thời? Một ví dụ: Photoshop và IE có các phần mở rộng có nguồn gốc của .dll. Bạn không thể có mã 32 và 64 bit được trộn lẫn trong cùng một quy trình, vì vậy không thể sử dụng phần bổ trợ cho phiên bản 32 bit với phiên bản 64 bit và ngược lại. Như vậy, Photoshop / IE  để cho phép cả hai phiên bản được cài đặt hoặc có nguy cơ phá vỡ cơ sở lớn của các trình bổ sung hiện có.


6
2018-06-27 18:48



+1 Ít nhất bạn đã giải quyết câu hỏi cơ bản về lý do tại sao người dùng trung bình sẽ có cả hai phiên bản. - Synetech


Các chương trình chạy trên "Program Files (x86)" sử dụng WOW64 hệ thống con (Windows 32 bit trên Windows 64-bit là một bộ trình điều khiển và API có ý định chạy các ứng dụng x32 trên một hệ thống kiến ​​trúc x64):

Hệ thống con WoW64 bao gồm một lớp tương thích nhẹ   có giao diện tương tự trên tất cả các phiên bản Windows 64 bit. Nó nhằm mục đích   tạo môi trường 32 bit cung cấp các giao diện cần thiết cho   chạy các ứng dụng Windows 32 bit chưa sửa đổi trên hệ thống 64 bit.   Về mặt kỹ thuật, WoW64 được triển khai bằng cách sử dụng ba thư viện liên kết động   (DLL):

  • Wow64.dll, giao diện cốt lõi cho hạt nhân Windows NT dịch giữa các cuộc gọi 32-bit và 64-bit, bao gồm cả con trỏ và cuộc gọi   ngăn xếp thao tác
  • Wow64win.dll, cung cấp các entry-point thích hợp cho các ứng dụng 32-bit
  • Wow64cpu.dll, sẽ xử lý việc chuyển bộ xử lý từ chế độ 32 bit sang 64 bit

Hệ thống 64 bit cần phải "mô phỏng" các ứng dụng 32 bit, đó là lý do tại sao Windows cần phải "tách biệt" hai thư mục Program Files.


5
2018-06-27 17:32



Nhưng tại sao nó phải đặt nó trong các thư mục khác nhau? Windows đã hoàn toàn có khả năng xác định kiến ​​trúc của một tập tin thực thi bằng cách nhìn vào tiêu đề PE. Tại sao nó không thể tải môi trường thích hợp khi nó tải thực thi? - Synetech
Tôi nghĩ rằng đó chỉ là một sự lựa chọn của Microsoft để dễ dàng hiển thị cho người dùng kiến ​​trúc mà họ muốn từ hai phiên bản chương trình khi mở một chương trình. Ý tôi là, nếu không có hai thư mục này và nếu nó trong suốt đối với người dùng (nếu nó tự động chuyển đổi), họ sẽ không biết nếu chạy ứng dụng 32 hoặc 64 bit, thậm chí, họ sẽ không biết chương trình nào sẽ mở nếu chạy trên 64 bit .. - Diogo
Phiên bản IE 64 bit có tiếng là khủng khiếp. - Samuel Edwin Ward
MS khuyến cáo sử dụng office32 trừ khi bạn đang làm việc với bộ dữ liệu đủ lớn để vượt quá giới hạn bộ nhớ. Tôi tin rằng cần phải biên dịch lại các addons nhị phân để làm việc với office64; kết hợp với không đưa ra bất kỳ lợi ích nào trong các trường hợp sử dụng bình thường là đằng sau quyết định. - Dan Neely
Tôi nghĩ bạn sẽ thấy rằng một chương trình 64 bit được cài đặt rõ ràng vào thư mục Program Files (x86) sẽ hoạt động hoàn toàn bình thường (và, trong hầu hết các trường hợp, ngược lại). Windows không sử dụng vị trí thư mục để xác định cách xử lý tệp thực thi. - Harry Johnston


Điều thú vị là các câu trả lời ở đây và trên internet thay đổi khá nhiều. Tìm một câu trả lời chính xác cho câu hỏi quan trọng này là một thách thức. Dường như có một chút thông tin sai lệch được trình bày trên internet, dẫn đến sự nhầm lẫn.

Tôi đã thực hiện một số lượng đáng kể nghiên cứu, và đã rút ra kết luận sau đây, mà tôi tin là chính xác:

  • Nó làm cho không có sự khác biệt nơi một ứng dụng được lưu trữ. Khi chạy, Windows sẽ xác định xem ứng dụng là 32-bit hay 64-bit và tự động sử dụng phần đăng ký và DLL thích hợp.

Điều này xảy ra tự động và độc lập với nơi ứng dụng được lưu trữ. Không có tốc độ, độ tin cậy hoặc lợi ích chức năng khác để có các thư mục 32 bit và 64 bit riêng biệt.

Lý do duy nhất để tách mặc định thành hai thư mục ('Program Files' và 'Program Files (x86)') là nếu bạn có hai phiên bản của cùng một chương trình (phiên bản 32 bit và 64 bit), nó cung cấp cách đơn giản để giữ riêng các tệp chồng chéo. Ngay cả trong trường hợp này, miễn là tất cả các tên tệp là duy nhất, chúng thực sự có thể tồn tại trong cùng một thư mục mà không có bất kỳ hậu quả nào.

Có một báo trước cho kết luận trên, và đó là một trong những ứng dụng được mã hóa kém. Nếu một ứng dụng có bất kỳ đường dẫn nào được mã hóa cứng vào nó, nó sẽ chỉ sử dụng đường dẫn đó. Theo quy tắc, đường dẫn không bao giờ nên được mã hóa cứng vào một ứng dụng, nhưng đôi khi một lập trình viên sẽ mắc lỗi này. Trong trường hợp này, chương trình sẽ sử dụng đường dẫn mã cứng; thư mục trong đó ứng dụng được cài đặt sẽ không ảnh hưởng đến vị trí thực sự tìm tệp.


5
2017-10-16 19:57





Có các thư mục riêng biệt giúp có thể giữ các ứng dụng 64 bit gốc và các ứng dụng yêu cầu WoW64 ngoài.

Điều này có thể hữu ích - như @OliverSalzburg đã được chỉ ra - nếu bạn muốn cài đặt cả 64 bit và 32 bit của trình duyệt web (ví dụ), vì một số trình cắm và tiện ích bổ sung có thể chỉ có sẵn cho một trong hai trình cắm.

Có các thư mục riêng biệt làm cho sự tách biệt này tự động, sử dụng các kỹ thuật như chuyển hướng đăng ký.

Giả sử trình cài đặt cố gắng xác định thư mục tệp chương trình bằng cách đọc sổ đăng ký bằng cách sử dụng, ví dụ: RegQueryValueEx.

Trong mọi trường hợp, nó cố gắng đọc khóa registry

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

mà thường trỏ đến C:\Program Files.

Tuy nhiên, nếu trình cài đặt là một ứng dụng 32 bit, việc chuyển hướng đăng ký sẽ gây ra khóa regitry

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

để được đọc thay vào đó, mà thường trỏ đến C:\Program Files (x86).

Tại sao những cụ thể tên thư mục đã được sử dụng chỉ có thể được trả lời bởi những người đã thực hiện lựa chọn này. Bạn luôn có thể thay đổi tên của các thư mục mặc định nếu muốn.

Có phải Windows bằng cách nào đó trình bày chính nó khác với một chương trình chạy ra khỏi "Program Files (x86)"?

Tôi nghi ngờ điều đó. Hầu hết các trình cài đặt cho phép bạn chọn một thư mục cài đặt tùy chỉnh, vì vậy nó không quan trọng Ở đâu một chương trình được cài đặt.


3
2018-06-27 18:40



Xin lỗi tôi trộn "giấy phép" với "cấm" - Wernfried Domscheit


Tôi không thể tin rằng sự nhầm lẫn ở đây .. trước hết tôi là một nhà phát triển toàn thời gian.

MS đã làm điều này để giải quyết trường hợp một DLL được sử dụng bởi cả hai ứng dụng 32-bit cũ hơn và các ứng dụng 64-bit mới hơn. Không thể thay đổi phương thức cũ hơn (System32, Program Files, vv) vì điều đó sẽ phá vỡ các chương trình cũ hơn mà không thể biên dịch lại được.

Vì vậy, MS đã tạo một thư mục để lưu trữ các chương trình, cụm và thư viện 64 bit cụ thể để các chương trình mới có thể liên kết đến các thư viện thích hợp và các chương trình cũ sẽ tiếp tục hoạt động như bình thường.

Vì nó là viết tắt, .Net DLLs có thể cùng tồn tại với các phiên bản khác trên cùng một máy. Ví dụ, bạn có thể có Library.1.0.1, Library.1.0.2, Library 1.1.0, v.v. Và đây chỉ là một kích thước bit cụ thể (32 hoặc 64). Nếu các thư mục riêng biệt không được sử dụng, thì mỗi assembly phải có một phiên bản 32 và 64 bit. Điều này sẽ làm lộn xộn một thư mục đã chứa nhiều phiên bản của cùng một assembly.

Đây là tất cả các công cụ phát triển. Là một người sử dụng, tôi chỉ phải đối phó với nó khi tôi đang làm việc với một chương trình 32-bit trên Windows 7 64. Và tôi thích có khả năng chạy một phiên bản 32-bit và cùng một ứng dụng trong 64-bit là tốt. Khi tôi đang làm việc trên một ứng dụng 32-bit mà tôi cần phải biên dịch trong 64-bit, tất cả những gì tôi làm là yêu cầu trình biên dịch làm như vậy. Tên dll và mọi thứ khác vẫn giữ nguyên.

Lý do điều này không tồn tại với Windows 95/98 là những hệ thống này mô phỏng thời gian chạy 32 bit; nó không phải là một hệ điều hành 32 bit chính hãng. Nó giả mạo thực hiện 32-bit với một cái gì đó có tên "thunking".

Đây là một định nghĩa tốt: http://searchwinit.techtarget.com/definition/thunk


3
2018-06-28 14:43



Làm thế nào ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in \ 32 \ blah` hoặc \blah\32; một trong hai cách, chúng được tách ra. Nếu bất cứ điều gì, cách hiện tại tách các thành phần của ứng dụng (và cũng sao chép chúng một cách không cần thiết vì vài ứng dụng sử dụng CommonFilescho tài nguyên và như vậy. Bên cạnh đó, bạn làm cho nó âm thanh như thể các ứng dụng đang bán các tệp DLL của chúng trong một nhóm chung. Thật dễ dàng để giữ các tệp DLL 32 bit của ứng dụng với các bit 32 bit của nó và đó là các DLL 64 bit với các bit exe 64 bit. - Synetech
Oh, và như cho 95/98, ai nói gì về điều đó? Ngay cả XP cũng có một hệ thống con 16 bit (NTVDM). - Synetech
Tôi nghĩ bạn muốn có một lời giải thích. Vài ứng dụng sử dụng CommonFiles? Tôi có 35 ứng dụng khác nhau có mục nhập ở đó. Đó là một nơi an toàn hơn để lưu trữ các thành phần được chia sẻ hơn thư mục System32. Tuyên bố của bạn rằng vài ứng dụng sử dụng điều này là gây tranh cãi. Trích dẫn bạn: "Họ không phải nhảy qua các vòng này để cho phép các chương trình 32-bit và 16-bit trên cùng một hệ thống. Tôi không nhớ là đã từng thấy một ProgramFiles (16) hay một số [...] Một phần về nó được thực hiện như một sự tiện lợi cho các lập trình viên hợp lý mặc dù. " Vâng, yeah .. lập trình làm. Chúng tôi viết các ứng dụng sau khi tất cả. - Jason Locke
Huh? - Synetech
Chỉ cần đọc lại điều này .. anh ấy nói nó tốt hơn trong câu trả lời của anh ấy - superuser.com/a/442253/142951. Nếu bạn không phải là nhà phát triển, bạn có thể không thấy mục đích. - Jason Locke