DOS ain't dead

I have been trying to run Minecraft on DOS since I knew HX. If you don't know, it's a 3D sandbox game, written with java, and requires JVM to run. I know the game would be extremely slow even if it eventually works, since no hardware acceleration is available on DOS. Anyway, Java 1.5.0_22 can be run natively on Windows 9x systems, as well as DOS with HX. Then, I added java's binary directory into %PATH%, downloaded lwjgl (one of the library it needs), copied opengl32.dll to my DOS VM from Windows 98. Then I started it with the following command line:

javaw -Djava.library.path=./natives -cp 0.jar;1.jar;2.jar;3.jar;4.jar net.minecraft.client.Minecraft

(I renamed the libraries to avoid 126 characters commandline restriction)
It crashed , and created a file named "hxstderr.log", contains following error message:


Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\JAVA\jdk1.5.0_22\JRE\BIN\AWT.DLL: MsgId: 0000000B
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1753)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1670)
        at java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.lang.System.loadLibrary(System.java:993)
        at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
        at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
        at java.awt.Component.<clinit>(Component.java:547)
        at net.minecraft.client.Minecraft.a(SourceFile:2063)
        at net.minecraft.client.Minecraft.a(SourceFile:2056)
        at net.minecraft.client.Minecraft.main(SourceFile:2135)


I tried to resolve this problem myself, so I searched the "UnsatisfiedLinkError" on Internet. Unfortunately, no valuable infomation was found. This is usually caused by java can't find the specific library, but that's not my case - the file is RIGHT there! Also, I don't know what that "MsgId: 0000000B" means.
In case you don't know, AWT is a toolkit shipped with java, and it's used to handle windows. I also wrote a java progarm to test AWT:


package awttest;
import java.awt.Color;
import java.awt.Frame;

public class Test extends Frame{

        public static void main(String[] args) {
                // TODO Auto-generated method stub
                Test fr = new Test("AWT test");
                fr.setSize(240,240);
                fr.setBackground(Color.yellow);
                fr.setVisible(true);

        }
        public Test(String str) {
                super(str);
        }

}


This program create a yellow window on Windows 98, but when I tried it on DOS, this error message appears:


java.lang.UnsatisfiedLinkError: C:\JAVA\jdk1.5.0_22\JRE\BIN\AWT.DLL: MsgId: 0000000B
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1753)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1670)
        at java.lang.Runtime.loadLibrary0(Runtime.java:822)
        at java.lang.System.loadLibrary(System.java:993)
        at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
        at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
        at java.awt.Component.<clinit>(Component.java:547)
Exception in thread "main"


Which is basically the same as the above one. How do you think this problem happened?

> Also, I don't know what that "MsgId: 0000000B" means.

That's a message from HX's kernel32 emulation, Win32 function FormatMessage(). The "0000000B" might be a resource ID that isn't found - or it's a bug in the emulation code.

---
MS-DOS forever!

> I have been trying to run Minecraft on DOS

Imho, 95% you will meet multithreading in Minecraft.

About AWT: "The reason is that AWT encapsulates asynchronous event dispatch machinery to process events AWT or Swing components can fire. The exact behavior of this machinery is implementation-dependent. In particular, it can start non-daemon helper threads for its internal purposes."

About java: "According to The Java™ Virtual Machine Specification, sections 2.17.9 and 2.19, the Java virtual machine (JVM) initially starts up with a single non-daemon thread, which typically calls the main method of some class."

IMHO, you can run console apps (like helloworld), but not expect gui.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

OK, after doing some reverse-engineering, I found that "java.lang.ClassLoader$NativeLibrary.load" is an exported function in java.dll. It's named "_Java_java_lang_ClassLoader_00024NativeLibrary_load@12". That function calls "_JVM_LoadLibrary@4", which yet another is an exported function in jvm.dll. It does a lot of operations, but eventually, It calls "LoadLibraryA".
Here are some decompiled codes from Ghidra:

HMODULE __cdecl FUN_6d81dee4(LPCSTR param_1,char *param_2,uint param_3)

{
  bool bVar1;
  HMODULE pHVar2;
  DWORD DVar3;
  int _FileHandle;
  int iVar4;
  undefined **ppuVar5;
  int extraout_EDX;
  int extraout_EDX_00;
  undefined *puVar6;
  undefined *puVar7;
  char *_Format;
  int local_c;
  uint local_8;
 
  pHVar2 = LoadLibraryA(param_1);
  if (pHVar2 == (HMODULE)0x0) {
    DVar3 = GetLastError();
    if (DVar3 == 0x7e) {
      strncpy(param_2,s_Can't_find_dependent_libraries_6d89e3ac,param_3 - 1);
      param_2[param_3 - 1] = '\0';
    }
    else {
      FUN_6d81ff15(param_2,param_3);
      param_2[param_3 - 1] = '\0';
      _FileHandle = _open(param_1,0x8000);
      if (-1 < _FileHandle) {
        local_8 = 0;
        FUN_6d7e66bc(_FileHandle,0x3c,0,0);
        if ((((extraout_EDX < 0) || (iVar4 = _read(_FileHandle,&local_c,4), iVar4 != 4)) ||
            (FUN_6d7e66bc(_FileHandle,local_c + 4,0,0), extraout_EDX_00 < 0)) ||
           (iVar4 = _read(_FileHandle,&local_8,2), iVar4 != 2)) {
          bVar1 = true;
        }
        else {
          bVar1 = false;
        }
        _close(_FileHandle);
        if (!bVar1) {
          puVar6 = (undefined *)0x0;
          puVar7 = (undefined *)0x0;
          ppuVar5 = &PTR_s_IA_32_6d878994;
          do {
            if ((short)local_8 == *(short *)(ppuVar5 + -1)) {
              puVar7 = *ppuVar5;
            }
            if (*(short *)(ppuVar5 + -1) == 0x14c) {
              puVar6 = *ppuVar5;
            }
            ppuVar5 = ppuVar5 + 2;
          } while (ppuVar5 < &DAT_6d8789ac);
          if ((short)local_8 != 0x14c) {
            if (puVar7 == (undefined *)0x0) {
              puVar7 = (undefined *)(local_8 & 0xffff);
              _Format = s_Can't_load_this_.dll_(machine_co_6d89e340;
            }
            else {
              _Format = s_Can't_load_%s-bit_.dll_on_a_%s-b_6d89e380;
            }
            _snprintf(param_2,param_3 - 1,_Format,puVar7,puVar6);
          }
        }
      }
    }
    pHVar2 = (HMODULE)0x0;
  }
  return pHVar2;
}

Apparently, this piece of code checks whether the module is loaded successfully. If it is, the function returns the loaded module's base address. If it's not, it modifies the character array "param_2" in the formal parameter, then returns 0. Notice that the function "FUN_6d81ff15" is where the "FormatMessageA" is called:

size_t __cdecl FUN_6d81ff15(char *param_1,uint param_2)

{
  char cVar1;
  DWORD dwMessageId;
  size_t _Count;
  int *piVar2;
  char *_Source;
  uint uVar3;
  char *pcVar4;
 
  dwMessageId = GetLastError();//It should be 0xB, I guess.
  if (dwMessageId == 0) {
    piVar2 = _errno();
    if (*piVar2 == 0) {
      _Count = 0;
    }
    else {
      piVar2 = _errno();
      _Source = strerror(*piVar2);
      uVar3 = 0xffffffff;
      pcVar4 = _Source;
      do {
        if (uVar3 == 0) break;
        uVar3 = uVar3 - 1;
        cVar1 = *pcVar4;
        pcVar4 = pcVar4 + 1;
      } while (cVar1 != '\0');
      _Count = ~uVar3 - 1;
      if (param_2 <= _Count) {
        _Count = param_2 - 1;
      }
      strncpy(param_1,_Source,_Count);
      param_1[_Count] = '\0';
    }
  }
  else {
    _Count = FormatMessageA(0x1200,(LPCVOID)0x0,dwMessageId,0,param_1,param_2,(va_list *)0x0);
    if (3 < _Count) {
      if (param_1[_Count - 1] == '\n') {
        _Count = _Count - 1;
      }
      if (param_1[_Count - 1] == '\r') {
        _Count = _Count - 1;
      }
      if (param_1[_Count - 1] == '.') {
        _Count = _Count - 1;
      }
      param_1[_Count] = '\0';
    }
  }
  return _Count;
}

Now I have a theory, I wanna debug HX to see if it's true, also, try to figure out why "LoadLibraryA" fails. But I got stuck on debugging. I didn't realized that HX is written in assembly language, which I don't understand. I really don't know what should I do next...

Hello 4D5A9000,

>
> size_t __cdecl FUN_6d81ff15(char *param_1,uint param_2)
>
> {
> char cVar1;
> DWORD dwMessageId;
> size_t _Count;
> int *piVar2;
> char *_Source;
> uint uVar3;
> char *pcVar4;
>
> dwMessageId = GetLastError();//It should be 0xB, I guess.
> ...
>

If the error code is indeed coming from GetLastError(), then Microsoft's documentation (https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-) says that it means ... ERROR_BAD_FORMAT?

Which will mean that HX did find the .dll, but for some reason decided that it did not like its contents.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> Which will mean that HX did find the .dll, but for some reason decided that
> it did not like its contents.

Yes, probably a missing import.

To verify, try to load the dll directly with dpmild32.exe:

C:\>dpmild32 awt.dll

the loader will then display more information.

---
MS-DOS forever!

Well, it crashed:

C:\JAVA\jdk1.5.0_22\JRE\BIN>dpmild32 awt.dll

DPMI loader version 3.9.0
Copyright (C) 1993-2018 Japheth

Exception 0E
EAX=00798000 EBX=0000F000 ECX=0000008F EDX=0000575E ESI=00771040
EDI=00005620 EBP=00005772 ESP=00798000 EFL=00013206 EIP=00002A22
CS=0097 (00110000,000058CF,00FB) SS=00BF (00000000,FFFFFFFF,CFF3)
DS=00BF (00000000,FFFFFFFF,CFF3) ES=00BF (00000000,FFFFFFFF,CFF3)
FS=0000 (********,********,****) GS=0000 (********,********,****)
LDTR=0038 (FF80A000,00000FFF,0082) TR=0030 (00037068,00000067,008B)
ERRC=0006 (********,********,****) PTE 1. Page LDT=0020D467
GDTR=07FF:FF808800 IDTR=07FF:FF809000 PTE CR2=0086D404
CR0=80000031 CR2=00797FFC CR3=00200000 CR4=00000200 TSS:ESP0=00000804
DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400
LPMS Sel/Cnt=0087/0001 RMS=4E00:0200 open RMCBs=0000/0000 ISR=0000
   [EIP]=66 51 66 52 2E 8B 0E CA 41 67 66 8B
   [ESP]=????
terminate (c)lient or (s)erver now?


> Exception 0E
> EAX=00798000 EBX=0000F000 ECX=0000008F EDX=0000575E ESI=00771040
> EDI=00005620 EBP=00005772 ESP=00798000 EFL=00013206 EIP=00002A22
> CS=0097 (00110000,000058CF,00FB) SS=00BF (00000000,FFFFFFFF,CFF3)
> DS=00BF (00000000,FFFFFFFF,CFF3) ES=00BF (00000000,FFFFFFFF,CFF3)
> FS=0000 (********,********,****) GS=0000 (********,********,****)
> LDTR=0038 (FF80A000,00000FFF,0082) TR=0030 (00037068,00000067,008B)
> ERRC=0006 (********,********,****) PTE 1. Page LDT=0020D467
> GDTR=07FF:FF808800 IDTR=07FF:FF809000 PTE CR2=0086D404
> CR0=80000031 CR2=00797FFC CR3=00200000 CR4=00000200 TSS:ESP0=00000804
> DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400
> LPMS Sel/Cnt=0087/0001 RMS=4E00:0200 open RMCBs=0000/0000 ISR=0000
> [EIP]=66 51 66 52 2E 8B 0E CA 41 67 66 8B
> [ESP]=????

It crashed, yes, but apparently just due to insufficient stack space.

That may happen, because for a dll there is no defined stack size, and the loader might supply a (default) stack space that is "too small" for the dll initialization code.

The important information is that it seems that there are NO missing imports.

---
MS-DOS forever!

Hello Japheth,

> It crashed, yes, but apparently just due to insufficient stack space.
> That may happen, because for a dll there is no defined stack size, and the
> loader might supply a (default) stack space that is "too small" for the dll
> initialization code.
> The important information is that it seems that there are NO missing
> imports.

Then the question, I guess, is where the ERROR_BAD_FORMAT is actually coming from...?

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> That may happen, because for a dll there is no defined stack size, and the
> loader might supply a (default) stack space that is "too small" for the dll
> initialization code.

Well, how to adjust the stack space?

>
> Well, how to adjust the stack space?

Since the "stack space" problem occurs only if the dll is loaded directly by dpmild32, it's pretty useless trying to "fix" it - it won't help with the real application.

---
MS-DOS forever!

> >
> > Well, how to adjust the stack space?
>
> Since the "stack space" problem occurs only if the dll is loaded directly
> by dpmild32, it's pretty useless trying to "fix" it - it won't help with
> the real application.

it's been a while since last time I post you.
And, unfortunately I made no progress

I've tried to use dpmild32 to load some DLLs that can be loaded properly during the execution of java, such as java.dll. dpmild32 also crashed.
Would you like to help me figure out why HX doesn't like these DLLs if I sent them to you?