I can’t reproduce the file issue here. When you say it “happens on a system even without Norton”, do you mean one without Norton installed, or one with Norton turned off (for some definition of “turned off”)? The two are not the same …
The file issue you have looks as if something else has these files open. You could try a reboot and then install, and see if that helps.
For what it’s worth, as another data point, the installation worked for me (on Windows 8.1).
Avast Antivirus did its usual “CyberCapture” thing, i.e. executed the file in a sandbox environment, and then, when nothing untoward happened, let it execute for real.
The installer picked up the current installation’s path, and I installed the new version there.
The update installed on my Win 10 desktop without issue. I do not run any third party anti-virus software, only Win 10s standard installation.
Okay, got it: turns out I had to uninstall the existing version first. I somewhat feel like an idiot. The only thing mitigating my total feelings of inadequacy are that this has not happened with any other version of the I7 IDE. In fact, it didn’t even have a problem with the previous version of the IDE in this case.
From a diagnostic standpoint, a few things:
But on both machines: uninstall first, then install the new version – worked like a charm.
Apologies for the confusion and thread bloat on my part.
That is odd. You’re supposed to be able to install over an existing version without having to uninstall first, and I’ve just tried this again here, and that works for me.
I did not have to uninstall the earlier edition of I7 for the new install either.
Repeated “unable to open file for writing” errors sounds like you accidentally installed as administrator last time.
Possibly, but these are classroom machines so I don’t know if they installed that way or not. I am getting reports from multiple students of this warning on Windows (which they all tell me they never got before with the I7 IDE install; including when they retry the previous one):
All are also reporting that when they get the IDE installed, they are seeing a lot of this error:
When I had them compile anything, they reported getting this:
It is very unlikely that your computer is at fault. More likely causes are:
disc space running out on the volume holding the project;
trying to run a project from a read-only volume, such as a burned CD or DVD;
trying to run a project which belongs to another user, whose files you have no permission to alter.
When I had them look at the actual console view, they are all seeing errors along the lines of:
Unable to open extensions documentation index for writing
Offending filename: <C:\Users\THEIR_USER_NAME\Documents\Inform\Documentation\Extensions.html>
Going to have them try clearing out the Documents\Inform folder entirely and seeing what that does.
I can repeat their experiences on my own machine; tried that of course just to make sure that folks weren’t trying to install as one user on something that was previously installed as another.
Of note, though, NONE of these issues happen if I just install the previous version that was made available. That works fine. No warnings, no issues, nothing untoward.
That “code 2” error is almost certainly antivirus-related – I just ran into it last week (see here for my thread requesting help, which includes a link to another, more detailed one). Adding Inform to your whitelist, or temporarily disabling the antivirus program, should clear it right up!
Interesting! Thanks for pointing that out. What’s odd is that this never happened before. And these classroom machines have all had Norton running on them since the beginning. The census code 2 issue does happen even if Norton is not enabled; specifically, smart protect is disabled.
Equally baffling is that this does not happen with the previous version of the I7 IDE on Windows. That installs (with full Norton running) without any issues or warnings whatsoever.
That, of course, points to an easy solution, of course: just use the previous version. 
That you get a Windows Defender SmartScreen warning isn’t entirely surprising. From Microsoft’s blurb:
Microsoft Defender SmartScreen determines whether a downloaded app or app installer is potentially malicious by … checking downloaded files against a list of files that are well known and downloaded by many Windows users.
The previous beta has been around for a year, and has presumably been downloaded quite a few times, so it passes the test. The new release will, I assume, eventually be downloaded lots of times, but as I only released it today it’s not often been seen before. It seems likely that the SmartScreen warning will eventually go away of its own accord.
As Mike says, the most likely cause of the “code 2” errors is interference from anti-virus software. The actual Inform 7 compiler that also generates the extension census (“ni.exe”) is exactly the same file as in the previous build, if you check with Windows Explorer you can see it was created back in 2020.
I’d be interested to hear people’s opinion on the whole “vertical tabs on the right” versus “horizontal tabs along the top” issue. I haven’t entirely decided which I prefer, though having the tabs vertically feels like it makes more sense on a widescreen monitor.
Regarding the positioning of the tabs, it’s interesting in that one of the reasons I wanted to update the editor was because the interface was now more consistent between the Mac and Windows versions.
However, I’m now finding that students on Windows who tried the “vertical tabs” approach have all switched back to the “horizontal tabs.” Those on the Mac are now voicing that they wish they had the option to move the tabs horizontally. The common expression of preference was that it was easier for the eye to drift up to change panels rather than drift all the way to the right.
Speaking for myself, I move between Mac and Windows versions quite a bit, but I have to say that I too find my preference for the horizontal approach.
One thing I noticed on my system (using a 4K monitor at 150% scaling) is that the text on the vertical tabs doesn’t seem to anti-alias properly. Not sure whether this comes across properly on a screenshot, but here goes:
(If you don’t see it, please take my word that it looks significantly more jagged than all the other text in the application.) The horizontal version looks normal.
Apart from that, I’m inclined to agree that the horizontal version seems more “natural” somehow.
I definitely prefer horizontal tabs and set that option in Edit>Preferences>Advanced tab.
On the one hand, I didn’t actually have a strong negative reaction, as I thought I would at first, because of the change to what I’m used to. I could adapt to the new layout.
But I do prefer the old style, because:
I agree with ArdiMaster about the anti-aliasing. The “y” in the vertical “Story” is a bad offender, for example.
I think the widescreen argument sounds sensible, but for me personally, it is not completely compelling, because I’m using a relatively large font size, and due to that, I don’t have very much screen width to spare.
In the new vertical mode, the two sidebars are wide enough to sometimes cause additional wrapping/line breaks, which is of course not pretty (and also negates the maximally one-line space gain due to the missing horizontal panel). Example:
I think having the tabs horizontally on top, as before, is a more widely-used “paradigm” in general, which speaks in its favour.
Even if one switches to the new vertical tabs, one still has to use UI elements at the top: the general menu (File, Edit, …), of course, and especially the sub-tabs like “Report” & “Console” under “Results”, and “Contents”, “Actions”, etc. under the Index, and so on.
So now the attention is “broken up” a bit, and having the tab-choice UI elements at the side is slightly “inconsistent”, one might say. To look at the Actions index, one would now need to click on the vertical Index tab to the right and then move to the top again to click on Actions.
Of course, it’s not the end of the world, but it doesn’t seem like an improvement either.
Having these choices at the side adds a bit more “visual clutter”, instead of just having the source code (or story/documentation text) and a scroll bar there.
If it’s not too much additional maintenance work, I’d suggest to keep both options, but set the default to the old horizontal style with the tabs on top.
I agree with others who prefer the horizontal tabs and as such have set mine accordingly.
Yes, I have noticed that. In both the horizontal and vertical cases it is just using Windows’ font rendering, which seems to make a better job of anti-aliasing in the former case than the latter. As the former is by far the commonest case I guess that that is not surprising.
Zooming in on a screen shot of the buttons is interesting. A composite image:
This is the text for the “Story” button, firstly from a screen shot with the tabs horizontal; then with a screen shot with the tabs vertical; and then finally the first “Story” rotated through 90 degrees. This suggests that maybe rendering the text horizontally and then rotating it will give better results.
Sub-pixel rendering should be accounting for the higher horizontal density of most screens. (And if Windows is responsible for rendering the text then it should account for all the various pixel options.) Manually rotating text will probably be counterproductive.
Back in the 1990s when people used CRT displays, anti-aliasing text just used intermediate shades between the foreground and background to smooth out jagged edges. In the 2000s when LCD displays became common, eventually somebody realised that since an LCD display actually has specific Red, Green and Blue sub-pixels laid out in a fixed pattern, you can adjust the brightness of individual sub-pixels to render text more crisply. Done naïvely, this adds distracting colour fringing, but with a little horizontal blur it looks like regular anti-aliasing, just… sharper.
The key detail is that because the Red, Green, and Blue sub-pixels are stacked horizontally, text can accurately be positioned horizontally, but vertically we’re still constrained to pixel units. In the microscope image above, you can see that the sides of each “o” are smooth, but the tops and bottoms are still lumpy because there’s no additional vertical resolution available.
Microsoft Segoe UI, the interface font introduced with Windows Vista and which Windows still uses today, was very deliberately designed to look good with this kind of rendering - the left and right edges of (horizontal) characters are smoothly curved, but the tops and bottoms are designed to snap to crisp pixel boundaries, to make the best of the rendering opportunities available.
The upshot of all this is that rendering horizontal text in Segoe UI looks great, rendering vertical text in Segoe UI looks weird (because the crisp bits are smoothed and the smooth bits are crisp), and rendering text horizontally then rotating it is just going to make a colourful mess (since the colours are no longer aligned with the display’s subpixels).
