Potential end of the line for Windows support

[joncampbell123]

http://news.slashdot.org/story/16/03/12/1634229/windows-10-upgrade-reportedly-starting-automatically-on-windows-7-pcs

I'm adding it here because the admins on the Vogons forms locked the original thread. I personally believe this is a worthwhile protest and I am not trying to be pretentious about it at all.

I have no tolerance for a company to force OS upgrades on clients. I am considering giving up on maintaining the Windows-specific code in DOSBox-X. I will pick a stopping point, and tag that commit, so that others can continue to do Windows development as they please. But the main branch that I develop on will not improve or develop Windows-specific features past that point, and the Windows code will be slowly removed and replaced over time.

[ghost]

I agree. I wouldn't be suprised, at this point, if linux offers greater compatibility in running legacy software than the newer Windows versions. Also, reading the commits of other projects, the majority of changes are often to accommodate different compilers and their versions. This maintenance soaks time away from other work.

About that Vogons thread: they are fairly aligned with gog.com which is reliant on Windows users. They typically defend that position without fail.

[DominusExult]

Whatever you decide to do is fine but these claims of Vogons admins being aligned with gog and defending stuff... Total bullshit. Talking bad behind others back is really low.

[sikthehedgehog]

I wouldn't be suprised, at this point, if linux offers greater compatibility in running legacy software than the newer Windows versions.

I'm on 64-bit Ubuntu. I can run programs for 64-bit Linux, 32-bit Linux, 64-bit Windows, 32-bit Windows, 16-bit Windows and DOS, and that's including the PC platform only. I don't think you can beat that right now.

Also I wonder how this would align with what Tim Sweeney was saying lately.

[crawlingChaos]

I would ask that you please reconsider phasing out Windows support. While not developing Windows specific features seems completely reasonable, I would ask that at least cross-platform build support be maintained.

Like you, I have no love for Microsoft's shenanigans. I run exclusively Linux, having ditched Windows years ago. I used to hold pretty much every major Microsoft certification, until I got tried of being jerked around by an OS that constantly fought what I wanted to do in order to support only what Microsoft wanted me to do. No thanks to that.

That said, many people haven't yet made the same realization.

I am a member of a retro-gaming community that is looking for a Win9x gaming emulation platform to standardize on and I have recommended to them DOSBox-X as the solution. It is a large community and would likely be able to offer a lot of feedback and testing across a huge variety of games. The caveat is that although a number of members run linux, the bulk do run Windows. Only a solution which works on both platforms will fit the community's need. I would gladly help out with any support issues, even taking on the responsibility of maintaining the Windows build if necessary. While more and more members of the community seem to switch or at least try out Linux every day, to drop support now would mean DOSBox-X would become unusable to the community as a whole and another solution sought. I think that would be a waste as DOSBox-X fits the need better than anything else out there.

Thanks

[joncampbell123]

Then I'll leave a branch open for anyone who wants to do Windows development on the code. But I still don't plan to continue spending any of my time on Windows platform support in the code.

[crawlingChaos]

Thanks. If it were for my own selfish use, I'd dump Windows support too, but I'm trying to help out a fairly large community. Do you still plan on releasing a Windows binary? If not, I can always pull from your code and release it on mine. I already keep a Windows development VM around for other reasons.

[theophiluso7]

Jonathan Campbell is just being a stubborn asshole who wants to pull a political stunt which Microsoft won't listen to anyway.

[joncampbell123]

I do not plan on releasing Windows binaries either.

[joncampbell123]

@chrisBGithub Nice! And you give Nadella fellatio too?

[sikthehedgehog]

OK so this is going to turn into a flamewar then?

[joncampbell123]

I'm stating that I'd rather focus on Linux and Mac OS X development and leave Windows development to anyone else who is more interested in it. I've written my share of code for Windows for over 20 years now (yes, starting with Windows 3.1!) and I'm disappointed with the direction that Microsoft is taking Windows. But since 8 years ago, I've become a lot more comfortable with Linux and I see less and less need to write anything or use anything in Windows at all (literally the only reason I have Windows now is for Adobe Premiere). I'm at a point now where I don't really care to support Windows anymore and I don't wish to waste my development time supporting it. Nadella pushing Windows 10 down everyone's throat is just the final nail in the coffin for me.

[joncampbell123]

@sikthehedgehog Nah, just wanted a good comeback for laughs.

[crawlingChaos]

OK, I'll plan on doing Windows releases on my fork, thanks.

My build environment will be strictly Windows 7 though, since I have no desire to run the malware called Windows 10. Windows 7 is bad enough. I am completely opposed to the walled garden approach that Microsoft seems determined to take. Lock-in to any app store is an abomination in the software world and I will have no part in it.

[Jarvik7]

Having recently built a windows gaming PC after about a decade of OSX-only (switched just before Vista launch), I don't really understand all the hate for Windows 10 vs Windows 7. All of the spyware has been backported with security patches so Win7 is just as bad in terms of spying on a stock config. The app store isn't mandatory in any case. The force feeding of Win10 onto existing PCs is kind of ridiculous I'll agree though.

Hopefully the code remains reasonably portable. I can offer my occasional limited support for Win and OSX builds (no Android build? :P), but work takes priority sigh.

[crawlingChaos]

Jarvik7,

I can't speak for anyone else, but for me it's a collection of things rather than any one thing.

Running Windows means dealing with a bunch of crap that I don't have to deal with under Linux. First, there's activation crap, then advertising crap, wonky flat UI crap, DRM crap, technology lock-in crap, random MS technology paradigm shift crap ( e.g. Silverlight, XAML, Universal Windows Apps, etc.), forced updates crap, spying crap, half-assed feature crap (Storage Spaces, File History). It all adds up to a whole bunch of crap I'd rather not deal with. And while the app store isn't mandatory yet, it has been clear for some time that Microsoft wants to head that way.

I don't much like Windows 7 either and you are right a lot of the spying crap has been backported, but it's still a much lesser evil than Windows 8+2.

I still do some Windows dev work in my day job, so it's not a huge deal to produce Windows releases to help out some people who for whatever reason choose to deal with Windows. However, I can totally understand a developer not wanting to have to deal with it at all. We all only have a finite amount of energy and time, and supporting Windows requires both.

[ghost]

Disabling automatic updates should help, but I've heard that they took care of that as well.

Speaking of flamewars, I'm surprised that nobody yet mentioned the 6-month cycle of most Linux distributions as a kind of forced upgrade.

[crawlingChaos]

@Enthymem,

There's a huge difference. With Linux, you are free to choose your distro (or no distro at all) to suit your needs. Debian has a longer support cycle than some other distros. You are also free to ignore any updates you don't care about, and Linux doesn't typically download tons of monolithic updates requiring system reboots just to change how some minor system tool functions regardless of whether you even have it installed. Don't even mention Windows 10's sharing of your bandwidth to supply updates to other people.

Yes, you can turn some Windows 10 things off with regard to updates, UI settings, and and spyware (sorry, telemetry), but the level of control is pathetically low, with user-hostile defaults. By the time you fight back against the OS enough to configure everything to be semi-reasonable, you couldv'e configured a hundred linux boxes from scratch. Why choose an OS that fights you tooth and nail, vs one that does what you want it to? I choose not to waste my time with a product that clearly wants to do something other than what I want.

[joncampbell123]

@Enthymem There are a lot of Linux distros to choose from, including ones that don't force upgrades. Or you could do as I do and build your own Linux system from source, then only you can force upgrades :)

http://www.linuxfromscratch.org/

Can't do that with Windows!

[crawlingChaos]

@joncampbell123

Funny you'd mention linux from scratch. I use it too. I wrote my own script to automate the entire thing so I can kick off a build and come back later to a complete linux system built entirely from source. :)

[sikthehedgehog]

Ubuntu does do the annoying thing of bugging for upgrades every whenever one is available. It also waits until you actually click "OK" (or reject it), and also gives you the option (in that same prompt!) to stop bugging you until you decide to upgrade on your own. No risk of automated upgrades because you happened to be away from the computer when it decided to do that.

So let's say there's a big difference there.

[ghost]

I'm well aware of the differences. I only brought that up because it's a common argument that arises whenever someone points out the obvious, that forced upgrades are a bad idea and not only because they take away your freedom of installing only what you want or need (think of a layperson trying to solve an issue caused by an update -- I've seen a lot of that).

Cutting-edge, bleeding-edge and rolling release distros are your best choice if you have recent hardware. The drivers are constantly improving, so it does no harm to live on the edge, if you are careful. (LFS seems like too much work for me, though.)

[joncampbell123]

Okay, remember my original gripe on the Vogons forums? Well, I hate to sound cliche but I told you so

http://www.tomshardware.com/news/windows-10-auto-schedules-updates,31802.html

[ghost]

Following Google's Android example and possibly Apple's, It seems like the move by MS has been toward a short-term licensing scheme in the application and operating system market. However, I would think this strategy is not attractive to large businesses who incur high costs from the continual upgrades both in software and corresponding hardware - nearly mandatory from the loss of support and bug updates. It will be difficult to change this since MS has the application and some other markets (such as Office products), but I think these moves will fragment retro-gaming onto the older Windows versions and Linux (including OS X). There is also a conscious and unconscious effort to deprecate support for older Windows games (such as midi support, full directdraw and directsound capability, ntvdm issues as described on djgpp forum - Dos related in this case, and multimedia extensions to the desktop which are enabled by default).

Probably the main benefactor is gog and its Vogons proponents.

[joncampbell123]

I can understand deprecating the old Win32 API, it's almost terrible. By that I mean it's useful, it's kind of stable, then when you get down to details there's subtle things about it that cause problems and headaches especially where multi-threading is involved. A lot of it from my experience comes from the fact that some APIs originated in cooperative multitasking systems like Windows 3.1 and then they made a somewhat messy transition to 32-bit, then multithreading (like the waveOut functions). For example, did you know that when a thread creates a window with CreateWindow(), only that thread can talk to the window? So if you thought you could write a program where the main thread runs the message pump while a second thread draws an animation on it, you're wrong :)

My hope that as Microsoft deprecates the old Win32 API bit by bit that projects like ReactOS and Wine fill in the gaps and allow legacy programs to run and that virtual machine software like QEMU and VirtualBox eventually emulate all the hardware acceleration we took for granted during the XP era, and that DOSBox-X fills in for the Windows 3.x/9x/ME era as well. If they remove NTVDM, well, I honestly wouldn't miss it. NTVDM sucks. You can see what I mean from my comments and hacks in the DOSLIB project.

[joncampbell123]

Speaking of fragmentation, I've had this crazy idea for a long while that might be an interesting project. What you do with the project, is install the base OS (Windows 3.1, 95, 98, ME) and then overwrite system files with ones compiled from the project. You would have a project that, bit by bit, replaces the Microsoft components with open source ones, until eventually the open source bits can stand on their own as a complete Windows 3.1/9x/ME compatible system. Then once you've done that you can adapt the kernel to run on modern processors and hardware, and retro gamers could rejoice and enjoy their own games again without worrying where Microsoft would take you today :) It would be the 3.1/9x/ME complement to ReactOS's focus on NT-based Windows. Bonus points if the open source Windows clone runs atop FreeDOS.

[joncampbell123]

Anyone up for that? You can make things easy by first cloning Windows 3.1, which should be dead easy since Windows 3.1 is basically the Windows API atop a DOS extender atop MS-DOS.

[ghost]

I wasn't aware of the win32 limitations, particularly in its multithreading. Also, it makes sense to move toward emulation (and wrapper) solutions, even if Linux is the main target OS.

I agree on an open source solution to Windows. As you said, ReactOS is NT like in its functioning, but its model is not ideal for 9x games for the same reason Linux runs slow in dosbox-x (presumably the way that these kernels work in contrast to Win95). I've wondered if the Linux kernel can be adapted for dosbox-x so that it runs faster and does not expect the elements of physical hardware to enhance performance or multitask. These are not great solutions, but they could serve as demonstrations (I think jdosbox tried something related and was able to run simple Windows programs, maybe it was using wine). Another similar project was part of hx-dos and these had system file replacements.

Edit: from jdosbox web page.. "Support for Win16 and Win32 games by porting over WINE code to Java Status: Age of Empires Demo and Caesar 3 both run rather well. Currently I'm researching a more complete WINE port of GDI32 and USER32"

[joncampbell123]

I don't think there's much the Linux kernel can adapt to run DOSBox-X faster. There's already code there that could be used for improved emulation speed. Here's what I have in mind as possible CPU emulation "cores" for future development with DOSBox-X:

• Dynamic core (rewrite, better suited to the new design in use now). Runtime translation of x86 to the host CPU would provide a good speedup just as the DOSBox 0.74 dynamic core does now.
• Use the virtualization extensions that all CPUs have nowadays to run the DOS machine (Intel VT-X and AMD-V). Linux already offers a kernel interface to use this mode of the CPU, look at the "kvm" interface. QEMU already has support for this interface. DOSBox-X would politely notify the user in the log that the VT core uses the host CPU to execute instructions and may not precisely act like the CPU type requested (i.e. runs the DOS system but does not necessarily have the quirks of a 386 or 486). I envision offering this by adding something like "core=kvm" to dosbox.conf.
• Fork and exec into a "naked" process, where no pages are mapped except what DOSBox-X allocates to the guest OS. Linux's ptrace() debugger functions are used to trap and emulate all attempts at I/O and memory pages that are not RAM and switch to the "normal" core if the instruction pointer wanders into the upper 1GB normally reserved in the memory map for the Linux kernel on 32-bit systems. Note that ptrace() can even trap system calls, so doing this would not prevent running a Linux guest on Linux this way. If you don't think that's possible, look at "user mode Linux" which uses this technique to run a whole Linux kernel and user space inside a user-mode process. I would add that the Linux kernel is usually compiled with a syscall that allows a process to create 16-bit code & data segments and run them in user-space even on x86_64, because if it didn't, WINE wouldn't be able to support 16-bit and 32-bit Windows applications. Finally for obvious reasons, DOSBox-X would revert to the normal core if the guest is in protected mode and running in anything other than CPU ring 3 user-mode. Perhaps you could use this by adding "core=ump" (user mode process) to dosbox.conf.

[joncampbell123]

Obviously though, those ideas take a backseat to ensuring that DOSBox-X stable and working properly. Software emulation takes priority so that compilation on other CPUs will result in working emulation. But as long as software emulation works I would entertain these ideas to speed up emulation on x86 and x86_64 processors.

Okay, I know, technically the last two aren't emulation of the CPU, but, the hardware and I/O would be emulated around it.

[ghost]

Without doubt, all three of your ideas are impressive and worthwhile. Disregarding the large performance advantage of VT-X, I like the 1st and 3rd because they are generalizable while the VT-X (and related extensions) is cpu and system specific. The 1st idea seems similar to the more portable dynrec core in dosbox (as opposed to the dynamic core), and with limited understanding, I recall that the dynrec core focuses on certain memory operations which must be the more costly cpu operations. In porting, there are few that can currently do translate the cpu operations since it requires thorough knowledge of the target machine architecture and cpu instructions, notwithstanding the fpu instructions, too. That dynrec core is not really documented either, although it has been called self-documenting. A more thorough explanation of the core may be enough for a simpler porting effort.

The 3rd idea seems better than the 1st idea. The ability to run linux in user mode on dosbox-x should allow for the wine compatibility layer to work and display to screen, if I understand the method correctly; and it sounds very feasible, even if the details are beyond my experience. Also, this idea would allow others to contribute code because it would be in C/C++ and not require extensive assembly language knowledge. I don't think every Win95 game has to run either, but the important ones would make it worthwhile. It should also be fun to work on. However, I don't know the performance of a ump core - I would think it must be better than the native linux installation in dosbox-x!

[joncampbell123]

Actually, my understanding is that the VT-X/AMD-V emulation would be easier to do because the CPU would give it's full support for real/vm86/protected mode, guest paging, and guest memory mapping, while the "user mode process" mode would be useful for x86 CPUs that lack the VT-X/AMD-V but it requires some more work to make sure the code running in it is "trapped" in the emulation and not allowed to call out to the real Linux kernel nor execute/read/write memory in areas that DOSBox-X cannot memory map (like the top 1GB on 32-bit systems). Either would be a fun challenge for me to try.

[ghost]

I haven't seen any examples outside of vmware and virtualbox which use the VT-X emulation. Perhaps the other emulation developers don't have a good template to copy. :) It sounds like it would provide for very good compatibility, too. I also thought that the user mode process core would work with non-x86 cpus, but if it doesn't, then that mode may be less interesting.

[ghost]

Speaking of fragmentation, I've had this crazy idea for a long while that might be an interesting project. What you do with the project, is install the base OS (Windows 3.1, 95, 98, ME) and then overwrite system files with ones compiled from the project. You would have a project that, bit by bit, replaces the Microsoft components with open source ones, until eventually the open source bits can stand on their own as a complete Windows 3.1/9x/ME compatible system. Then once you've done that you can adapt the kernel to run on modern processors and hardware, and retro gamers could rejoice and enjoy their own games again without worrying where Microsoft would take you today :) It would be the 3.1/9x/ME complement to ReactOS's focus on NT-based Windows. Bonus points if the open source Windows clone runs atop FreeDOS.

Yes, that is definitely an interesting idea! :) It would also allow for not having to have a purchased copy of a guest OS (eventually), correct? Because you're saying that you are going to build your own modified OS that is open source while at the same time being compatible with windows 9x games?

[joncampbell123]

That's the idea. As you progress, replacing it bit by bit with open source implementations, you retain the ability to run Windows 3.1/9x and test how software works with your code vs Microsoft's at all times. Doing so also means that, if it is designed properly, you can easily interchange open source and closed source components as needed, such as running closed source video and sound card drivers atop the open source implementation. I also envision the project opening up the possibility of being able to run Windows 3.1/9x/ME compatible software atop FreeDOS.

[aybe]

Have you seen this attempt to run a Linux terminal in DOSBox ?

http://bisqwit.iki.fi/source/linux-for-dosbox/

[ghost]

https://www.vogons.org/viewtopic.php?f=32&t=27467&start=140#p272724 https://sourceforge.net/p/boxedwine/code/HEAD/tree/

I recall that the above method of porting wine to SDL replaced the original method of running a version of wine inside jdosbox. It may be because the scheduling of the wine threads was faster. However, dosbox-x should be faster than jdosbox so a "ump" core may be viable with the current cpu cores -- and any vt-x core would render the issue moot.

I believe gog is using wine to port games, too, so wine must sufficiently run games in linux.

[aybe]

I will handle the building and release of Windows binaries, thorough testing is another thing, though.

[joncampbell123]

I've started making Windows builds again.

[aybe]

Ok, cool, sadly I have no free time at all these days to contribute to the project, barely played a few hours in the last months :(