-
I spent yesterday adding $(foo) style backquotes to my Windows based shell, Yori. I expected this to be simple since the traditional backtick style was already there, but nested backquotes make for more sophisticated parsing at execute time, and tab completion wants to determine the currently “active” command in order to know which completion rules apply. And obviously, since you’re still building a command when hitting tab, it can’t assume a well formed expression, sigh.
Back at work, my boss is back this week. Another sigh.
-
-
Obviously this is somewhat opinionated, but…
Powershell, IMO, is a very powerful shell. Its object model provides for quite reliable scripting, and the way it exposes many aspects of the Windows system makes it very useful for system administration. At work we have a requirement to do this type of administration, and it’s the right tool for the job there. As a developer who’s primarily after an interactive shell though, the benefits aren’t readily apparent (my compiler, editor, revision control etc are not Powershell commandlets) and it’s rather verbose/cumbersome.
Cygwin/msys are useful tools for people who want to use Windows but have a fully Linux-oriented command environment. I say “fully” because integrating Windows tools into a Linux toolchain is a little clumsy due to their different semantics - eg., direction of path separators, which component does wildcard expansion, migrating environment variables between the two, etc. Obviously there are ways to do interop, but using one of these shells to invoke primarily Win32 processes doesn’t seem great.
So the short answer is that just due to where I am, I’m a developer using predominantly Win32 native code tools, and neither of the above options are really optimal for that. Cmd is just ancient; Yori trying to rethink what a native Win32 shell would be in this decade, and heavily borrows from Linux shells but implements it with a view to invoking native Win32 tools. Some day I probably won’t be a developer working on predominantly Win32 native code tools, and when that day comes, Yori will be a lot less interesting/useful to me. I mean, I certainly don’t see any point porting it to other platforms, for example.
-
-
-
I occasionally write about Win32 and its history, being something I know. I haven’t done it in a while and should do more though.
-
-
I’m writing a Windows package manger. Obviously this is done to death and mine won’t be any better than the last thousand, but just like the last thousand, I still need a system for installing/uninstalling/upgrading the software I distribute, and I’m really looking forward to being able to efficiently say “upgrade all from the Internet” from the command line without copying new installer binaries around.
I’d like to know why DosBox-based games are on this list, since DosBox on Linux doesn’t need things like Wine and would function the same on Linux as on Windows.
Separately, there are tons of Steam games I have that have Linux ports but the Linux port isn’t natively on Steam (eg. Quake, Unreal, etc.) I’ve never understood why this is. I end up using a custom compiled ioquake engine with assets from Steam, which works great.
With older games that were ported to Linux, the distribution rights are often (but not always) with a different publisher.
Since Steam requires a game to have ports for different platforms of the same title under the same product ID (and thus publisher), there is no way to set up a proper revenue sharing system for the owners of the Linux ports (or Mac ports, old Mac games are in the same boat)
Steam initially required a single title to be a single product ID because they don’t want publishers to make people re-buy old titles that were newly ported, in order to boost SteamOS adoption - this way, many players would have a half-decent Steam library from the get-go on the new platform.
Many of the old porting shops for Linux and Mac have gone under, or the ports haven’t been maintained since before Linux 2.6 or even 2.4, meaning that many of the ports can no longer be trivially made to work on modern day distributions. Many games from before say 2003 used SVGA lib to render directly to the framebuffer, for example, without going through X11.
So, sadly, many of these ports are lost to the sands of time and the murky status of IP limbo.
This does not explain why DosBox titles are run through Wine, but I guess that’s just a matter of the publisher not being interested in making and testing a Linux build, given the limited revenue that comes from the platform. These re-releases are probably a very low budget and low income affair, more for the sake of IP owners being able to point to them and say “see, we still provide these products! Preservationists which are distributing our old games are plain pirates, they are not serving a higher purpose!”. But maybe that’s just me being cynical.
I’m sure in a lot of cases you’re exactly right. I’m just frustrated because the games I’m referring to are largely exceptions. Take Quake 3 - the engine is released under the GPL, has a community maintained fork, targets OpenGL rather than Svgalib and Valve have the same distribution rights to it as to Wine or Dosbox. It’s possible this is still publisher related, for example if Valve are expecting the publisher to compile/support it and the publisher doesn’t do so. In the end it seems like a lack of economic incentive to package and distribute a thing that already exists.
Most id engine games are in this situation and a couple of those were included in the current beta. They really do use Win32 dosbox on Wine to run a DOS game (so a 500Mb download for a 10Mb game.) 430Mb of that is a Wine/Proton tarball which is then extracted (but left on disk) so Proton on disk is 1.6Gb to run a 10Mb game.
PS. I had great fun with SvgaLib on Linux for games before Steam came along. At one point I was using an a.out version of Doom on a much newer system, and it worked great because a.out had a parallel set of usermode libraries so everything was period except for the kernel, which was the only thing that needed to be compatible.
This has annoyed me before. I got a dos game from gog a while ago and I thought it would be trivial to run on linux but it turns out gog bundles the game and dosbox together in a way you can’t split apart. I tried to get the dosbox version to run in wine but it wasn’t working so I had to find a torrent of the original dos copy
GOG gives you a single installer that includes DosBox and the game itself; once you’ve gotten the files out you can ignore the DosBox-related ones in favour of running the original binary in your own copy of DosBox or open-source re-implementation or whatever.
To get the files out, you can run the installer in Wine, or use a tool like innoextract.
the worst ones are when GOG.com is delivering a butchered Win32 game and you can’t get the original copy out of it