So I bit the bullet and updated to Windows 10 build 1903. And then the fun started on my glorious 2006 MacPro. It finished the update, and on reboot I get the login screen, and then almost immediately a blue screen.
Naturally the QR code is useless as it doesn’t specify any stop codes, and the minidump… Well that requires gigabytes and gigabytes of crap to download to get a tool to read it. (I still haven’t finished that rabbit hole, like COME ON! why isn’t it included?!).
However after hitting F8 a million times, I found that safe mode & networking work just great. Searching online was basically useless as there was no specific stop code to go with this WDF_VIOLATION. Further looking around I did notice one thing, and that it was all Macintosh machines that crash out to this WDF_VIOLATION error. It must be something specific to the Apple hardware running Windows 10!?
Armed with this (dis)information, I went ahead and disabled all the Apple specific drivers & startup items.
From MSCONFIG.EXE I disabled the following services:
Apple OS Switch Manager
Apple Time Service
And in the task manager, I disabled the following startup items:
Realtek HD Audio Manager
Boot Camp Manager
I had the other VMWare serial & USB hook previously disabled, as I just don’t want them at all on my setup. The big upshot is that after rebooting out of safe mode, I’m now up and running on Windows build 1903.
Considering the BootCamp stuff was so woefully out of date, don’t expect Apple to fix this anytime soon. And since I’m on a MacPro 2006, I certainly won’t be getting any updates from Apple. But at least I can struggle to keep this thing up to date otherwise.
Now I can enjoy that ‘new command prompt’ everyone keeps telling me about.
I went through this on another Bootcamp Mac, and what I had to do was uninstall the “Boot Camp Services”. It’s startup component triggers the bluescreen as it’s doing some nonsensical inventory, banging around on the drivers in a not friendly way. I had version 4.0.4033 of the Boot Camp Services installed.
Removing this kept all the old drivers, which continue to work just fine.
I’ve been trading emails with various people from the project after I had made my post, and helping them integrate more of Visual Studio 2003 into the project and working through a few issues to bring far better compatibility to VS 2003.
And the best part is being able to build projects in parallel!
I haven’t ordered new processors, so the 2.1Ghz parts are… lacking. However being able to use all available cores makes building DOSBox pretty fast.
Restricting the build to a single process takes 1:13 while the full parallel build on this machine takes a mere 10 seconds!
I uh, also saw this on archive.org, which may help people looking for this stuff from the future as old tools get harder and harder to find. Especially bigger editions like the Enterprise Architect version.
That’s right ARM Linux userland! I still have high hopes for Windows on ARM (I have 2 Windows RT devices now!!) although I’m not holding my breath.
Maybe there will be some ARM boards that are suitable for the desktop that aren’t over 1k USD.. That’d be nice.
Interesting trivia is that the Linux Subsystem started it’s life on ARM as a way to run Android binaries on Windows Phone. And true to everything Microsoft does, it got to the point where it could start to run things (albeit poorly) and was summarily killed. Although it’s found life despite the original false start as a general ‘text mode’ subsystem for Windows.
However running Linux binaries on Windows currently just shows that NTOS isn’t as efficient as the Linux kernel when it comes to emulating the Linux ABI. Although this was the original ‘dream’ of the microkernel, and a POSIX subsystem for NT was always part of the original design, although it really was more of a checkbox for GSA contracts, and outside of being able to use pax & vi it really was handicapped by not having BSD extensions, and especially by not having any access to the TCP/IP stack.
I saw this the other day, VC6 Ultimate. It’s an interesting ‘update’ on the old Visual C++ 6.0 product with an improved UI, along with updated compiler toolchain taken from later versions of Visual C++. Naturally something like this is 1000000% unofficial.
Portable and compatible with Win7 / Win10
bye bye regedit, hello .hjson setting file !
also meaning it should not mess with your current install
More compatible compiler
multicore version of VC7.1 compiler (It’s fast)
you can compile with other compilers (64bit), but not debug yet
Real-time highlighting and diagnostics
based on libclang 6.0 and compatible with VisualAssistX
Real multicursor editing
search, sort, number, evaluate, etc. while in multicursor mode
Improved UX and UI
32bit icons, dark skin, lot of visual hints
revamped dialogs (project settings, threads, breakpoints, …)
searchable command palette
It’s free (as in free beer)
ever had to pay for a birthday present ? 😉
Every change has a toggle
only take what you like, but we can not check each combination
It’s an internal spare time project
don’t expect everything to work in every setup, but feel free to reach out
Included in the bundle is the following compilers:
clang version 3.8.0 (branches/release_38)
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80×86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
It’s an interesting project, although I tried to re-build some Visual C++ 2003 projects and it bombed out. Maybe it’s just more geared towards VC 6 as indicated.
So I have this 2006 Mac Pro 1,1 that I’ve had laying around and I wanted to put my old Nvidia 1030 into it, along with Windows 10 for a newer (stronger?) home machine.
So I burnt the downloadable ISO from Microsoft onto a DVD, tried to boot it up and got this:
I got stuck at this “Select CD-ROM Boot Type : ” prompt, which you can’t type anything into. Apparently it’s a common and known issue with 64bit boot code, as the older Intel Apple Mac’s are of course 32bit only. So there is a fix, you have to use something called “oscdimg” to rebuild the ISO with a 32bit friendly loader.
So first I just used 7zip to extract the downloaded ISO, and then create the new 32bit ISO with the following:
(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.
Well it turns out that this ‘system32’ directory is actually the 64bit system directory! And attempting to do this will just result in the error:
The module was loaded but the call to DllRegisterServer failed with the code 0x80040005. Well great. This typically goes back to a permissions issue, or the wrong regsvr32.exe being called.
However on a Win64 based OS, you actually need to specify the Win32 version of regsvr32 which actually lives in the SysWOW64 directory, and run the command prompt at administrator! So you would run it like this:
With this COM object registered, you can now launch the Enterprise manager!
Also I found a semi fun way to rename the SQL server:
sp_configure ‘allow updates’, 1
reconfigure with override
Running this and it renamed the local SQL instance, and shut it down. Restarting and it connected to itself just fine. Naturally change YOURSERVERNAME to whatever your hostname is. SQL server always wants to be called whatever the actual hostname is, otherwise things break in strange and confusing ways.
Is this terribly useful? Probably not. But I think it’s kind of interesting to run 90’s era server software in the 21st century. Sure I wouldn’t want to run any of it in any type of production environment, but it shows at it’s core how Win32 has not drifted. However looking at the Microsoft Management console of SQL Server 7.0, and how it will not either run on Windows 10, nor will the snapin run show just how fragile the house of COM turned out to be, and meanwhile good old fashioned Sybase/Win32 code still runs from 1993 onward.
I suppose the next thing to do is to try it on Wine, or a fun enough debugger/syscall trace to see what on earth SQL 7.0’s problem is. I don’t have any doubt that it’s nothing that can’t be fixed, although back to the root point, would you really want SQL 7.0 in 2016… or even SQL 2000 for that matter.
Unlike Windows Vista, the setupdll.dll from Windows NT 4.0 will not work. I used the one from Windows NT 3.1, and it will run the setup program fine, but the file copy bombs out. I went crazy and modified the setup.inf to not actually copy files, take an xcopy of the raw files from an old install, and it won’t even try to install the service, it just builds a master database, and exits.
Trying to run the SQL Server directly, and you get this fun error:
16/10/13 21:19:08.40 kernel Unable to start due to invalid serial number.
Well isn’t that great. So naturally you either have to install it, or just import an existing registry key setup like this SQL.REG file.
If you are so inclined, you can even remove named pipe support, and have it listen only on TCP/IP. Or the other way around. Or even change the TCP port.
In the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQLServer\Server key there should be a Multi-String key called ListenOn … and it’s just the network transport DLL, and how they listen. As you can see SSNMPNTW is the named pipe transport, and SSMSSOCN is the TCP/IP transport.
SQL Server really wants to load the TCP/IP trasnport DLL from the Windows\System32 directory. On 64bit versions of Windows, however that means copying the SSMSSOCN.DLL file to the SysWOW64 directory, in order to have TCP/IP networking.
SQL server is not terribly useful in it’s current state as it turns out that master database is actually empty. So without stored procedures or much of anything you really can’t do anything with it. However looking at the install directory there is a bunch of SQL scripts. Even better on the VM where I’ve installed it, there is some output files, that by their date & time tell me in what order to run them!
First things first, I copy the following files from the C:\SQL\DLL diredctory to the C:\SQL\BINN directory so I don’t have to mess with paths:
Now I can run the SQL server from the C:\SQL\BINN directory
And now it’s running. If there is any issues, or your master database is either damaged, or just plain doesn’t exist, you can create one with the BLDMASTR.EXE program.
C:\sql\BINN>BLDMASTR.EXE Buildmaster 4.20a NT : Wed Jan 26 12:37:00 1994
Master disk name? (default is master.dat) :
Master disk size (in 2k blocks)? (default is 6144) :
Configuration only? (default is N) (y or n) : n
Databases only? (default is N) (y or n) : n Master device: master.dat writing configuration area writing the MASTER database writing the MODEL database writing allocation pages for remaining 7 MB, (3584 pages) 7 MB Buildmaster complete
It’s that simple! Move the master.dat file into the C:\SQL\DATA directory and if the server doesn’t find it by itself, you can just tell it where it’s located:
START SQLSERVR.EXE -d ..\DATA\master.dat
And it should start.
Now the file CONFIG.SQL needs to be modifed (if you have a prior config) or created.
The two key lines are:
update master.dbo.sysdevices set phyname=’C:\SQL\DATA\MASTER.DAT’ where name = ‘master’ sp_addserver YOURMACHINE,local
Which as you can imagine simply sets where the master database lives, and what the machine name is, as SQL server LOVES to know the correct machine name. With that done, here is my simple script for populating the master database:
And once this has finished it will have populated all the tables in your master database. Hit CTRL+C in the SQL Server window, and it’ll shut down. Re-launch it, and it’ll be initialized.
Assuming this all went according to plan, you can now launch SQLADMIN, the SQL Administrator, and then you can get a connect screen like this (I only got it running with the named pipes transport…)
Remember by default the sa user has no password!
And we are good to go! Feel free to grab SP4, and apply it by unzipping, and copying the files & dll’s to their respective places. So there we go, from January of 1994, to October of 2016, SQL Server still running!
I went ahead and installed the JDK in a normal directory, The same went for the Android SDK. The NDK is a 7zip file, that I went ahead and put at the root of my C drive because I’m that kind of guy. Next I unpacked ant into the NDK directory, and SDL. For SDL be sure to use some command line or other unzip tool that makes sure that the text files are translated appropriately, otherwise they are impossible to read in good editing tools, like notepad.
unzip -aa \Downloads\SDL2-2.0.3.zip
Now to stage the project directory. The ‘Android project’ that we are going to build out of is *INSIDE* the SDL archive. And SDL needs to be inside the project directory, so we xcopy out the bits we need.
Now we need to set some environment variables. Again this is where my stuff is, yours may be different.
set ANDROID_HOME=”C:\Program Files (x86)\Android\android-sdk\”
set PATH=%NDK_ROOT%\apache-ant-1.9.4\bin;”C:\Program Files\Java\jdk1.7.0_79\bin”;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools;%PATH%
Now we need to edit the jni\src\Android.mk and point it to your sources. In this case I’m using dinomage.com‘s simple main.c & image.bmp as I haven’t written anything exciting yet. Change YourSourceHere.c, to main.c
Now copy in the image.bmp file into the assets directory:
copy image.bmp assets
Now we can fire up the native compiler tools, and by default it’ll compile for ARM thumb, ARM v7a, and x86
Now for the java. Android is a java platform, so now we have to compile the wrapper that calls our C/C++ code. First we have to set what version of Android we are compiling for:
android update project –path . –subprojects -t 12
And now we compile with ‘ant’ by typing in:
And if all goes well you’ll get:
Total time: 2 seconds
Now to run the program, we can fire up one of the emulators (you will have to configure one no doubt) using AVD. I just clicked around, and picked something that’d launch. The shell seems to crash a lot, but otherwise yeah.
Now to upload our application to the emulator once it is running:
ant debug install
And if all goes well, you’ll see:
[echo] Installing C:\android-ndk-r10d\proj\bin\SDLActivity-debug.apk onto d
efault emulator or device…
[exec] pkg: /data/local/tmp/SDLActivity-debug.apk
[exec] rm failed for -f, Read-only file system
[exec] 1985 KB/s (1028625 bytes in 0.506s)
Total time: 5 seconds
And on my first shot at running, it crashed.
Using ‘adb logcat’ on the emulator I was able to find this line:
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol “signal” referenced by “libSDL2.so”…
Well it turns out signal was an inline function until platform android-21, now it’s not inline anymore. When you use the ndk r10, android-21 is used by default but it’s not fully retro-compatible with devices running former Android versions. In this case, signal can’t be found on the emulator. (It did run properly on my Lollipop phone).
Fixing this is simple just edit jni\Application.mk and add in the APP_PLATFORM line:
# Uncomment this if you’re using STL in your project
# See CPLUSPLUS-SUPPORT.html in the NDK documentation for more information
# APP_STL := stlport_static
APP_PLATFORM := android-12
APP_ABI := armeabi armeabi-v7a x86
Re-compile with ndk-build, and re-upload with ant then you are good to go.
I grabbed, and borrowed some phones around the office, including an x86 phone and yeah it works!
I haven’t even tried to cross build libraries on Windows… I suspect I should be doing this on OS X or Linux.