Latest Visual Studio updates now bring official ARM/ARM64 support for Desktop Apps, little hidden, but here is how to enable it.
Being able to compile Windows ARM apps, I wanted to try to actually run them, but … on what exactly? There are some developer evaluation boards. Apparently someone managed to run it on Raspberry PI. Most importantly however you can run Windows 10 ARM64 on QEMU. This is some serious Fun With Virtualization!
I’m not claiming to be the first. Clever people have already done it. I just wanted to make it little easier for the lazier of us. Here is how.
Follow the link above but skip the shady UUP business in step #3 and download ready made iso instead. You can google the iso image from windows.cmd and it will take you to this link. You need the rest of the files like UEFI firmware and virtio drivers.
For the even more impatient here is a ready to run image with Windows pre-installed. Because QEMU now comes with DLL HELL I’m not including it in the archive. You will have to install it separately.
Go have fun and port some apps to ARM64 with free community edition of Visual Studio. I’m going to start with Aclock 🙂
(This is a guest post by Antoni Sawicki aka Tenox)
Since 2012 or so Microsoft is pushing concept of running Windows Server headless without GUI and administering everything through PowerShell. I remember sitting through countless TechEd / Ignite sessions year after year and all I could see were blue PowerShell command prompts everywhere. No more wizards and forms, MMC and GUI based administration is suddenly thing of a past. Just take a look at Server Core, WinPE, Nano, PS Remoting, Windows SSH server, Recovery Console and Emergency Management Services. Even System Center is a front end for PowerShell. Nowadays everything seems to be text mode.
This overall is good news and great improvement since previous generations of Windows, but what if you need to create or edit a PowerShell, CMD script or some config file?
Oooops, looks like you are screwed. Seems that Redmond forgot to include most crucial tool in sysadmin’s job – a simple text mode editor. WTF Microsoft?
So, are there any 3rd party alternatives? Yes, and there are and quite a lot of them! Unfortunately none are perfect and most are old and unmaintained. This article aims to be a grand tour of whatever is available out there.
Note that throughout the article I will be repeatedly referring to a “portable” editor, that for me means single .exe file that can be carried around on a USB pen drive or network share. I also cry a lot about 64-bit Windows builds because I work a lot in WinPE and other environments where syswow64 is not available.
First lets start with most obvious choices well known through intertubes. If you search for a Windows Console Editor VIMand Emacswill naturally pop up first.These editors don’t need any introduction or praising. I use VIM every day and Emacs every now and then. These two had ports to Windows for as long as I can remember and in terms of quality and stability definitely up top. The problem is that both are completely foreign and just plain unusable to a typical Windows user and learning curve is pretty steep. Also portability suffers a lot at least for Emacs. Both editors come with hundreds of supporting files and are massive in size. Emacs.exe binary is whopping 83 MB in size and the zip file contains two of them just in case. Whole unpacked folder is 400 MB.
VIM is fortunately much much better you can extract single vim.exe binary from the package and use it without much complaints.
When talking about about VI and Emacs hard not to mention some more historical versions. Emacs’ little brother MicroEmacs has been available for Windows since earliest days. I’m not going to attempt to link to any particular one since there are so many flavors.
VIM little brother VI also comes in different shapes and forms. Lets take look at a few.
Stevie is a very special case. Rumor has it, this editor played crucial role in development of Windows NT itself or has been used since earliest days of NT as part of the private SDK. If you could ever look at Windows source code I’d bet you could probably find it buried inside. Because it was ported by folks at Redmond the quality should be pretty good. Unfortunately README states “this is an incomplete VI that has not been fully tested. Use at your own risk.”. For a historical note according to Wikipedia, Stevie port to Amiga has been used by Bram Moolenaar as a base source code for VIM.
One particularly interesting case is VI editor from Watcom compiler suite. It has very nice TUI known from MS-DOS editors, syntax highlighting and online help. One of nicest versions of VI available for Windows. Small portable and just all around handy editor. This is probably my main to go text editor when working on WinPE or Server Core. Unfortunately not very well known. I hope it can gain some popularity it deserves.
Thanks to Federico Bianchi just learned that there is a BusbyBox port to Windows having both 32bit and 64bit builds, 100% portable as just a single exe file! Most importantly it contains a working vi editor that understands window resizing and Win32 paths. I’m going to be keeping this one around. Awesome job Busybox! As a last thought I wish they also included Nano.
I don’t want this article to be all about VI and Emacs clones. Let this nice color menus be a segue to more native Windows / DOS editors at least departing from hardcore keystrokes and Unix.
For a change in theme lets look at SemWare TSE Pro, the editor that originally started as QEDIT for DOS and OS/2. It has most advanced features one could ever imagine for a text mode editor. Including resizable windows, hex editor, macros and spell checker. I really wish I could use it in everyday’s life. Unfortunately TSE has some drawbacks, it lacks portable version and install is little cumbersome. Currently no x64 build but the author is working on it. TSE is not free, the license is $45 but it allows to install on as many machines as you need.
Next one up is Brief. It used to be very popular in it’s own time and sparked quite bit of following as there are numerous of editors being “brief style”. It’s a nice and small console based text editor. It comes in two versions basic (free) and professional (paid). The pro version supports splitting in to multiple windows regexp and unicode. Unfortunately it runs at $120 per user and there is no 64bit build or a portable edition.
There also is an open source clone of Brief called GRIEF. Flipping through the manual it has very impressive set of features including $120 windowing feature and macros. Unfortunately it’s rather unportable due to large amount of dll and other files. 64bit build could probably be made if someone wanted.
As we talk about less costly options there is Kinesics Text Editor aka KIT. It’s more well known if you search on google, completely free and after installing you can find and a x64 binary file! This makes it somewhat portable and able to run in WinPE for instance. Until recently the editor did not have 64bit version so I did not have chance to use it much in practice but the TUI appears to have a well rounded easy to use (F1 or right mouse click brings menus). It does’t seem to have any advanced features but it’s very stable and actively maintained. And frankly this is what matters for editing on the console. It may actually be the right missing Windows console editor.
Another one is Minimum Profit. It’s fully open source and it supports a lot of platforms in both windowing and text mode. It has a lot of interesting features such as syntax highlighting, spell checked and menus. It can’t be easily made portable as it needs a lot of files of it’s own scripting language. There is no Win64 build by default but one could probably make it with Mingw64. I also find that screen refresh is somewhat funky.
Lets look at somewhat well known FTE. It’s a very nice text editor available on many platforms such QNX, OS/2 and of course Windows. It has nice TUI, split windows, syntax highlighting, folding, bookmarks and tools for HTML authoring etc. Overall awesome editor falling short only to TSE. Support for NT console has been available since 1997. I have recently fixed couple of bugs and built a 64bit portable version.
One could also not forget Borland Turbo C IDE. Apparently there is an open source clone of the IDE as a regular editor called SETEdit. It’s multi platform editor with MS-DOS style windows and menus. Syntax highlighting macros and all regular amenities. Looks like DOS version can play MP3 songs while you code. There is a native WinNT build made with BCPP. To run on Windows you install the DOS version then overwrite dos exe file win NT exe. The editor is absolutely awesome, unfortunately currently doesn’t work in a portable manner and there is no x64 binary. However as it’s open source it could be probably made.
When talking about MS-DOS style windows, Norton Commander like file managers come to mind. There is one particular built specifically for Windows – FAR Manager. Written by author of WinRAR, originally shareware, but since 2007 it has been released under BSD license. FAR does come with a built in text editor hence it’s featured here. It’s actively supported and developed, and because it’s designed from ground up for Windows, it’s probably most stable and trustworthy of all applications in this post. I normally don’t use it that much, but I do keep a copy of it lying around when I need to do some more heavy lifting from Windows console. There is a 64bit binary by default but unfortunately FAR can be hardly made portable as it comes with 400 files.
When talking about Norton Commander clones lets not forget Midnight Commander, which does have an unofficial native Windows console build called mcwin32. Similar to FAR, MC has a very nice built-in text editor. MC overall seems far nicer than FAR but because it’s multi platform rather than WIndows specific and not officially supported I don’t trust it as much for day to day use.
When on topic of Unix, lets talk about GNU Nano. In it’s native habitat, it’s very popular and stable editor making it a perfect choice for a text mode console. Unfortunately Windows port is lacking quite a lot, especially for things like resizing Window or handling file names. The official build looks like a fusion of cygwin, mingw, pdcurses and other horrible stuff. Version that comes with Mingw/MSYS is not portable and so far I failed in attempts to build a static windows binary by hand. Nano predecessor UW Pico unfortunately never did have console terminal Windows port. Authors of Pine decided to make it semi graphical application with it’s own window, menus and buttons. Sad story for both Pico and Nano. Hopefully one day someone will make a 100% native Windows port.
Another non-vi and non-emacs Unix editor with Windows console port is JED. Frankly I have not used JED that much in the past although I did play with it in the 90s. This is the original web page of Jed editor. It does seem to have menus and multi windows. Unfortunately doesn’t look like it can be easily made in to a portable image.
Yet another more obscure editor is ED-NT which is DEC EDT clone. Unfortunately seems to be completely dead an unmaintained. Sources are still available through archive.org so perhaps it could be still looked after if someone wanted EDT editor on Windows.
When going through obscurities via archive.org one can also mention ZABED and more specifically Z95 which is a 32bit console version. I don’t know anything about the editor and I’m little too lazy to play with it extensively although pdf manual is available. Probably little too old and too obscure for every day use.
Perhaps even more obscure to a mere mortal is The Hessling Editor aka THE. It’s based on VM/CMS editor XEDIT. I did briefly use VM/CMS and XEDIT in early ’90 but I never liked it so much. THE comes in as a native Win32 binary. Not easily portable as it requires some additional files. Also no 64bit binary but source code is available.
Thanks to Andreas Kohl I have learned about X2 Programmers Editor which also has NT console version. The editor seems very nice and has extensive help, syntax highlighting, etc. Unfortunately I have never used this editor before. Last version has been released in 2008 which is not loo long ago but sadly there has been no update since. I hope the author will continue to maintain it.
Andreas also brought up Personal Editor, which comes as PE32 and PE64. Looks like really well maintained and stable editor designed and developed specifically for Windows. 64bit bit version is really cool however the editor doesn’t seem to be portable and $40 license will probably prevent me from using it professionally in environments where I would need it. Never the less looks like a very fine editor!
Another find is e3 editor. Pretty interesting stuff. It’s written in assembler and available on many operating systems including DOS and Windows. Looks like it’s still maintained as last version was released in 2016. It supports multiple modes, Wordstar, Emacs, Vi, Pico and Nedit by renaming or linking the main executable. It’s definitely portable as it doesn’t need any extra files and the exe is just 20KB (take that emacs!). Unfortunately because of assembler I don’t think there will be a 64bit release any time soon. Overall seem to be really cool to keep this one around.
A really cool last minute find is public domain TDE – Thomson-Davis Editor. Released not so long ago in 2007 it has 16, 32bit DOS and 32bit Windows console executable. It has DOS style menus,syntax highlighting, resizable windows and bunch of other features. Looks like a very handy editor. I don’t know how did I miss it. Since source code was available so I was able to make a x64 build. This is really untested so use at your own risk!
Also a recent find – shareware editor called Aurora. I never had a chance to use it in the past but after taking it for a quick spin I fell in love. The text mode UI it feels like it’s own windowing operating system! Originally for DOS, Unix and OS/2, Win32 port is relatively new. Unfortunately it’s no longer maintained or even sold. This is very sad because the editor is extremely cool. I hope the author may be willing to release the source code so it could be maintained.
Thanks to Richard Wells I have learned about OSPlus Text Editor. It’s a really cool little editor with Borland style TUI and multi windows. It doesn’t seem to have any advanced features but it does have a built in calculator and allows background play of WAV and MID. Also allows format conversion of various formats like Word, Write or RTF in to text using Microsoft Office converters. Pretty cool if you need to read Word based documentation on the text console. Sadly looks like the application is no longer maintained. I guess with little bit of luck a 64bit version could be compiled using Mingw64 or MSVC.
Also recently learned about HT. This is more intended as a binary/exe/hex editor and analyzer. However it seems to have an excellent plain text editor with HTML and C syntax highlighting. It doesn’t have very advanced features but one that stands out is a very detailed change log, much like Photoshop History. It shows you what exactly has been changed and in what order. This is pretty cool when doing heavy editing of some important files. The latest version is from 2015 and it’s 100% portable single exe. Unfortunately no x64 but I guess it should be easy enough to build one with Mingw64.
Just in freshly “re-discovered” – Microsoft Editor. This editor is a Win32 port of Mark Zbikowski’s port of Z editor to MS-DOS. It has been widely used with Microsoft C as M, MEP and and OS/2 SDK as SDKED. Shockingly looks like Windows NT did actually have a console mode text editor since it’s earliest days or even earlier. Included in Windows NT pre-release CDs and later on the official Windows NT/2000 SDKs, hiding in plain sight, was a Win32 console mode MEP.EXE. Only if Microsoft included this editor with Windows itself the world would be a different place. I have recently dug it out of SDK and made available here. There also are additional builds (including x64) here. There is a dedicated blog post about it.
As with many commercial editors there is an open source edition of Z named K_Edit. It is a modern re-implementation from scratch written in C++ and LUA. It builds only on 64bit Windows and there probably is no chance for any other version. As of today author of K doesn’t provide ready binaries but I was able to make one myself.
Reader brdlph pointed me to a pretty fresh editor named Textadept. It’s a cross platform, both GUI and TUI editor. Windows console version uses Curses, but it performs remarkably well. It has a look and feel of a modern programmer’s text editor with syntax highlighting, line numbers, etc. The zip archive comes with over 400 files so it’s rather not portable. Also there seem to be no Windows 64bit build although there is one for Linux. The application seem to be very well maintained and the latest release is from January 2018!
Reader Andreas Kohl mentioned SlickEdit, which was a text mode editor for DOS, OS/2 and Windows console (before Visual SlickEdit stole it’s name). According to the company’s employee an OS/2 version of the editor was used by some Windows NT team members to develop their operating system. In early days, SlickEdit CTO traveled to Redmond to port the application to a barely yet functioning NT console system so that the developers could use native dev environment. SlickEdit was most likely the very fist commercial application for Windows NT. It was available in 386, Alpha, MIPS and PowerPC editions. I’m hoping to obtain old evaluation copies. So far I was able to get this screenshot:
Last but not least, a new kid on the block, is Micro. It’s a modern times editor for all platforms including Windows. It looks really cool and seem to have all recent amenities from editors such as Sublime Text or Atom. Multi windows, syntax highlighting and even it’s own built in terminal emulator for running a subshell. Micro is 100% portable and comes in as a single x64 exe file. It’s 10 MB size but I think well worth keeping around. Unfortunately it doesn’t have built-in file browser. Yes, there is a plugin for it but I don’t know how to use it. Also seems to have issues with Windows style path names. However I’m really happy that a new editor has been developed in recent times. It has a great chance of becoming the missing Windows text mode editor for the future! Definitely worth keeping an eye on it.
With this positive news it’s time to wrap up. To summarize there currently is no perfect text mode editor for Windows. I hope that Microsoft can one day step up and provide one. In the mean time I usually stick around to OpenWatcom VI and FAR Manager. For people who do not wish to learn VI, Kinesics KIT may probably be the most perfect editor in short term and Micro in the future. I also hope someone can make a good GNU Nano port using native Win32 APIs without going to pdcurses and cygwin.
Thank you for all suggestions! Have I forgotten or missed any editor? Please let me know and I will promptly add it to the list! Note: please do not include editors that work under Cygwin.
Nothing like a little vintage advertising to try to re-capture the feel. But don’t let the colorful lizard fool you, this certainly was a dark time for Citrix. Firs they had tooled a product around the future of the PC market, OS/2 to only have Microsoft pull out of active development just as they were launching Multiuser 1.0. And to be fair it wasn’t just Citrix, the whole industry including Microsoft was in turmoil as people were pulling away from IBM and selecting Windows on MS-DOS of all things!
Citrix, like a lot of vars were caught in this lurch between OS/2 and the forthcoming NT OS/2 3.0, which of course ended up becoming Windows NT. During this time even Microsoft had to keep selling it’s SQL server on OS/2, along with it’s LanManager file & print server. Although they had a solution for the end user in the form of Windows they didn’t have any server platform. That left Citrix chasing the tail end of the application wave again as although they could now finally use OS/2 2.0, with it’s 32bit/16bit hybrid kernel, there remote user solution was still terminal based.
As IBM & Microsoft had split up the direction of the OS/2 project, IBM was running with version 2 as a platform for running DOS & Windows applications. Which ultimately lead to the major problem that OS/2 ran Windows apps better than native Windows thanks to it’s ability to run isolated Windows VM’s using paravirutalized graphic drivers. It wasn’t until Windows NT 3.5 could Microsoft meet this feat with it’s new platform. Suddenly Citrix had access to tonnes of MS-DOS based applications, much to my surprise there is even a DPMI driver on the disks I have, meaning that Windows 3.0 standard mode can run, along with DooM! But for Citrix this would be another one of those ‘not good enough’ moments where PC Servers were just high end workstations that could easily be maxed by one user, commodity multiprocessor machines were years off, and of course everyone was jumping to Windows 3.0.
But this did at least you run MS-DOS applications remotely, over dialup.
Installing Citrix Multiuser 2.00 starts looking very much like one of the 1.x versions of OS/2 with a far more busier screen featuring the Citrix tree. However from this point onward it feels a LOT more like IBM OS/2 2.00. Citrix interestingly enough has two disk 1’s, one that features newer LADDR drivers, and another with the older 1.x drivers. Although under bochs, the older driver disk crashes out. The entire OS fits on 8 high density 5 1/4″ diskettes. As teased before this post, I saw this on eBay, ordered it immediately to only discover that I don’t have the needed drive, and had to order one from pc-rath_de, and I wanted to give a shout out, as he made sure that I had the proper floppy ribbon cable, so I could go ahead with this fun project.
Although I had been expecting this to be inline with the never released Microsoft OS/2 2.00, it clearly has a lot of IBM vestige, even though the OS/2 source code license agreement was between Citrix and Microsoft.
Indeed, even checking the OS level:
IBM OS/2 Base Operating System
Standard Edition 2.00 Component ID 560109001
Current CSD level: XR00000
Prior CSD level: XR00000
Compare this to the OS/2 2.00 GA:
IBM OS/2 Base Operating System
Version 2.00 Component ID 562107701
Current CSD level: XR02000
Prior CSD level: XR00000
IBM OS/2 Base Operating System
Standard Edition 2.00 Component ID 560109001
Current CSD level: XR00000
Prior CSD level: XR00000
Well isn’t that interesting?
Having had the misfortune of crashing all three we can look at the internal revisions:
So this make the BOS (Base Operating System in IBM speak) newer than the OS/2 LA (Limited Availability) kernel, however quite a few revisions behind the GA (General Availability). This of course means that Citrix Multiuser 2.0 is basically incompatible with any 32bit OS/2 software. I was unable to run anything EMX based, nor could I run the vast majority of the 32bit TCP/IP stack for OS/2 2.00. The best I could do was have it load the drivers, to where I could setup and ping the loopback, but the route command crashes the system, and any of the commands simply refuse to run. Not being able to run 32bit OS/2 applications greatly reduces the usability of the system, and falls further to the OS/2 trap that it really just excels at running MS-DOS apps.
It was a bit of a surprise to find out that even though Citrix had their source license through Microsoft, the 2.0 components turned out to be the upstream components from IBM. Just as the included Qbasic is the IBM version, along with the other components. The terminal support is naturally more robust than version 1, although I think the larger problem I had trying to run OS/2 programs it that many terminals are hard coded for 24 lines, and I don’t think you can change that in Citrix. And it does mention that if you do try to run on a 24 line terminal that DOS won’t run.
Much like 1.0, all the administration is done via text tools. It feels weird at first as even on the console there doesn’t seem to be any mouse integration, although the installer does ask if you do have a mouse on the system.
And like 1.0 there is no Presentation Manager, so no graphics on the console. HOWEVER you can run MS-DOS graphical stuff on the console. Although today I have no real need for it, but I went ahead and setup the included Windows support.
What is interesting is that you are expected to supply your own retail version of Windows 3.00, and Citrix has some updated drivers, along with OS2K286.EXE, and updated program manager, control panel, and print manager. While IBM included a full copy of Windows 3.00 at this point, this feels like the beginning of OS/2 for Windows – AKA the Borg.
First I just setup a COM port on Bochs to Listen on port 8880. Unfortunately this isn’t resilient, as Bochs will wait for a connect before actually starting, and if you drop off, it won’t let you connect back in.
And then it’s a matter of running CFGTERM, and adding in the Async module.
With the module added you then just have to assign a port.
I didnt’ do anything special other than telling Citrix that there is no modem, it’s a direct connect, and to use the ICA terminal profile.
Using the Citrix MultiLink program, and DOSBox I was able to add an ICA terminal. On DOSBox I had to specify a modem with an IRQ in the config like this:
serial2=modem irq3 listenport:5001
In the modem settings I had to set this to Forced connect, otherwise it’ll never see the server.
And here is how I ‘called’ the Bochs VM. And then after ‘dialing’ in Bochs will start up the Citrix VM, and then you’ll get the simple Login prompt. Login and you’ll get pselect.
Pselect the the text based UI tool to get around your OS/2 sessions. It’s a little cumbersome at first, but once you get used to it, it’s just like OS/2 1.0 … Or Multiuser 1.0 for that matter, nothing really changed, except you can start MS-DOS Sessions now.
And yes, you can run Qbasic. But you can’t do anything graphical. Not even DooM. Although after loading the VDPMI device driver, DooM v1.1 will run, but then it’ll give you this fun error:
And that is where I’m going to have to leave this adventure for now.
I have to admit it, that when I first heard about this I was HIGHLY skeptical, but sure enough it actually works.
Although I have gotten SQL Server 4.21a & 6.5 running on Windows 10 (The core from 6.0 works, but it’s pre-release COM objects for the Enterprise manager don’t like Windows 10) There were two stumbling blocks I never could get around. The first one turned out to be something trivial, which is SQL 4.21 would never listen on TCPIP.
Fixing SQL 4.21
It turns out that this actually was a simple fix.
17/09/21 19:40:24.00 server server name is ‘JADERABBIT’
17/09/21 19:40:24.00 server Recovering database ‘model’
17/09/21 19:40:24.00 server Recovery dbid 3 ckpt (45,26)
17/09/21 19:40:24.00 server Clearing temp db
17/09/21 19:40:24.03 kernel Using ‘SQLEVENT.DLL’ version ‘4.21.00’.
17/09/21 19:40:24.83 kernel Using ‘OPENDSNT.DLL’ version ‘4.21.09.02’.
17/09/21 19:40:24.83 kernel Using ‘NTWDBLIB.DLL’ version ‘4.21.00’.
17/09/21 19:40:24.83 ods Using ‘SSNMPNTW.DLL’ version ‘22.214.171.124’ to listen on ‘\\.\pipe\sql\query’.
17/09/21 19:40:24.83 ods Using ‘SSMSSOCN.DLL’ version ‘126.96.36.199’ to listen on ‘1433’.
17/09/21 19:40:26.04 server Recovering database ‘pubs’
17/09/21 19:40:26.06 server Recovery dbid 4 ckpt (469,25)
17/09/21 19:40:26.06 server Recovering database ‘ultimate’
17/09/21 19:40:26.06 server Recovery dbid 5 ckpt (524295,12)
17/09/21 19:40:26.06 server Recovery complete.
17/09/21 19:40:26.12 server SQL Server’s default sort order is:
17/09/21 19:40:26.12 server ‘bin_cp850’ (ID = 40)
17/09/21 19:40:26.12 server on top of default character set:
17/09/21 19:40:26.12 server ‘cp850’ (ID = 2)
The DLL for TCP/IP is SSMSSOCN.DLL, and it turns out it really wants to be located in the C:\Windows\SysWOW64 directory (aka the system path for libraries). Well that’s all great now, isn’t it?
The ODBC drivers in Windows 10 finally made a magical cut off point that they will not talk to any old and ‘vulnerable’ SQL Servers. This means that the oldest version you can connect to is SQL Server 2000. Even SQL 7 didn’t make the cut. Trying to connect to a SQL 7 server, you just get:
[Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context
And then I saw this post, about using FreeTDS to connect to MSSQL. So I followed their instructions, and got nowhere fast just lots of crashing. Turns out the bloodshed environment’s included G++ just fails 100% of the time for me, with a nice crash. So I pointed it to the TDM GCC install, and then had to link the DLL manually and… nothing. No configuration point. In a fit of rage, I took the exist msvc project, opened it in Visual Studio 2015, and built it, except for one issue…
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __vsnwprintf_s referenced in function _StringCchPrintfW
So I was thinking that SQL 4.21 & 6.5 are just too old to have this weird table, and as mentioned over here people would just create it, to get Access to shut up, and get on with their lives.
So, I put in some SQL
CREATE TABLE MSysConf(CREATE TABLE MSysConf(Config int NOT NULL,chValue char(255) NULL,nValue int NULL,Comments char(255) NULL)
INSERT INTO MSysConf(Config,nValue,Comments)VALUES(101,1,’Prevent storage of the logon ID and password in linked tables.’)
And yes, it creates the table, Access get’s it’s result then obviously doesn’t like it and up and dies. Maybe I can burn more cycles on it later, or break down and ask.
Copy ..SP4\x86\other\sqlredis.exe to ..\originalinstallpath\x86\other
(this avoid mdac insall freezing)
Create this folder structure (any place):
Microsoft SQL Server\80\Tools\Binn
Microsoft SQL Server\MSSQL\Binn
Find out sqlunirl.dll on SP4 path and copy to Binn folder above
Copy dll files on ..SP4\x86\setup to Microsoft SQL Server\MSSQL\Binn (folder above)
Copy folder structure (created on step 3) to C:\Program Files (x86)
Give full access to user logged to **Microsoft SQL Server** folder
Change install compatiblity ..\originalinstallpath\x86\setup\setupsql.exe
Run as administrator
Could that really be it? For some reason I had a file held in the Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\PendingFileRenameOperations registry key, preventing me from installing, but zapping the key & stub program, and I was able to follow the steps (I’m still not sure if you copy the dlls into the MSSQL\Binn or Tools\BInn directories, so I copied them to both!) and yes, it worked. I even could run the SP4 update.
And now I can use Access 2016 with this fine ancient database.
And here we are. As always there is no larger over reaching point to this. I did have to create a linked SQL login for myself to get ODBC to login properly but it’s somewhat simple, and honestly if that sounds bizarre to you, why are you even thinking about something like this?
For me, I’m interested in the DTS of all things. Sure the new ones are fancier, and all that jazz, but I paid good money back in the day for old MS dev tools, and being able to use them without any virtualization, aka running on bare iron is all the more appealing.
So it’s always a fun time for me to push my old project Ancient Linux on Windows. And what makes this so special? Well it’s a cross compiler for the ancient Linux kernels, along with source to the kernels so you can easily edit, compile and run early Linux from Windows!
As always the kernels I have built and done super basic testing on are:
All of these are a.out kernels, like things were back in the old days. You can edit stuff in notepad if you so wish, or any other editor. A MSYS environment is included, so you can just type in ‘make’ and a kernel can be built, and it also can be tested in the included Qemu. I’ve updated a few things, first with better environment variables, and only tested on Windows 10. Although building a standalone linux EXE still requires a bit of work, it isn’t my goal here as this whole thing is instead geared around building kernels from source. I included bison in this build, so more of GCC is generated on the host. Not that I think it matters too much, although it ended up being an issue doing DooM on GCC 1.39.
So for people who want to relive the good old bad days of Linux, and want to do so from the comfort of Windows, this is your chance!
As you can see it clearly can see the USB device, but when it opens the device it fails. And yes I’ve tried Administrator. And for the hell of it, I fire up Windows XP on VMWare, connect the USB dongal, and amazingly:
MIDI:win32 selected USB Audio Device
MIDI:win32 selected USB Audio Device 
MIDI:win32 selected Microsoft GS Wavetable SW Synth
Yes, I can open the out port just fine. So now I run a virtualizer to run my emulator to drive a physical peripheral… Ugh. Has MIDI been this messed up all along and I never noticed?
Oh yeah, the GS Wavetable Synth works fine, as did MUNT before I uninstalled it, thinking it was somehow interfering with anything.
I know I’m using this fine device, the QinHeng USB MIDI adapter, which apparently is notorious crap, but my recently acquired Yamaha MU 80, works fine with it on Windows XP.
I can’t find any source of the 0.5 versions, and I had issues with 0.6.x but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?). I suppose with this version working I can go back and take a stab at resurrecting 0.6.x
What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.
I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta. So now you can actually use the CLI, and change disks. Double clicking is an impossibility as it simply runs far too fast. I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.
I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast. UAE is from an era where a 100Mhz computer was a luxury item. Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.
I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right! I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!
Where can I turn away from all this so called progress! I don’t like my C compilers to be C++ programs that require massive HOURS to compile. Can’t we just go back to the good old days?
And the answer is YES, you can!
While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms! Well isn’t that fantastic!
So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?
Well ancient versions of EMX are very difficult to track down. Somehow I did mange to find this hybrid of 0.8B & 0.8C. The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B. And the best thing is that the 0.8B is based around GCC 1.40! So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW! Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows! So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.
Now with my executable, I can run it on MS-DOS & OS/2!
and OS/2 2.0!
Well isn’t that fantastic!
However when running RSXNT’s bind, NTBIND I got this error:
No relocations in file:
you have not linked the NT library
Great. Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries. So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:
io.o: Undefined symbol __streams referenced from text segment
And looking at the stdio.h there is this:
extern struct _stdio _streams;
No doubt, the headers & libraries are tied together. So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).
Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory. I suppose it’s a fair trade off. Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days. GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!
For comparison, GCC 5.10 produces a 55,906 byte interpreter, while GCC 1.40 produces a 88,576 byte interpreter.
For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles. It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!
I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.
How about some speed comparisons? I dug out the ancient dhrystone.c, and gave it a shot. I had to define 500,000,000 passes, as my computer is fast. GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.
Dhrystone(1.1) time for 500000000 passes = 57
This machine benchmarks at 8771929 dhrystones/second
Dhrystone(1.1) time for 500000000 passes = 40
This machine benchmarks at 12500000 dhrystones/second
Dhrystone(1.1) time for 500000000 passes = 43
This machine benchmarks at 11627906 dhrystones/second
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second
Dhrystone(1.1) time for 500000000 passes = 14
This machine benchmarks at 35714285 dhrystones/second
Dhrystone(1.1) time for 500000000 passes = 11
This machine benchmarks at 45454545 dhrystones/second
As you can see, GCC 1.40 produces the slowest code. While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away. And again GCC 5.1 beat out the older 1.40 for executable sizes.
And this time by over a 2x lead! It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.
For anyone who’s read this far, I guess you want to take it out for a test drive? Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk. I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.