Laaca
Czech republic, 06.06.2020, 09:34 |
HX-DOS extender and TryEnterCriticalSection (DOSX) |
I tried whether is possible to work with Win32 version of Freepascal under HX-DOS.
In versions 3.0.4 and 3.2.0rc1 all FPC-win32 refuse to run and they complain about missing import TryEnterCriticalSection and some also about FindFirstFileExW.
Even compiled "hello world" program complains about TryEnterCriticalSection.
But _suprisingly_ if I set the DPMILDR variable to 128 (SET DPMILDR=128) the situation changes.
Under FPC 3.0.4 the HELLO.EXE works and few other programs also work. Some absolutely without problems some write on the end error message "DPMILD32: Unresolved import called" but otherwise is it OK.
Even the compiler itself work eith the DPMILDR 128 normaly. (the command line only, not the IDE).
So, my question is: Is possible to implement into next release of HX-DOS the function TryEnterCritical section? And also FindFirstFileExW?
Maybe even the stubs could be OK.
And why am I examining this?
Because we still don't have a good DOS based FTP server working with LFNs.
And here is a chance that it could be done in FPC-Win32 application running under HXDOS. --- DOS-u-akbar! |
Japheth
Germany (South), 06.06.2020, 19:20
@ Laaca
|
HX-DOS extender and TryEnterCriticalSection |
> But _suprisingly_ if I set the DPMILDR variable to 128 (SET DPMILDR=128)
> the situation changes.
It's not very "surprisingly" because that's what the documentation tells:
- bit 7 (DPMILDR=128): ignore unresolved imports. With this
setting the loader will continue to load and execute a binary even
if an unresolved import has been detected. If such an import is
called, however, an error message is displayed and the application
will exit.
> So, my question is: Is possible to implement into next release of HX-DOS
> the function TryEnterCritical section? And also FindFirstFileExW?
It's surely possible. However, I'm currently busy with real life issues.
> Maybe even the stubs could be OK.
You could probably add those yourself. File CRITSECT.ASM is a candidate for implementing TryEnterCriticalSection. --- MS-DOS forever! |
Japheth
Germany (South), 09.06.2020, 16:25
@ Japheth
|
HX-DOS extender and TryEnterCriticalSection |
> You could probably add those yourself. File CRITSECT.ASM is a candidate for
> implementing TryEnterCriticalSection.
TryEnterCriticalSection has been added, its functional, but untested. --- MS-DOS forever! |
Laaca
Czech republic, 10.06.2020, 10:58
@ Japheth
|
HX-DOS extender and TryEnterCriticalSection |
> > You could probably add those yourself. File CRITSECT.ASM is a candidate
> for
> > implementing TryEnterCriticalSection.
>
> TryEnterCriticalSection has been added, its functional, but untested.
Cool. As soon as I arrive home I'll test it
BTW: I briefly looked at the source; it is a kind of black magic for me however I noticed a nice thing in your assembler.
I noticed that it allows to name the labels with non-unique names. I always thought that all labels for jumps must be unique for all ASM file.
But you use label "is_ours:" in more places (althgough in various procedures). Mayve is it a common feature of all assemblers but it is a new information for me --- DOS-u-akbar! |
Laaca
Czech republic, 10.06.2020, 18:29
@ Laaca
|
HX-DOS extender and TryEnterCriticalSection |
Good work. The implementation of TryEnterCriticalSection works. So now work the programs compiled with FPC for Win32 in DOS.
In case of FPC 3.0.4 works even the command line compiler itself.
(and FPC 3.2.0 does not because it wants to use the "FindFirstFileExW") --- DOS-u-akbar! |
Rugxulo
Usono, 11.06.2020, 18:40
@ Laaca
|
MASM v6 scoping for labels |
> however I noticed a nice thing in your assembler.
> I noticed that it allows to name the labels with non-unique names. I always
> thought that all labels for jumps must be unique for all ASM file.
> But you use label "is_ours:" in more places (althgough in various
> procedures). Mayve is it a common feature of all assemblers but it is a new
> information for me
Most x86 assemblers are incompatible since there is no official standard. So, anything goes, usually. However ....
See Art of Assembly, Chapter 12:
> 12.1.1 Scope
>
> By default, MASM 6.x treats statement labels (those with a colon after them)
> as local to a procedure [PROC ... ENDP].
The way around that, when needed, is "option noscoped" or double colon after label name. |