I’m a bit confused about this situation. If the Wine Win7 environment is stock, rather than SP1, why am I able to install dotnet 4.6.2, if that is supposed to require SP1? On Microsoft’s page (https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements) it doesn’t list stock Win7, yet does that really mean dotnet 4.6.2 won’t install on it? I no longer have an ISO for stock Win7, so I’m unable to confirm one way or the other. Perhaps someone else can try it.
I believe that is in fact the case, as stock Windows 7 fell out of support fairly quickly. SP1 was practically required.
And yet we can install it in a Win7 instance of Wine. 
I’ve scrounged through my old CD/DVD collection of Windows versions and found one that I think might be a base Win7. It’s about my bedtime, so I’ll take it to work with me tomorrow and install it on a VM. If it really is a copy without SP1 I’ll try and install dotnet 4.6.2 and let you know the result.
I can confirm that dotnet 4.6.x, and presumably anything after 4.6 as well, will not install on a base Win7 machine. That leaves us with two possibilities in regards to Wine’s Win7 container:
1 - The dotnet installer is unable to detect it as non-SP1
2 - Win’es container is effectively SP1
Out of curiosity: why stick with Win 7 and not go to 10 for Scrivener? Is there a specific reason (other than preverring Win 7, which I do)?
Cecilia
In my case I’ll never use a Win10 Wine container unless I ever come across something which can’t be run otherwise but which I really want to run. Why throw even more variables into the mix?
On workstations my view of Windows versions is based entirely on my rather long experience with it in corporate environments. Quite simply, Win7 is more stable and predictable than Win10, especially for “power users”, who tend to crash machines more frequently then “regular users”. It’s also easier on the eye and more user-friendly, although I admit that’s completely subjective and some, aspecially the young, will not agree. Two items I’m still constantly hearing from experienced staff members are “it used to work on Win7” and “where did they hide [insert anything here], it was obvious or easy to find on all previous versions”. Starting from Win8, Microsoft (and others since that time) have clearly demonstrated that technology changes and progress can at times be mutually exclusive.
Wine containers do not have Windows versions per se. The version is just an entry in the registry and can be changed at will (even on the fly; you can use one version to start one program and another version to start another program and have the programs interact like if they were running on the same Windows machine).
Most applications do not even look at the Windows version, but look at available capability. That is the case of the dotnet installer, which pretty much ignores whatever you have set the version to. It may complain if the version is extremely wrong, but I doubt it will care even then. I haven’t managed to get it to complain.
The main reason for the “dotnet462 conflicts with dotnet40, which is already installed” error is having mono installed. Make sure to remove mono from the Wine container.
Good to know, thank you!
I had the activation problem with Manjaro KDE. I found the solution explored in depth at
https://forum.winehq.org/viewtopic.php?f=2&t=32869
.
Here’s the step-by-step process from RobK’s post:
Mine didn’t take an hour, but it is a lengthy process, and often seems to have died. I ended up with .NET 4.8, I think.
This appears to have worked for me with latest 3.0 beta (29042) on 64-bit Ubuntu 19.10.
I’ve run the program, adjusted the UI font and exported the interactive tutorial to Word format - checking the result in Office 365. So far so good.
The only changes I made were:
- I had to install winetricks
- I set WINEARCH and WINEPREFIX once at the beginning
- Installed Scrivener from a folder inside drive_c once that was available
I don’t know that any of my variations make any difference. This install was on a VM but I also intend to install it on a “bare-metal” Ubuntu 20.04 machine soon.
There are a lot of errors while running the scripts but it seems we can ignore them.
Here are the commands I ran, based on Mr. Beardie’s:
[code]sudo apt install winetricks
WINEPREFIX=~/.scrivener
export WINEPREFIX
WINEARCH=win64
export WINEARCH
wineboot --init
winetricks dotnet40 corefonts
winetricks win7
winetricks dotnet462
copy Scrivener installer to somewhere on drive_c inside the wine prefix.
change to directory where Scrivener installer is located
wine Scrivener-29042-installer_x64
[/code]
Can’t see a way to edit my last post so:
Unfortunately I wasn’t so lucky on Ubuntu 2004 using the same steps. The program aborts at “Loading spell checker engine”.
Update
I switched to Wine using their repo (advice here wiki.winehq.org/Ubuntu ) and installed the development version (5.4 at time of writing) and Scrivener now works on Ubuntu 2004.
I’ve been messing about on and off for quite a while now so not confident on exact steps required. I had several things that weren’t installed the first time I tried and I think some of my problems relate to the extra hardware I have on a real machine vs a VM.
TL;DR: Scrivener will work on Ubuntu 2004 if you’re technical or lucky enough to navigate the maze.
I’m glad it worked for you. Your approach is certainly the easier if you only have a single prefix and for most users that’s probably the case. A note about why I used WINEPREFIX for each command may be in order, in case this applies to others as well.
I have multiple Wine prefixes on my machine. so I specify the prefix to use in all commands to be sure that it not only affects the intended prefix and never changes anything about my default prefix, which I’ve had for many years. I have too many existing scripts, commands and shortcuts pointing to the default and don’t fancy having to update them all to specify the prefix to use, which I would have to do if I were to point WINEPREFIX to another instance.
Can also confirm that instructions at start of this thread worked for me (Fedora 31 and Scrivener for Win).
Did fresh install of 2.9 Beta 44 on Kubuntu 20.04 today (I spend more time fiddling with software than writing) and found this thread invaluable: [url]https://forum.literatureandlatte.com/t/wine-5-0-and-scrivener-2-9-0-x/48674/1] .
TL;DR: add
winetricks speechsdk
to the list of commands to setup Wine for Scrivener.
This post:[url]WINE 5.0 and Scrivener 2.9.0.x] solved the issues without any additional messing. I’ve run through the process twice now so pretty confident.
In summary, run
winetricks speechsdk
as last step in the install process…
With help from a guy I call The Pro From Vilnius and the above post, the Scrivener registration server was accessible for me. Replaced Win 7 with Linux Mint, After jumping thru hoops it appears that Mono hadn’t been installed so I was instructed to start at Step 4, above, and continue. I elected to load the default .NET framework rev since MS doesn’t support 7 any longer.
Scrivener server accessed, I’m good to go, once again.
Thanks, amigo.
Cheers!
CD
I came back to this after a long hiatus (used Scrivener on macOS in the meantime). I now find it is possible to install the beta (version 2.999), if one sets up a new prefix properly. The env instructions at the top of this thread are quite useful, and I set up the prefix in a wine_scrivener directory as well. Note that you need to have 32-bit architecture enabled for a successful install. I also placed the installer in the x86 Program Files directory, then used wine to run the installer file. Voila.
However, I can’t open the program by double clicking on the Scrivener.exe file inside the new prefix. I have to navigate to the Program Files/Scrivener directory in the terminal and run wine Scrivener.exe instead. That said, the program looks good at first glance. Given the beta version number, Scrivener 3 for Windows can’t be too far away.
Thanks to all on this thread.
The simplest solution to that is to create a launcher and edit its properties so that you set the wine prefix prior to starting the program on its command line. This works great when you run multiple prefixes.
People have been saying that for two years now. I’m beginning to wonder if it will ever come out of beta. As for the version number, I am puzzled by the version 3 betas being given a version number of 2.9. Then again, Windows people seldom understand the way version numbers are supposed to work. That’s something they have in common with Linus Torvalds.
Point the first, there’s no magical inherent “right way” to do version numbers. They’re a labeling convention, and as long as you define what that convention is and use it consistently, that’s fine. (Now, some conventions may have more pros or cons than others given their context, but that’s a whole different conversation.)
Point the second, the released Scrivener 3 for Windows will be 3.0. So using 2.9.x ensures that when you look at the version number, you will immediately know that you’re not up-to-date if you’re still using a beta. No magical parsing, just simple intuitive “2 is less than 3.”
Perhaps you’re too young to recall how version numbering was done in a very standard way in the past. These days it has become quite arbitrary and therefore quite meaningless. This is superbly highlighted by version 3 of Scrivener, regardless of whether it’s a beta or not, being given a version number of 2.
A far more appropriate version numbering scheme would have the current betas number something like 3.0.0.x,b but, as I recall, Visual Studio and the like can’t deal with that, although it’s been a number of decades since I used it.