Download Exness — and tell the right file from the wrong one — South Africa

How to download Exness

Download guides by device

One name, several files

A download folder collects near-identical entries fast. A browser that fetches the same file twice does not overwrite it — it appends a counter, so setup.exe becomes setup (1).exe and then setup (2).exe. A copy forwarded through a messenger arrives under the sender naming, an archive unpacked twice leaves a folder and a folder (1), and a file saved months ago sits next to one saved this morning with exactly the same stem.

None of that changes the name in a way that carries meaning. The stem of a file name is chosen by whoever packaged or re-saved it, not by the operating system, and it is the one part of a file that survives renaming, re-hosting and copying untouched. Treating the stem as identity is how the wrong file gets opened.

The working rule is to sort the folder by date rather than by name. Two files with one name are separated first by when they arrived and only then by what is inside them — and the arrival order is the cheapest of the two questions to answer.

The file card carries the identity, the name does not

Every file has a card the operating system keeps beside it. On Windows it opens from the right-click menu under Properties, and the Details tab lists the product name, the file version and the file description. On macOS the same information sits under Get Info, with the version line in the General block. On Android the file manager entry shows size and date, and the package details appear on the install screen before anything is confirmed.

Three lines on that card do most of the work: the size in megabytes, the version string, and the date the copy was created. A build for a different architecture usually differs in size by a wide margin, an older build differs in the version string, and a re-saved copy differs in date while the version stays identical. One of the three almost always separates two candidates in a few seconds.

An empty card is information too. A packaged installer normally carries a product name, a description and a version; a file that lost those fields somewhere along the way is no longer the file that left the source, whatever the name still says.

Architecture: which build the machine can actually run

Desktop builds come in two shapes. A 64-bit build runs on 64-bit Windows and on current macOS; the 32-bit shape is the legacy one kept for older systems. A 64-bit file will not start on a 32-bit system at all, while a 32-bit file usually starts on a 64-bit system and simply works inside the older limits.

The system side is quick to read: on Windows the System page in Settings states the system type, on macOS the About screen states the chip. Match the file to that line instead of guessing from the file name — a name may say x64, x86, amd64 or nothing at all, and those labels follow no single convention across packagers.

On a phone the same question appears in another form: a package built for one processor family refuses to install on another, and the install screen is where that shows up. When a phone rejects a package outright, the architecture and the system version are the first two lines to compare, not the last.

Interface language is a setting, not a separate download

A frequent reason two files look like different downloads is language. The desktop terminal ships one build for every language and picks the interface language from a menu inside the program, applying it after a restart. There is no national build to hunt for, and a language tag inside a file name is a naming choice made by whoever re-hosted the file rather than a property of the build.

The mobile app normally follows the device language instead of keeping a setting of its own, which is why one and the same package can open in two languages on two phones while remaining, byte for byte, the same file.

So when two candidates differ only by a language tag in the stem, that tag is not a reason to keep both. Keep the one whose version string is higher and whose card is intact, set the language inside the program, and the question disappears.

Keeping one copy and retiring the rest

Identification is only half the job. Once the right file is known, rename it so the name finally carries the identity — product, version and architecture in the stem — and move it out of the download folder into a folder kept for installers.

Then remove the rejected copies. Leaving them costs nothing today and costs a wrong click later, usually at the exact moment the platform is needed. A shortcut still pointing at a deleted copy is the other half of the same clean-up: open it once and confirm it launches the copy that was kept.

Anything that fails identification is not worth repairing. Fetching a clean copy from the account area takes less time than proving a doubtful file is fine, and it ends the comparison instead of extending it.

Eight checks that separate two files with one name

1. Sort the download folder by date and note which copy arrived when — a counter suffix (1) or (2) marks the order of arrival, not the order of versions.
2. Open the file card: Properties then Details on Windows, Get Info on macOS. Read the product name, the file version and the description.
3. Compare the size in megabytes. Builds for different architectures rarely land within a few megabytes of each other.
4. Match the architecture to the system type stated in the system information screen, not to the label written into the file name.
5. Start the installer and read the confirmation the operating system shows before anything is written — the publisher line either matches the source the file came from, or it does not.
6. Check the interface language on the first setup screen, and change it inside the program afterwards if it is not the one wanted.
7. Keep exactly one copy, rename it with product, version and architecture, and delete the others.
8. Point the shortcut at the copy that was kept and open it once to confirm the target is right.

None of these checks touches an account: they decide only which file on disk gets opened. If no candidate passes them, fetching a fresh copy from the account area is quicker than repairing a doubtful one.

Markers that separate two files with the same name

The table judges the file on disk only. It says nothing about instruments, spreads or account settings, which live on the account rather than in an installer.

Which copy to keep when two candidates are left

When two candidates both fail, the comparison is over: neither is the build the machine should run.

Related Exness pages