Om du försöker köra någon form av databas eller makro i en vinbaserad miljö på någon form av GNU / Linux-implementering kan du uppleva något slags felmeddelande. Någon gång under programflödet kan du i slutändan se en OLE-fel 8004013F låda. Ditt manus kommer då att omedelbart upphöra med körningen. Om detta skulle hända saknar du mer än troligt ett bibliotek som ditt skript behöver köras. I en inbyggd Windows-klient används dessa bibliotek för att matcha objekt inuti filer med sin överordnade värd. Linux har inte den här möjligheten, eftersom varje program som körs på en X Server hanterar saker på sitt eget sätt.
Under en inbyggd Microsoft Windows-miljö kan Delphi använda en liten bit kod för att öppna Excel. Om du ville att en inbäddad och länkad instans av Excel skulle fungera med olika objekt, kan du ha använt det eclApp: = CreateOleObject (‘Excel.Application’); att göra så. Inuti Linux kan du till och med ha försökt använda OpenOffice på detta sätt. Skulle du hitta Delphi kasta den fruktade 8004013F fel när du försöker skapa ett OLE-objekt med en instans av eclApp: = CreateOleObject (‘com.sun.star.ServiceManager’); utdrag, då lider du förmodligen av samma beroendeproblem. Titta först över din kod för eventuella felstavningar. Detta är de vanligaste orsakerna till fel även innan beroenden är inblandade. När du är säker på att du har skrivit allt korrekt och sedan kan du fortsätta att återställa de bibliotek som behövs.
Nödvändiga OLE-bibliotek
Du kan också uppleva samma fel om du försökte använda ett Windows-arrangörsprogram som heter keynote-nf, och om så är fallet kan du använda samma process för att avhjälpa det. Keynote.exe-filen levereras inte med ett installationsprogram, så det är vanligt att kopiera den till katalogen Programfiler. Även om den kan köras kan du uppleva antingen det ovan nämnda 8004013F-felet eller ett annat 80004001-undantag. I båda fallen gör du en katalog inuti Program Files med antingen kommandot mkdir eller din grafiska filhanterare. Kalla det KeyNote-NF och flytta binärt keynote.exe till det.
Om du har tillgång till en Windows XP-, Vista-, 7, 8, 8.1 eller 10-partition kan du försöka kopiera msftedit.dll-filen från C: Windows system32 katalog till KeyNote-NF-katalogen du skapade. Du bör också kopiera filen msls31.dll. Du kan också skaffa båda dessa från en installations-CD, men du måste använda kommandot expand för att blåsa upp dem. I båda fallen kör du programmet och du bör upptäcka att det fungerar bra.
Thunar, Nautilus och andra liknande filhanterare kommer att identifiera keynote.exe som en DOS-körbar, som du säkert kan ignorera. Kör bara det som du hade tidigare. När du högerklickar för att komma åt en snabbmeny kan du faktiskt få ett alternativ som uppmuntrar dig att köra den under Vin. Välj det här alternativet för att starta det. Att köra programmet från terminalen i stället låter dig se eventuella felmeddelanden som kan baka huvudet i processen. I vissa fall kan du faktiskt få en varning om ett annat filnamn än antingen msftedit.dll eller msls31.dll, som du istället bör skaffa. Precis som ett Unix-beroende kaninhål kan du teoretiskt spendera lite tid på att skaffa en katalog full av olika filer.
När du har samma problem med Excel- eller Delphi-kod, navigerar du till katalogen som innehåller den körbara versionen du försöker köra och placerar de två dynamiskt länkade biblioteksfilerna i den katalogen. Du kan ge Wine total tillgång till dessa genom att sätta in dem ~ / .wine / drive_c / Windows / system32 också, men detta kan skriva över några av de filer som Wine installerar som standard.
Eftersom dessa DLL-filer på vissa sätt är överlägsna de öppna källkodslösningarna som Wine använder, kan de också hjälpa till att länka objekt i andra program som du kan köra, men många användare tycker inte om idén att förorena sin Linux-installation med sluten källa filer. Att bara placera dem i de kataloger som dina program faktiskt använder är det bästa sättet att lösa detta problem. Du kan till och med skapa kataloger för faktiska Windows-tillbehör som du har kopierat från en annan partition. Till exempel upplever vissa användare sådana problem om de använder ett bash-skript eller Delphi-kod för att starta traditionella WordPad-instanser. Vin kan ha installerat sin egen version av write.exe, men det finns inget som hindrar dig från att skapa en katalog i “~ / .Wine / drive_c / Program Files /” och placera write.exe, msftedit.dll och msls31.dll till den och refererar sedan till den katalogen med din kod. Eftersom Wine innehåller en primitiv version av cmd-tolk från Microsoft Windows NT kan du också referera till dessa program i batch-skriptfiler om du föredrar det. Se till att du förordar dessa med @ECHO OFF, annars visas varje kommando som om du har skrivit in det på en kommandorad och sedan tryckt på enter för att utföra det efter varandra.
Många webbplatser på Internet erbjuder DLL-objekt för nedladdning, och det kan vara frestande att gå med ett av dessa arkiv om du inte har en Windows-installation på en annan partition. Även om de verkligen kan vara praktiska, se till att du utför en skanning av skadlig kod på msftedit.dll och msls31.dll om du tvingas skaffa dem på det här sättet. Du bör inte behandla dessa arkiv på samma sätt som du behandlar de officiella som sponsras av projekten Ubuntu, Debian och Fedora.
Tänk också på att om du tvingas förvärva dem på detta sätt kan det orsaka licensproblem om du omfördelar din kod. Installera inte några körbara filer som något sådant arkiv frågar om heller, eftersom dessa körbara filer oftare är en form av adware som är utformad för att påverka användare av faktiska officiella Microsoft Windows-programvarumiljöer. Detsamma gäller alla fall där du kan ha varit tvungen att ladda ner ett antal olika bibliotek utanför dessa två, eftersom de kan bli offer för samma typ av adware-invasion.
4 minuter läst
