Windows system wide installer


Hello everybody

Let me introduce myself. I’m a mathematic and computer science teacher in france, and also a sysadmin.

In France, whe are this year beginning to massively introduce computer science in High School and all kids gonna learn to code.

I think Atom would be a excellent editor for them. I’m beginning to translate the interface really soon (I’ve some vacation in a week).

The real problem for us is with the installer. I’ve just opened a bug (enhancement request) and it was closed as the actual installation was described as intentional on windows.

Actually, Atom install itself in %localappdata%. . This is not a use case for us for many reasons.

  1. On many LAN in France, executable are deactivated in %localappdata% or in any personnal folder to prevent code execution from pupils for security reasons.
  2. %localappdata% is usually for us server storage. Server storage is not unlimited, it’s expensive. Atom is almost 370M big for it’s installation. In a high school with 1000 pupil, this make 370G of server storage for just one application ! Clearly not possible.

The correct way would be to have Atom installed in %programfiles%. I’ve made a simple test by putting the atom program folder in %programfiles% and … it works. For a single user only may be ? But we do not use TSE server, we have only one pupil on one computer.

The actual installer works perfectly for the developper use case. But for pupils in high school it’s not usable.

Pupils are tomorrow developpers and they will later use what they are used to.

in another post, idleberg said he add 10 years experience in windows installer and would be glad to help with an nsis installer. May be it should be a solution ?

Thanks for reading so far. Hope our use case will be taken into account so I can spread atom in hundreds of high schools !

Sincerely yours



I’m tagging @idleberg so that he gets a notification.


Google offers Chrome for Work, which installs the browser using MSI to %PROGRAMFILES% (rather than %localappdata%.) I wonder if their install script is available somewhere.

I’m willing to put together an installer for Atom using NSIS, but I’m not sure whether that’s still the best solution in 2017. Anders, one of the NSIS developers, has written about the (dis)advantages of both, NSIS and MSI. Signed installers might be important for your organization, otherwise I don’t know if MSI has any major advantages. Rolling out to multiple computers at once?

Before anybody brings up Inno Setup – when compared to MSI, there is probably little difference between Inno Setup and NSIS other than personal taste. There’s first-party MSI on one side, and third-party solutions on the other. I have written installers (and actual Windows tools) in NSIS for a lengthy period, so I certainly feel more at home using it. And since I’m supporting the NSIS developers in contributing assets and working on the new website, I might be a bit biased as well :wink:

I am mainly using macOS these days, but I still have an old desktop computer capable enough of running Windows 10 (also: Windows 2003 Server in a virtual machine!) I’d have to get familiar with building Atom on Windows and then figure out what the current installer (Squirrel?) does. Do I have to worry about the version of Node that ships with Atom or is that handled internally? Is apm installed by the installer or inside Atom using “Install Shell Commands” dialog?


Today, MSI main advantage on a network is massive deployement with GPO. In a school environment, that’s clearly the main point.


In that case, I can’t help you. Sorry.


An installer can easily be wrapped to be used in GPO also, and (most important) with wpkg to deploy on a whole network in a breeze. So a correctly made system installer, with NSIS , is a good solution anyway :slight_smile:
Pleeease :slight_smile:


This seems apropos:

Historically Atom was first developed on the Mac, and all-too-many addon packages are still only tested on that environment. I’d suggest writing up your requirements (good start above) and send them on to @damieng.


Already responded on the issue at


Damieng, I appreciate all the work you’ve already done to bring atom to windows. Usefull with a bunch of pupils in portable version for me already (4 pupils using atom and floobits to worl on a project)

I understand that you actually use squirrel for installation, that this is user folder oriented and you have no time to create another setup

But, if someone else like idleberg or may be even myself, would develop an installer, be it with NSIS or something else, should we hope to have some help to integrate this in atom ?

I think our need is relatively clear, and helping atom to go on the way to standard install procedure would be very helpful to bring atom to our school system (where data only holds data and executable are deactivated through GPO)

Thank you for your work and for reading so far


If you notice in the Atom Releases list, we’re already supporting 11 different packaging formats for every release. Eight of those 11 packages are specifically for Windows. Because we now support both 32-bit and 64-bit formats for Windows (something we do for no other platform), what you’re asking is for us to support and maintain two more packages for every release. (Even if we don’t have to build it ourselves, history shows that ongoing maintenance will be on us.) I don’t think that it is unreasonable for us to draw the line at eight and say that if this is something the community wants, the community will have to support it.


Hello leedohm

Indeed, you already have a bunch of installer version. I fully understand your concern about an eventual additional work. You already did a real lot’s of work for the community.

May be this installer should replace the actual MSI installer. This one is possibly quite deceptive as people tend to think it will install system wide and it only deploys an installer, hidden, without icon or shortcuts.

Replacing the actual msi installer with a real system wide installer should be the target. It would not increase the release volume. It can even decrease it. An installer correctly made should install 32 bit or 64 bit version automatically without having to maintain both.

the goal would be to broaden the audience without adding a burden to the team.


I’ve done some test with an install in %PROGRAMFILES% today

Atom works correctly but some plugins no more works (floobits for example). It seems that some plugins rely on atom program living in userspace (%localappdata%)

Is this to be considered as normal or as a bug ?


I would assume that this would be a bug, but I would have to understand why they are depending on this location to be sure.

The current MSI installer is generated by Squirrel for Windows. I talked with the maintainer of Squirrel last night and he is familiar with the problems of installing Atom and other programs to %PROGRAMFILES%. We would prefer to stick with Squirrel if at all possible. You may want to talk to him about what options there are while still using Squirrel.


If a new/alternative installer would install Atom to %PROGRAMFILES%, I’d still expect it to store settings and packages in user-space. Sounds to me like you’re actually after a portable version that can be deployed easily.


I totally agreee with you, settings and packages shall be in user space. (Packages should be also installable system wide, but’s another story)

I’m not seeking a portable version at all. I’ seeking a standard installed version :

  • binaries and libraires in application folders, that’s %PROGRAMFILES%

  • settings in userspace, thats %userprofile%. By the way, atom actually uses %localappdata% wich is irrevelant in an environnmeent you use roaming profiles. %localappdata% is located on computer, and user profile is network wide. %userprofile% is synchronised across computers. That is, if you install a package in atom on computer A, you have it installed when you log in computer B.

Actually, using %localappdata% in our highschool makes atom totaly disfonctional. Pupil has Atom on computer A. He uses it, and the next morning he goes to computer B. All customisation, packaging, and so on, is lost ! Even if he returns to computer A the following days, he will have lost everything potentially, because every 24h, the local profiles are deleted (with 1200+ profiles, it’s mandatory to not explode dsik space)


The problem with installing into %PROGRAMFILES% is that every update will require a UAC prompt and admin privileges or you’ll have to develop an always-running background agent to deal with it like Chrome does.

Additionally the first person to upgrade Atom could break things for other users if the packages they rely on do not work with the new version of Atom and they’d have no way of going back.


This is not a problem.

In a production environment where hundreds of computers are centrally managed, we don’t want our thousands users to make updates. We don’t want neither automatic updates. We do updates with central management, after being sure that the update don’t break things.

We work with firefox ESR to have few updates. We use chrome for work and not chrome to manage updates, and so on.

Managing ten or twenty computers is not like handling 600 or 700 computers. In schools, we have only one part time technician to manage all these hardware. We clearly do not want to have bleeding edge. We want that it works. That everytime a teacher comes in a classrom, he is sure that everything is working fine.

So we are really conservative about updates.

Having updates not done by users or automatically is not a problem. It’s wat were looking for.


You should be able to just unpack the (or to c:\program files\ using your deployment tools and then just create a shortcut that points to the atom.exe in the all users group.

If you’re not using deployment tools you can achieve the same thing with just a couple of command lines - one to unpack atom and the other to create the shortcut, e.g.

7z x -o"%ProgramFiles%\Atom" \\server\apps\ 
powershell "$s=(New-Object -COM WScript.Shell).CreateShortcut('%ProgramData%\Start Menu\Programs\Atom.lnk');$s.TargetPath='%ProgramFiles%\Atom\Atom.exe';$s.Save()"


Yes, I already did, with wpkg. But now, I’m into removing atom because the personnal folder is not placed into roaming folder but into a local computer folder. So each time a pupil change computer, all customization is lost. Clearly unusable in production environment


The location of the .atom folder can be customized using the ATOM_HOME environment variable as mentioned in atom --help.