How to Fix OLE Error 8004013F on Linux
If you’re attempting to run any sort of database or macro in a Wine-based environment on any sort of GNU/Linux implementation, then you might experience some sort of error message. At some point during the program flow, you might ultimately see an OLE Error 8004013F box. Your script will then immediately cease execution. If this were to happen, then you’re more than likely missing a library that your script needs to run. In a native Windows client, these libraries are used to match objects inside of files with their parent host. Linux doesn’t have this capability, since each program running in an X Server manages things in its own way.
Under a native Microsoft Windows environment, Delphi can use a small bit of code to open Excel. If you wanted an embedded and linked instance of Excel to work with different objects, then you might have used eclApp:=CreateOleObject(‘Excel.Application’); to do so. Inside of Linux, you might have even tried to use OpenOffice this way. Should you find Delphi throwing the dreaded 8004013F error at you after you attempt to create an OLE object with an instance of the eclApp:=CreateOleObject(‘com.sun.star.ServiceManager’); snippet, then you’re probably suffering from the same dependency problem. First, look over your code for any misspellings. These are the most common causes of errors even before dependencies are involved. Once you’re sure that you’ve written everything correctly, and then you can proceed to recover the needed libraries.
Necessary OLE Libraries
You may also experience the same error if you were attempting to use a Windows organizer application called keynote-nf, and if that’s the case then you can use the same process to remedy it. The keynote.exe file doesn’t come with an installer, so it’s common to copy it over to the Program Files directory. While it might run, you could experience either the abovementioned 8004013F error or a different 80004001 exception. In either case, make a directory inside of Program Files with either the mkdir command or your graphical file manager. Call it KeyNote-NF, and move the keynote.exe binary over to it.
If you have access to a Windows XP, Vista, 7, 8, 8.1 or 10 partition, then you might want to try copying the msftedit.dll file from the C:\Windows\system32\ directory to the KeyNote-NF directory you made. You should also copy the msls31.dll file. You could acquire both of these from an installation CD as well, but you’ll need to use the expand command in order to inflate them. In either case, run the program and you should find that it works fine.
Thunar, Nautilus and other similar file managers will identify keynote.exe as a DOS executable, which you can safely ignore. Simply run it like you had previously. When you right-click to access a context menu, you might actually get an option encouraging you to run it under Wine. Select this option to start it. Running the program from the terminal instead will allow you to see any error messages that might rear their head in the process. In some cases, you might actually get a warning about a different file name than either msftedit.dll or msls31.dll, which you should instead acquire. Much like a Unix dependency rabbit hole, you could theoretically spend some time acquiring a directory full of different files.
When you’re having the same problem with Excel or Delphi code, navigate to the directory that contains the executable you’re attempting to run and place the two dynamically linked library files in that directory. You can give Wine total access to these by putting them in ~/.wine/drive_c/Windows/system32 as well, but this might overwrite some of the files that Wine installs by default.
Since these DLLs are superior in some ways to the open-source solutions that Wine uses, they can also aid in linking objects in other programs you might run, but many users don’t like the idea of polluting their Linux installation with closed-source files. Putting them only in the directories your programs actually use is the best way to solve this problem. You can even create directories for actual Windows accessories you’ve copied over from another partition. For instance, some users experience these sorts of problems if they’re using a bash script or Delphi code to start traditional WordPad instances. Wine might have installed it’s own version of write.exe, but there’s nothing stopping you from creating a directory in “~/.wine/drive_c/Program Files/” and placing write.exe, msftedit.dll and msls31.dll to it, then referencing that directory with your code. Since Wine does include a primitive version of the cmd interpreter from Microsoft Windows NT, you can also reference these programs in Batch script files if you prefer. Make sure to preface these with @ECHO OFF, or else each command will appear as though you’ve typed it at a command line and then pushed enter to execute it one after another.
Many sites on the Internet offer DLL objects for download, and it might be tempting to go with one of these repositories if you don’t have a Windows installation on another partition. While they can indeed be certainly convenient, make sure you perform a malware scan on msftedit.dll and msls31.dll if you’re forced to acquire them this way. You shouldn’t treat these repositories the same way that you treat the official ones sponsored by the Ubuntu, Debian and Fedora projects.
Keep in mind too that if you’re forced to acquire them in this manner that it may cause licensing concerns if you’re redistributing your code. Don’t install any executable that any such repository asks about either, since these executables are more often than not a form of adware designed to influence users of actual official Microsoft Windows software environments. The same goes for any case where you might have been required to download a number of different libraries outside of these two, since they can fall prey to the same sort of adware invasion.
