DOS ain't dead

WIN32-programs, compiled with FPC 2.4.0 and loaded with HX are not able to handle dynamic libraries (dll) anymore. I tried HXRT217 and 216 with the same result.

I tried to do this under FreeDOS in qemu, bochs and dosemu and got no positive result.

Using FPC 2.2.4 everything works, but I'm not sure that this is FPC trouble, because Linux target does things well even compiled by FPC 2.4.0.

Sources and binaries are available via this link:

http://postfactum.pl.ua/nebula3/download.php?q=da17c1e60708fabbd4984a7b00cd0178

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> WIN32-programs, compiled with FPC 2.4.0 and loaded with HX are not able to
> handle dynamic libraries (dll) anymore. I tried HXRT217 and 216 with the
> same result.

I'm not entirely sure, but it might be that FPC 2.4.0 uses some -W bits here and there, and afaik now requires MSLU (on w9x. I don't know if HX emulates the -W stuff/MSLU)

> Sources and binaries are available via this link:
>
> http://postfactum.pl.ua/nebula3/download.php?q=da17c1e60708fabbd4984a7b00cd0178

Binary works fine under XP.


* added later: the stuff between parentheses.

> I'm not entirely sure, but it might be that FPC 2.4.0 uses some -W bits
> here and there, and afaik now requires MSLU.

First of all, I tried to play with fpc -W switches, but got no result.

Putting MSLU files (unicows.dll and unicows.pdb) into testing folder didn't help as well.

What should I do?

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> > I'm not entirely sure, but it might be that FPC 2.4.0 uses some -W bits
> > here and there, and afaik now requires MSLU.
>
> First of all, I tried to play with fpc -W switches, but got no result.
>
> Putting MSLU files (unicows.dll and unicows.pdb) into testing folder
> didn't help as well.
>
> What should I do?

Dunno, but here's a informative link (esp. about the partial Mozilla reimplementation):

http://en.wikipedia.org/wiki/Microsoft_Layer_for_Unicode

> Dunno, but here's a informative link (esp. about the partial Mozilla
> reimplementation):
>
> http://en.wikipedia.org/wiki/Microsoft_Layer_for_Unicode

I have no idea how to apply this to fixing the issue :(.

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> > Dunno, but here's a informative link (esp. about the partial Mozilla
> > reimplementation):
> >
> > http://en.wikipedia.org/wiki/Microsoft_Layer_for_Unicode
>
> I have no idea how to apply this to fixing the issue :(.

Sorry, not sure it will. But can you at least try OpenCow? Or try WDOSX, there is some minimal support for that in FPC too (or at least used to be).

> Sorry, not sure it will. But can you at least try OpenCow?

How? And why should it help?

> Or try WDOSX,
> there is some minimal support for that in FPC too (or at least used to
> be).

I tried WDOSX, it has no threads support.

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> WIN32-programs, compiled with FPC 2.4.0 and loaded with HX are not able to
> handle dynamic libraries (dll) anymore. I tried HXRT217 and 216 with the
> same result.
>
> I tried to do this under FreeDOS in qemu, bochs and dosemu and got no
> positive result.
>
> Using FPC 2.2.4 everything works, but I'm not sure that this is FPC
> trouble, because Linux target does things well even compiled by FPC
> 2.4.0.

I ran your test app under a debugger. AFAICS the problem is that your dll's DllMain function ( sometimes also called LibMain ) returns -1. HX's DPMILD32 expects this function to return 1 on success.

This is what MSDN says about DllMain's return value:

-------------------------------------------------------------
When the system calls the DllMain function with the DLL_PROCESS_ATTACH value, the function returns TRUE if it succeeds or FALSE if initialization fails. If the return value is FALSE when DllMain is called because the process uses the LoadLibrary function, LoadLibrary returns NULL. (The system immediately calls your entry-point function with DLL_PROCESS_DETACH and unloads the DLL.) If the return value is FALSE when DllMain is called during process initialization, the process terminates with
-------------------------------------------------------------


It seems that DPMILD32 is slightly more picky than Windows.

Btw., the DllMain function inside lib.dll calls LoadLibrary() on its own, which - according to MSDN - is an error:

-------------------------------------------------------------
Warning  On attach, the body of your DLL entry-point function should perform only simple initialization tasks, such as setting up thread local storage (TLS), creating objects, and opening files. You must not call LoadLibrary in the entry-point function, because you may create dependency loops in the DLL load order. This can result in a DLL being used before the system
-------------------------------------------------------------


---
MS-DOS forever!

> I ran your test app under a debugger. AFAICS the problem is that your
> dll's DllMain function ( sometimes also called LibMain ) returns -1. HX's
> DPMILD32 expects this function to return 1 on success.

As I understand from Google, there's no way to set up returning 1 from DllMain in FPC :(.

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> > I ran your test app under a debugger. AFAICS the problem is that your
> > dll's DllMain function ( sometimes also called LibMain ) returns -1.
> HX's
> > DPMILD32 expects this function to return 1 on success.
>
> As I understand from Google, there's no way to set up returning 1 from
> DllMain in FPC :(.

Doesn't it have to do with the new implementation of TRUE in FPC?

---
Glory to God for all things

> Doesn't it have to do with the new implementation of TRUE and FALSE in
> FPC?

http://wiki.freepascal.org/User_Changes_2.4.0#Byte.2FWord.2FLong.2FQwordbool_types

This one? But, in such case, who is right ? HX, WinAPI or FPC?

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> http://wiki.freepascal.org/User_Changes_2.4.0#Byte.2FWord.2FLong.2FQwordbool_types
>
> This one? But, in such case, who is right — HX, WinAPI or FPC?

Be aware that various compilers for different programming languages have different definitions for TRUE (AFAIK FALSE is always 0). So it is better to check for 1 or -1 when it is the case, instead of TRUE. Certainly not your fault, but they missed it.

---
Glory to God for all things

> Be aware that various compilers for different programming languages have
> different definitions for TRUE (AFAIK FALSE is always 0). So it is better
> to check for 1 or -1 when it is the case, instead of TRUE. Certainly not
> your fault, but they missed it.

So to fix this, I have to recompile FPC?

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> So to fix this, I have to recompile FPC?

It's rather trivial to fix in DPMILD32. So I did a small update to HXRT217.ZIP, which then hopefully works with fpc 2.4.

---
MS-DOS forever!

> It's rather trivial to fix in DPMILD32. So I did a small update to
> HXRT217.ZIP, which then hopefully works with fpc 2.4.

Yes, it works. Thanks a lot.

---
% uname -a
Linux eternity 3.0.1-pf #1 SMP PREEMPT Fri Aug 5 21:45:05 EEST 2011 i686 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

> > It's rather trivial to fix in DPMILD32. So I did a small update to
> > HXRT217.ZIP, which then hopefully works with fpc 2.4.
>
> Yes, it works. Thanks a lot.

Yes, big thanks!