"Simon J Mackenzie" <project.d@smackoz.fastmail.fm> wrote in message news:baqcgk$1avt$1@digitaldaemon.com...
> Hi Nic,
> I assume that WDosX is not designed to be used with a DMD executable.
> When I run stubit -nowfse hello.exe (dmd hello.d from the samples\d
> directory) it seems happy enough but I get the following runtime errors
> with hello.exe. a) with your *.wdl files : Could not find CreateThread
> in module Kernel32.DLL b) with WDosX 97B1 : Could not find
> ReleaseSemaphore in module Kernel32.DLL. NB: Yes KERNEL32.DLL and not
> ..32.WDL!
>
> Does this mean there are still more Win32 calls in a DMD executable that are not supported by WDosX???  If this is the case then I guess it means I will be unable to use DMD to create 32bit DOS apps?
>
> cheers
> Simon

Apparently wdosx does not support multithreaded programming. You could remove all those calls from the Phobos library and recompile it.

Walter wrote:
> 
> Apparently wdosx does not support multithreaded programming. You could
> remove all those calls from the Phobos library and recompile it.
> 
> 

Thanks for the info.  I'll have a look at the library source and see how far I get with the mods and recompilation.

Simon

Thanks for info.
I assume that CreateThread is not really used in simple applications, so I
can create stub for it.
I will post it when I do.

Anyhow, I already developed multi-threading kernel for DOSX and it is a matter of time when I attach it to DMC runtime library. So I assume we could use multithreading even in plain DOSX.

And about WDOSX's stubit: it really complains about .DLL, but this means that first it searched through .WDL module and then tried resolve externals with REAL DLL name (in file it is KERNEL32.DLL)

Nic Tiger.

"Simon J Mackenzie" <project.d@smackoz.fastmail.fm> wrote in message news:baqcgk$1avt$1@digitaldaemon.com...
> Hi Nic,
> I assume that WDosX is not designed to be used with a DMD executable.
> When I run stubit -nowfse hello.exe (dmd hello.d from the samples\d
> directory) it seems happy enough but I get the following runtime errors
> with hello.exe. a) with your *.wdl files : Could not find CreateThread
> in module Kernel32.DLL b) with WDosX 97B1 : Could not find
> ReleaseSemaphore in module Kernel32.DLL. NB: Yes KERNEL32.DLL and not
> ..32.WDL!
>
> Does this mean there are still more Win32 calls in a DMD executable that are not supported by WDosX???  If this is the case then I guess it means I will be unable to use DMD to create 32bit DOS apps?
>
> cheers
> Simon
>
>
>
>
> Nic Tiger wrote:
> > D is not directly supported under DOSX, but you could make DMD binaries
run
> > under DOS by using modified WDOSX.
> >
> > For details, look for message 'Re: Using DMC from DOS' in "c++.announce" news-group.
> >
> > WDOSX is obviously slower than Doug Huffman's DOSX (by my estimations,
it is
> > twice slower), but it supports DLLs 'natively'.
> > In order to make DMD produce DOSX executables the run-time library
should be
> > rewritten and appropriate startup module written. And in addition to
this
> > Walter should add DOSX model for compilation.
> >
> > I am going to rewrite RTL for DOSX but this will be little later. I
think I
> > will be very busy in next 2-3 months.
> >
> > Nic Tiger.
> >
> > "Simon J Mackenzie" <project.d@smackoz.fastmail.fm> wrote in message news:bac9ap$1jd4$1@digitaldaemon.com...
> >
> >>I'm wanting to try out D with DOSX.
> >>Has anyone ported the D to DOSX yet?
> >>What would the port involve?
> >>
> >>Regards, Simon, potential DeeVohTee
> >>
> >
> >
> >
>

I am intrigued by the effort you put into DOSX. While I believe that DOSX is a great product, and the best DOS extender by far, I also think that their time has past. What keeps you developing for it?

"Nic Tiger" <tiger7@progtech.ru> wrote in message news:bauocv$3rs$1@digitaldaemon.com...
> Thanks for info.
> I assume that CreateThread is not really used in simple applications, so I
> can create stub for it.
> I will post it when I do.
>
> Anyhow, I already developed multi-threading kernel for DOSX and it is a matter of time when I attach it to DMC runtime library. So I assume we
could
> use multithreading even in plain DOSX.
>
> And about WDOSX's stubit: it really complains about .DLL, but this means that first it searched through .WDL module and then tried resolve
externals
> with REAL DLL name (in file it is KERNEL32.DLL)
>
> Nic Tiger.

I have several reasons:

1) It is stable by itself (it doesn't introduce its own bugs as Windows
does), and my own bug I can always find and fix

2) I have sophisticated GUI developed from scratch with usage of inheritance, so I don't need Windows GUI. In fact the only plus in Windows (that I haven't yet have in DOSX) is visual development tools. But this can be done in DOSX either

3) DOSX has not (or almost has not) performance shortcomings in comparison
to Windows. On the other hand I have all resources in my disposal in DOSX.
The (fixable) problem I encounter now is alignment problem. It seems that
DMC needs controlled alignment (it is crucial for SIMD code).

About performance, I compiled XVID codec for DOSX and it runs about 5% faster in DOSX than in Windows (and when assembler is switched off, it runs 30-40% faster!)

4) I develop specialized systems, such as flight data ground-based processing system or hardware modeling systems

5) There is no way to get good Real-Time performance in Windows even on top-most CPUs (I tried PIII 1000 and P4 2400). The accuracy of Windows timer is terrible. On the other hand I can do all hardware jobs from DOSX easily which is required for controlling missile guidance system in real-time, for example.

6) Most of issues of Windows are applicable for Linux too. In addition to this, X in Linux is *very* slow (in fact, inappropriately slow). The solution I see is to implement my own GUI in Linux, but this will be effectively the same as DOSX. The other problem with Linux is GCC. If I had DMC working for Linux, I think I could port all my development from DOSX to Linux for several weeks, but with GCC's inline assembler it seems impossible.

Sincerely yours,
Nic Tiger.

"Walter" <walter@digitalmars.com> wrote in message news:bb1crt$2epd$1@digitaldaemon.com...
> I am intrigued by the effort you put into DOSX. While I believe that DOSX
is
> a great product, and the best DOS extender by far, I also think that their time has past. What keeps you developing for it?
>
> "Nic Tiger" <tiger7@progtech.ru> wrote in message news:bauocv$3rs$1@digitaldaemon.com...
> > Thanks for info.
> > I assume that CreateThread is not really used in simple applications, so
I
> > can create stub for it.
> > I will post it when I do.
> >
> > Anyhow, I already developed multi-threading kernel for DOSX and it is a matter of time when I attach it to DMC runtime library. So I assume we
> could
> > use multithreading even in plain DOSX.
> >
> > And about WDOSX's stubit: it really complains about .DLL, but this means that first it searched through .WDL module and then tried resolve
> externals
> > with REAL DLL name (in file it is KERNEL32.DLL)
> >
> > Nic Tiger.
>
>

I have a fellow consultant who helps machine shops, labs, and processing plants with automating legacy hardware, custom data gathering, alarms, and general automation.

He uses second-hand PCs, MSDOS or freeware dos, and custom hardware. The PCs normally do only one thing, and run only one program 24h/d.

This saves his clients loads of money compared to "proper" solutions. Both in hardware and in software costs. He cites:

- Easy to find programmers
- tools and practices are well known, hence bug-free
- your program can use the machine as it wishes
- no complicated operating system issues (windows, linux)
- TTY UI is sufficient for most cases (often even no UI)
- Char based UI or TTY UI are quick and trivial to do

For the few cases he really needs a graphical ui, he programs one from scratch, often as character based -- with less work than merely using Windows widgets.

They currently use C, Pascal, ASM. They'd use Forth for some projects but it's too hard to find programmers.

----

What I think is, they should use D instead of C and Pascal. But then they'd need a dos extender, right?

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bb1sm8$c8$1@digitaldaemon.com...
> What I think is, they should use D instead of C and Pascal. But then they'd need a dos extender, right?

That's correct.

Your reasons are smart, compelling, and sensible. -Walter

BTW, your reason for not using linux was the inline assembler. I agree that the pain of converting to D for linux has the inline assembler! So is it possible that D for linux will suffice?

I would like DMC for Linux.

Anyway for current need we cannot afford developing Linux versions of our
systems because we have not enough users capable of working in Linux (esp.,
sys admins to maintain Linux network; for now they use Novell for DOS/Win32,
I doubt whether they have enough qualification to study Linux or other
*nix )

As for foreign (outside Russia) customers, we currently have no new aircrafts to sell, and all previous ones are suited well with DOSX/Win32 versions.

Though I am highly interested in moving my development to D, it is very
constrained due to missing DOSX support.
As for migrating to Linux, I am afraid to change two things at once:
Language and Platform. It would be good for me to make intermediate port of
my systems with DMC for Linux and then develop system anew in D with all
three platforms DOSX/Win32/Linux in mind.

Nic Tiger.
"Walter" <walter@digitalmars.com> wrote in message
news:bb8aft$2b8u$1@digitaldaemon.com...
> Your reasons are smart, compelling, and sensible. -Walter
>
> BTW, your reason for not using linux was the inline assembler. I agree
that
> the pain of converting to D for linux has the inline assembler! So is it possible that D for linux will suffice?
>
>

Ok, I understand where you're coming from now. -Walter