DOSBox is a DOS-emulator that was originally developed to run old DOS games that had problems with the standard DOS emulations of Windows. It does have some additional uses though.

We have got an old DOS program that still hasn’t been fully ported from Borland Pascal to Delphi. Since Windows 7 64 Bit does no longer run DOS programs, we now run this program in DOSBox. One of the main functions of this programs is printing some curves on a dot matrix printer on fan-fold paper (Just learned a new word, thanks dict.leo.org.) Getting printing to work takes some configuration.

First, you need DOSBox Megabuild 6 since apparently printing is not fully implemented in the official version.

Then you must decide how you want to print:

• Print to a printer attached to your computer (this includes a pdf printer provided by e.g. PDFCreator)
• Print to png (or even bmp) files
• Print to a file that contains the data sent to the printer
• Print directly to a dot matrix printer

Whatever you want to do, you need to modify the .conf file (or start DOSBox with the -conf parameter pointing to a modified .conf file).

The .conf file is in INI format, so editing it can be done with any text editor. The installer also creates a menu item in the DOSBox start menu folder, subfolder config called “Edit Configuration” which you can use to edit the configuration with notepad.

## Printing to a local printer

If you want to print to a local printer, do the following:

[parallel]
parallel1=printer

[printer]
printoutput=printer
multipage=false


You might want to adjust the other configuration options in the [printer] section, in particular multipage must be set to true, if you want to print to a PDF file and don’t want to create a new PDF for each page.

If you print from a DOS program within DOSBox, you will get the Windows printer select dialog. This won’t happen immediately but after a while (when enough data has been printed) or only after exiting the program or even DOSBox. There is a shortcut for “Eject Page” which is mapped to F2 by default. It might also help to get this dialog (I haven’t tried that because it probably has some side effects.)

## Printing to a png/bmp file

If instead you want to print to a png or bmp file, one per page, you change the entries under [printer] like this:

[printer]
printoutput=png
docpath=c:\some\directory


Don’t forget to set the docpath to some suitable location otherwise you will hunt for the files all the time.

Other possible values for printoutput are bmp for generating bitmap files and ps for generating PostScript output. I haven’t tested them.

## Printing to a file that contains the data sent to the printer

To write the data that is sent to a printer to a file, configure DOSBox like this:

[parallel]
parallel1=file


This will create files in the capture folder, the filename will be the name of the program that printed them, followed by _<3digitnumber>.prt. If you want to append everything to one file, specify the filename like this:

[parallel]
parallel1=file append:c:\outputfile.prt


The files created with this method can be copied to the printer without changes to print them. But note that this is raw output containing control codes for the printer that is printer dependent. So if your program knows how to print to an Epson ESC/P dot matrix printer, you can copy the file to such a printer and it will work. If you copy it to a different printer you will most likely get garbage.

## Printing directly to a dot matrix printer

To directly print to a dot matrix printer, you configure DOSBox like this:

[parallel]
parallel1=file dev:lpt1


If the printer is directly connected to the host’s first parallel port, this should already work (I haven’t tried it though). If not, you need to mount it using

net use lpt1 \\server\SharedPrinter


This will directly print to a network printer. Again, be warned that this only works if your DOS program knows how to print to this particular printer type.

Alternatively you can specify the printer share directly in the [parallel1] section like this:

[parallel]
parallel1=file append:\\sever\SharedPrinter


In the process of moving forward to Windows 7 we found, that there were still some computers running Windows 2000. The original plan was to get rid of them in the process because they are (and have been for some time) an uncalculable security risk and of course the hardware is quite old as well (and don’t even ask for the backups). Unfortunately it turned out that there are some programs running on these computers that we still haven’t replaced or at least are not 100% sure the replacement works reliably.

So we decided to keep these computers as virtual machines without network connection (actually: With host only networking). And since one of the programs was a client server application, this added some additional headache: How do you use a 3 user c/s application if the computer running the server does not have a network? It turned out, that this particular application was rarely used and it would be fine if every one of these 3 users could work with it one at a time and on the console of the virtual machine.

Being a lazy bastard ™ I of course didn’t want to walk to the console every time and I don’t think the other users were particularly fond of that idea either, I investigated a little bit further and found a nifty little feature of VirtualBox called "Remote Display". It allows you to access the virtual machine using a Remote Desktop Client, so it adds remote access to any legacy operating system that runs in the VM.

Getting it to work turned out to be less straight forward than I thought. First, you need the “Oracle VM Virtual Box Extension Pack” in a version that matches that of VirtualBox. It is installed via the the VirtualBox settings (File / Preferences) under “Extensions”. Note, that installing from a network drive apparently does not work.

After this is done you configure the Remote Display for the virtual machines that require it. This is done in the virtual machine’s settings under “Display”. Switch to the “Remote Display” tab set the check to “Enable Server” and – very important – set the Server Port to something else but 3389. If you leave it with the default, it will conflict with the remote desktop capability of Windows and you will get the rather unhelpful error “Your computer could not connect to another console session on the remote computer because you already have a console session in progress.” when you try to connect locally. I used port 3400.

To be able to connect to the virtual machine that machine must already be running but it is not necessary that the OS has finished booting. Just open the Remote Desktop Client and point it to the name or IP address of the host computer followed by a colon (":") and the port number. E.g. localhost:3400, 127.0.0.1:3400 or bobscomputer:3400. After complaining multiple times about security the window should show you the same as the console window of VirtualBox.

If you want to run VirtualBox without a GUI and access it only via Remote Desktop, see this StackOverflow question.

One of the recurring confusions with databases is how to specify a date value in SQL statements. In the case of dbase, it’s not just SQL but also the builtin language.

There you specify a date as

ctod("<date>")

where <date> is the date in the format currently used for output.

e.g. if you are using the standard German date format:

replace all DATEFIELD to ctod("31.01.2014")

Yesterday, all of a sudden my smartphone (a Samsung Galaxy Note N7000) started to misbehave. The first thing I noticed was that the battery was down to <15% rather early in the day. I didn't think much about it, just plugged it into the charger and forgot about it.

This morning I wanted to put it back into my pocket and noticed that it was now complaining about "Insufficient Storage Available" with the hint to uninstall some apps or widgets. Since I haven't installed anything for a while, apart from the regular updates, I thought that rather strange. Especially since there was lots of space free on the micro sd card. Of course internal storage is always at a premium so that was probably what the shortage was about. It turned out that from the 2 gb internal storage apps used 540 mb and cached data used 35 mb, so where did the other >1.3 gb go?

This answer to a stackverflow question, which interestingly enough is also about a Galaxy Note, offered the solution. Apparently some stupid app writes log files to internal storage and never deletes it. In /data/log I found more than 1500 log files, each around a megabyte in size. I guess that explains where the storage space went. Deleting these files was easy enough since I run a rooted CyanogenMod, so I could just use the installed file manager to do it. That took care of the warning.

Unfortunately that wasn’t all of it. Another error message kept popping up: “Unfortunately android keyboard (AOSP) has stopped”. I had ignored it until then because I thought it might be caused by the storage problem as well. It probably was but it wasn’t solved by freeing more storage. Even after a reboot of the phone it kept crashing so I had to investigate further. Google turned up this blog post FIXED! – Unfortunately Android Keyboard Has Stopped Solution which caught my interest because of the upper cased “FIXED” in the title. And – wonders of wonders – it actually explained the fix: Clearing cache and data of the “Android keyboard (AOSP)” and “Dictionary Provider” apps solved the issue for me.

So I could finally start assembling the bloody kitchen cabinet which turned out to be much easier than I thought.

Here, I will be posting notes on converting Subversion repositories to Mercurial.

NOTE: This is work in progress. I will probably come back and change things as well as adding.

Hg Init: a Mercurial tutorial by Joel Spolsky
QuickStart in the Mercurial Wiki

I have got TortoiseSVN 1.8.3 including the command line clients and TortoiseHG 2.10.1 installed.

There are several short tutorials on converting from svn to hg. They all suggest that you first create a local copy of your subversion repository to work on.

A – Create a local copy of your subversion repository
Creating this local copy can easily be done as described by Massimo Iacolare, which I used as a guide.

1 – Create a local svn repository
You can use any local directory as the path to your local svn repository, I will be using the extension .svn to remind me that it is a svn repository. The converted Mercurial repository will not get an extension.

Unfortunately there is the first gotcha: Massimo seemed to be using an older version of svn that used db format 4. The current svn 1.8 uses db format 6 by default, and as Jeroen W. Pluimers found out, the current Mercurial does not support it yet. So, what can we do until the Mercurial developers fix this problem? Why, use db format 4, of course:

svnadmin create --compatible-version 1.7 [path\to\your\new\repository.svn]

I am not sure whether the steps 2 to 4 are necessary, it seemed to work fine without them. I’ll keep them here just in case I run into trouble later because I left them out.

2 – Enable writing on your new repository
Open the file [path\to\your\new\repository.svn]\conf\svnserve.conf and uncomment the line

[general]
password-db = passwd

This tells SVN which file stores the user credentials.

3 – Add a new user
Open the file [path\to\your\new\repository.svn]\conf\passwd and add a new user:

[users]
svnsync_user = svnsync

Open the file [path\to\your\new\repository.svn]\conf\authz and add:

[/]
svnsync_user = rw

5 – Enable rev propchange (revision property change)
create a text file pre-revprop-change.bat in [path\to\your\new\repository.svn]\hooks containing:

exit 0

This can be done easily with

echo exit 0 > [path\to\your\new\repository.svn]\hooks\pre-revprop-change.bat

6 – Initialize the repository

svnsync init file:///[path/to/your/new/repository.svn] [REMOTE PATH]

Getting the local repository path right can be tricky. Pay close attention to the number of slashes and use forward slashes. e.g.

svnsync init file:///c:/some/path/here.svn https://svn.somesvnserver.com/svn/repository

7 – Synchronize
Once the repository is initialized, you can synchronize it as often as you like:

svnsync sync file:///[path/to/your/new/repository.svn]

Be aware, if your repository is big, the first synchronization may take very long.
After the synchronization has been done once, you can keep it in sync by just repeating step 7.

B – convert your local Subversion repository to a Mercurial repository

This is a one step action:

hg convert [path/to/your/new/repository.svn] [path/to/your/hg/repository]

If you omit the second parameter, hg convert will assume [path/to/your/new/repository.svn-hg] which is probably not what you want, but you can easily rename the directory later on.

The above converts the whole svn repository, including any branches to a single Mercurial repository, as this command shows:

hg branches -a

(You must execute it inside the repository.)
This will also list the pseudo branch “default” which corresponds to the “trunk” in svn.

You can also specify any path within the svn repository to convert, e.g. only the trunk:

hg convert file:///[path/to/your/new/repository.svn]/trunk [path/to/your/hg/repository]

Alternatively, you can convert the whole repository and clone it for every branch to a new Mercurial repository, like this:

hg clone -r [branchname] [path/to/your/hg/repository] [path/to/your/hg/branch]

Due to different concepts of users in svn and Mercurial (one uses names, the other uses email adresses), you can provide a mapping file for users to emails. It must contain one line per user like this:

arist = Aristotle <aristotle@phil.example.gr>
soc = Socrates <socrates@phil.example.gr>

(This example is taken from Mercurial: The Definitive Guideby Bryan O’Sullivan)
And you pass it to the conversion with the –authors option.

At work and also on my private computer I am maintaining multiple Delphi projects that are (currently) managed in subversion repositories. They have a general structure like this:

projectname
\- buildtools (-> svn:external)
\- src (project sources)
\- libs
\- dzlib (-> svn:external)
\- some other libraries, all svn:external


Being a lazy bastard (deutsch: faule Socke) I don’t want to start Delphi just to compile the projects or check whether they still compile but have a build script to do that. Also, I don’t want to right click and svn update all the time (and build after that) so I have got an autobuildcheck script. And last but not least, since on my computer all Delphi versions since version 6 are installed, I need a method to automatically launch the correct IDE for each of the projects.

First, auto_build_check.cmd:

That one is simple. It needs to

• svn update
• call the build script
• revert the build number increment which the build script automatically made
• if no error occurred, just exit, otherwise pause to let me examine the error message
rem Update sources from repository
rem Build them
rem in case of error(s): Stop and show the error
rem revert the automatic build number incrementation

svn update
if errorlevel 1 goto Error

set BatchBuild=1
call _BuildProject.cmd

if not exist src\*_version.ini goto :eof
svn revert src\*_version.ini
if errorlevel 1 goto error

goto :eof

:error
echo ***** ERROR *****
pause


Next, _buildproject.cmd:

It needs to

• determine the project name from the current directory (I don’t want to write different build script for each project, lazy bastard again)
• determine the Delphi version to use for building (this one only supports Delphi 2007 and later)
• call msbuild
• if an error occurs, show that error
• pause, to let me examine the results
rem @echo off
REM - assumes that the parent directory is also the project name, extracts it
REM - and calls msbuild with %project%.dproj

setlocal

rem Has the project been passed as parameter?
set project=%1
if not "%project%"=="" goto projgiven
rem Is there a __SetProjectName.cmd which supposedly sets %project%?
if exist __SetProjectName.cmd call __SetProjectName.cmd
if not "%project%"=="" goto projgiven
rem Still no project, use the parent directory name to get it
call :GetLastDir %0
set project=%result%

:projgiven

call buildtools\delphiversions.cmd

set DelphiVersion=Delphi 2007
set DelphiDir=%Delphi2007Dir%
if exist __SetDelphiVersion.cmd call __SetDelphiVersion.cmd

set OldPath=%PATH%
echo building project %project%.dproj using %DelphiVersion%
call "%DelphiDir%\bin\rsvars.bat"

if NOT "%DelphiVersion%"=="Delphi 2007" goto no2007
rem Delphi 2007 sets the FrameworkDir incorrectly on 64 bit Windows, so we fix this here
SET FrameworkDir=%SystemRoot%\Microsoft.NET\Framework\
SET PATH=%FrameworkDir%%FrameworkVersion%;%FrameworkSDKDir%;%OldPath%
:no2007

pushd src
msbuild %project%.dproj | ..\buildtools\msbuildfilter ..\errors.txt
popd
if errorlevel 1 goto error

endlocal
if "%BatchBuild%"=="1" goto nopause
pause
:nopause
goto :eof

:error
echo ************************************
echo ***** Error building %project% *****
echo ************************************
if "%MAILSend%"=="" goto nomail
%MAILSend% -sub "Error building %project%" -M "Build Error" -attach errors.txt,text/plain,a
endlocal
goto :eof

:nomail
endlocal
pause
goto :eof

:GetLastDir
rem extract path
set directory=%~p1%
rem remove backslash (=last character)
set directory=%directory:~0,-1%
rem extract "filename" (= last directory of path)
call :LastItem %directory%
goto :eof

:LastItem
set result=%~n1%
goto :eof


Actually, this script does some more things:

• It allows me to pass the project name as a parameter.
• If no parameter is passed, it looks for a file called __SetProjectName in the current directory, which can set %project%.
• If that doesn’t exist either, it calls the GetLastDir subroutine to get the last part of the current directory and uses that as the project.
• next, it calls buildtools\delphiversions.cmd which is a script that knows where all my Delphi versions are installed and sets the base directories for them as Delphi2007Dir, Delphi2009Dir etc. environment variables.
• Determine wichh Delphi version it should use. It assumes Delphi 2007 (which I still use for the majority of my projects), looks for __SetDelphiVersion.cmd in the current directory, which is supposed to set %DelphiVersion% and %DelphiDir% if a different version is to be used.
• If Delphi 2007 is to be used, it implements a workaround to fix a problem this version has with setting %FrameworkDir% on 64 bit Windows.
• It calls rsvars.bat (which is a script installed by Delphi)
• It switches to the src subdir
• It calls msbuild for %project%.dproj (msbuildfilter is an internal tool that filters the output and counts hints, warnings and errors)
• If there is no error it either pauses, or if in batchbuild mode, it just exists.
• If there is an error, it checks whether it should send an e-mail and does that (I’ll come back to that in a future blog post.).
• If it sent an e-mail, it exists, otherwise it pauses to let me examine the error.

Last, _OpenInIde.cmd

It needs to:

• Determine the project name (see above)
• Determine the Delphi version to use (again: see above)
• Call the IDE of that version and pass it the appropriate .dproj file
@echo off
REM - assumes that the parent directory is also the project name, extracts it
REM - and calls the IDE with %project%.dproj

setlocal

rem Has the project been passed as parameter?
set project=%1
if not "%project%"=="" goto projgiven
rem Is there a __SetProjectName.cmd which supposedly sets %project%?
if exist __SetProjectName.cmd call __SetProjectName.cmd
if not "%project%"=="" goto projgiven
rem Still no project, use the parent directory name to get it
call :GetLastDir %0
set project=%result%

:projgiven

call buildtools\delphiversions.cmd
set DelphiVersion=Delphi 2007
set DelphiDir=%Delphi2007Dir%
if exist __SetDelphiVersion.cmd call __SetDelphiVersion.cmd

start "%DelphiVerson%" "%DelphiDir%\bin\bds.exe" -pDelphi src\%project%.dproj
endlocal
goto :eof

:GetLastDir
rem extract path
set directory=%~p1%
rem remove backslash (=last character)
set directory=%directory:~0,-1%
rem extract "filename" (= last directory of path)
call :LastItem %directory%
goto :eof

:LastItem
set result=%~n1%
goto :eof


So, am I lazy? I don’t really know. Writing the scripts described above was quite a lot of work. On the other hand, that was interesting work and it keeps me from making stupid errors again and again, like opening a project with the wrong Delphi version and having to revert the changes done by that version, or forgetting to do svn update before checking if the project still compiles. Also, they allow me to run a continuous build server to automatically find compile errors caused by incompatible changes to one of the libraries used, before I or my coworkers forget the reason for that change.

But why have copies of these scripts in all my projects rather than having them in buildtools and only small stubs in the project, that call these scripts? So that’s the next step.

If you want to use these scripts in your own projects or roll your own based on them, feel free to do so. You can find them in my buildtools repository.

Since version 2007 Delphi supports pre- and postbuild events for projects. If you only want to start programs or one batch file it’s a simple matter of adding the call to the respective section of the project options dialog. I use it to manage version numbers in the program resources and manifest files in prebuild and append translations and jcl debug info in postbuild and it works fine.

But a few days ago, I wanted, in addition to the above, to copy some dlls that the program needs to the output directory. So I went and added another batch file like this:
 ..\..\buildtools\postbuild.cmd $(OUTPUTDIR)$(OUTPUTNAME) ..\copydlls.cmd $(OUTPUTDIR)  To my astonishment I found that only the first of the batch files was executed. After looking for the obvious problems (like typos, wrong paths etc.) and adding some debugging code to the batch files which confirmed the assumption, a question on StackOverflow seemed to be in order (which usually works much better than posting to the Embarcadero forums, because of the great guys frequenting it.) While I was waiting for an answer I continued to experiment and found one workaround:  %comspec% /c ..\..\buildtools\postbuild.cmd$(OUTPUTDIR)$(OUTPUTNAME) %comspec% /c ..\copydlls.cmd$(OUTPUTDIR) 
This was like a flashback to the bad old days of DOS, but it worked. I added this result to my question and while I was at it, checked for answers. Still none (but then it had been less than 5 minutes since I posted it. So I started looking for similar questions on StackOverflow that were not tagged Delphi but MSBuild. I found this answer and tried it:
 call ..\..\buildtools\postbuild.cmd $(OUTPUTDIR)$(OUTPUTNAME) call ..\copydlls.cmd \$(OUTPUTDIR) 
It also worked so I added it to my question as well. It looked like a more elegant solution than the %comspec% hack to me, so after more digging didn’t turn up anything else, I posted it as an answer to my own question and went on with my work.

Around half an hour later I looked at the question again and found that it had been answered by David Hefferman. I posted the question at 15:19 and got his answer at 15:36 which is not unusual for StackOverflow (At least this time he didn’t beat me to the solution, but hey, I was actively working on that problem while he was probably doing something completely different.).

After getting Delphi 2005/2006 and 2007 working again the last stumbling block was Delphi 6.

It used to work fine on Windows 8 but after the update to Windows 8.1 it always started the registration wizard for a new activation. Unfortunately this activation did not work, I tried it twice, just to be sure. So, again I turned to the Google and found Code Singh: Virtualising Delphi 6 PC (Activation Errors)

The problem described there looked a lot like the one I was having so since I had nothing to lose, I just deleted the registry entry

HKCU\Software\Borland\Delphi\6.0\LM

(I did not make a backup, what would have been the point?)

I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.

Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.

After getting Delphi 2007 to work again I tried to do the same for Delphi 2005 and 2006.

Both versions require the dotNET framework 1.1 which is officially no longer supported on Windows 8 (and 8.1). According to Microsoft, you should contact your independent software vendor (ISV) to have the application upgraded to run on the .NET Framework 3.5 SP1 or later version. Good luck with that.

This is odd, because I could install and use both Delphi versions on Windows 8. The installations broke only when Windows was updated to 8.1, so Microsoft is BSing us here, at least partly.

Reinstalling the “dotNET Framework 1.1 Redistributable Package” failed with some unhelpful error message.

Praise the Google, I found a solution on this site. The .NET Framework Cleanup Tool resolved that problem. After running it, letting it clean up the mess the update apparently made of the dotNET Framework 1.1 and rebooting, I could reinstall it.

Delphi 2005 started again, complained about something regarding “Star Team” which I just ignored / disabled, and behold, the IDE seemed to work.

The same with Delphi 2006. It too complained about “Star Team” which I again just ignored / disabled. It also seemed to work.

Beware: I haven’t done much more than starting both IDEs and compiling GExperts with it. So there might still be issues.

When I updated to Windows 8.1 my Delphi 2007 installation broke. I could no longer open projects in the IDE and my command line compilation scripts also stopped working. It turned out that some files that were added by the installer to the dotNET framework were missing. In addition there is a known problem with Delphi 2007 on 64 bit Windows (starting with Vista).

This is the error message from the IDE:

followed by this one which is more readable:

(click on the picture to get it in full size)

This is the error message from my build script:

D:\src\MyProject.dproj(77,11):
error MSB4019: The imported project
"C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Borland.Delphi.Targets"
was not found. Confirm that the path in the  declaration is correct,
and that the file exists on disk.


You might notice that the error messages slightly vary: The IDE complains about a missing file in …\Framework\ while the build script complains about the same file in …\Framework64\. I’ll come back to that later.

So here is what I did to fix it:

1. I let Windows search for the missing file Borland.Delphi.Targets and it found it in
C:\ProgramData\{B59CE2E6-B15A-4F23-BD0E-72BF2ADDC3C7}\core\7EFD2DA3\6C948720


(Unfortunately I had already deleted the backup that was created by the Windows Update process.)
After looking closer into this directory I found 4 files that match Borland.*.Targets. It stands to reason that Delphi will need them all in one way or another so I just copied all 4 of them to

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727


After I did that, the IDE no longer complained and also was able to compile the projects.

2. To get the command line compile working again there are three options:
• Some older advice I found on the net said to also copy these files to
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727


I didn’t like that approach because the build process is 32 bit, so why should it involve the 64 bit dotNET framework at all?

• I found that for some reason the rsvars.bat script contained the line
@SET FrameworkDir=C:\Windows\Microsoft.NET\Framework64\


followed by

@SET PATH=%FrameworkDir%%FrameworkVersion%;%FrameworkSDKDir%;%PATH%


The Delphi 2007 installer is probably using some outdated method to find the dotNET framework, which works only on 32 bit Windows. I guess this was fixed in later versions.
So another option to fix the problem is to change the FrameworkDir to point to …\Framework\ rather than …\Framework64\.
I didn’t really like that approach either so I went for option 3.

• I changed my build script to work around this issue:
[...]
set OldPath=%PATH%
call "%DelphiDir%\bin\rsvars.bat"
SET FrameworkDir=%SystemRoot%\Microsoft.NET\Framework\
SET PATH=%FrameworkDir%%FrameworkVersion%;%FrameworkSDKDir%;%OldPath%


(The actual build script is a bit more involved because it allows to call several different Delphi versions depending on an environment variable.)

After this change the build script worked again.

I hope this helps others to fix that problem, but I wrote this post mostly to find this information later if I need it again. ;-)

Just in case you are wondering:

Delphi 2006 and 2005 don’t work either. They are missing an older version of the dotNET framework which was there in Windows 8 but vanished in the update process. Thanks Microsoft! But there is a solution.

Delphi 7 still works. Delphi 6 has some issue with not finding its registration information that I haven’t looked into yet.