DOS ain't dead

There's a trouble with running binaries under FreeDOS, which are compiled by FreePascal Compiler 2.2.2. When the binary is started to load (via TSR loader or not), it crashes. The most interesting is that fpc 2.2.0 produced binaries that run without any problem ("hello world" or some big projects - doesn`t matter).

I tried several versions of HX Runtime, old and the newest, but the result is the same. Here is a screenshot:

===screenshot===

If I build a binary with -WR (relocateable), it hangs without any error reporting.

Is that a problem of FPC or HX and how can I fix it?

---
% 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 use FPC 2.2.2 and FPC 2.2.2 compiled programs often but I haven't noticed any incompatibility with HX. You should make a test onreal hardware, not in emulator under Vista.

---
DOS-u-akbar!

> I use FPC 2.2.2 and FPC 2.2.2 compiled programs often but I haven't noticed
> any incompatibility with HX. You should make a test onreal hardware, not in
> emulator under Vista.

AFAIK "DOS in a box" comes from DOSEMU. So he's running Linux, not Vista.

---
Forum admin

> AFAIK "DOS in a box" comes from DOSEMU. So he's running Linux, not Vista.

Correct, I use only Linux.

BTW, the same problem appears not only in DOSEMU, but also in qemu, bochs and VirtualBox.

---
% 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 tried several versions of HX Runtime, old and the newest, but the result
> is the same. Here is a screenshot:
>
> ===screenshot===
>
> If I build a binary with -WR (relocateable), it hangs without any error
> reporting.
>
> Is that a problem of FPC or HX and how can I fix it?

exception C0000005 is an access violation. You can probably catch this exception from inside your Pascal program ( in C, it's "signal( SIGSEGV )" ).

---
MS-DOS forever!

> exception C0000005 is an access violation. You can probably catch this
> exception from inside your Pascal program ( in C, it's "signal( SIGSEGV )"
> ).

The problem is that the program cannot be loaded without crash. Even if I write an empty program, compile it (binary that do nothing), it won't be loaded.

---
% 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

Hm, are you sure you use the same parameters for compilation like with FPC 2.2.0?

---
DOS-u-akbar!

> The problem is that the program cannot be loaded without crash. Even if I
> write an empty program, compile it (binary that do nothing), it won't be
> loaded.

Then please send such a binary, mail address see at www.japheth.de!

---
MS-DOS forever!

> Hm, are you sure you use the same parameters for compilation like with FPC
> 2.2.0?

Yeah, the same. Also tried with no parameters.

---
% 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

> Then please send such a binary, mail address see at www.japheth.de!

I've sent it.

---
% 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've sent it.

Thanks!

Running the binary with a debug version of the Win32 kernel dll showed that Win32 function GetModuleHandle() failed. The function is fed with the full path of a binary. The call failed and the calling code apparently doesn't expect this function to fail.

A small fix in DPMILD32.EXE will be necessary.

---
MS-DOS forever!

> A small fix in DPMILD32.EXE will be necessary.

When will you do it?

---
% 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

> > A small fix in DPMILD32.EXE will be necessary.
>
> When will you do it?

I added a test version of dpmild32 into the hxrt WIP package (hxrtd.zip).

---
MS-DOS forever!

> > I've sent it.
>
> Thanks!
>
> Running the binary with a debug version of the Win32 kernel dll showed
> that Win32 function GetModuleHandle() failed. The function is fed with the
> full path of a binary. The call failed and the calling code apparently
> doesn't expect this function to fail.

Well, that can indicate a problem (bad errorchecking) in FPC too. Which call exactly?

> A small fix in DPMILD32.EXE will be necessary.

> I added a test version of dpmild32 into the hxrt WIP package (hxrtd.zip).

Thanks, it fixes a problem, but my large program with several threads still crashes (after loading). Could it be HX problem, or FPC problem? It have never happened before.

---
% 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

Well, you haven't written that you don't use the GO32V2 version but WIN32 version. I don't use the win version I have no experience about it.

---
DOS-u-akbar!

> Well, you haven't written that you don't use the GO32V2 version but WIN32
> version. I don't use the win version I have no experience about it.

Of course, I use win32 version, otherwise I don't need hx :).

---
% 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

> Thanks, it fixes a problem, but my large program with several threads
> still crashes (after loading). Could it be HX problem, or FPC problem? It
> have never happened before.

Sorry, everything works great now. It was an «improvement» of new FPC, where such a trick like sleep(-1) doesn't work in a proper way anymore.

Thanks for fixing a bug in hx.

---
% 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

> > Thanks, it fixes a problem, but my large program with several threads
> > still crashes (after loading). Could it be HX problem, or FPC problem?
> It
> > have never happened before.
>
> Sorry, everything works great now. It was an «improvement» of new FPC,
> where such a trick like sleep(-1) doesn't work in a proper way anymore.

That is new for me, since afaik on windows, sleep is directly passed to windows.

What is sleep(-1) supposed to do according to you?

> That is new for me, since afaik on windows, sleep is directly passed to
> windows.
>
> What is sleep(-1) supposed to do according to you?

It paused thread execution. Just waiting infinite time.

---
% 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

> > That is new for me, since afaik on windows, sleep is directly passed to
> > windows.
> >
> > What is sleep(-1) supposed to do according to you?
>
> It paused thread execution. Just waiting infinite time.

Procedure Sleep(Milliseconds : Cardinal);

begin
Windows.Sleep(MilliSeconds)
end;

The above snip comes from current sources, nothing has changed apparantly. I think you need to search for your problem somewhere else.

> > That is new for me, since afaik on windows, sleep is directly passed to
> > windows.
> >
> > What is sleep(-1) supposed to do according to you?
>
> It paused thread execution. Just waiting infinite time.

But sleep(-1) is no "trick", it's documented. -1 is the value of INFINITE, defined in the Win32 SDK.

---
MS-DOS forever!

> But sleep(-1) is no "trick", it's documented. -1 is the value of INFINITE,
> defined in the Win32 SDK.

But it doesn't work :(.

---
% 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

> > But sleep(-1) is no "trick", it's documented. -1 is the value of
> INFINITE,
> > defined in the Win32 SDK.
>
> But it doesn't work :(.

File a bugreport with Microsoft. We pass it to windows.