Greetings All!

I asked this once before, but many moons and many hard drive replacements later, I managed to lose the information. :-|

LOADDSKF.EXE appears to run as a native process, regardless of whether it is launched from a DOS or and OS/2 command prompt. Is it possible to duplicate this with Borland C++ 1.0? If so, how?


-Don



... Data overflow error at port 60h: Please remove cat from keyboard.
---
* Origin: EI/2 [Carleton Place, Ontario, Canada] (1:249/176)

I'm not an expert Don.

Greetings All!

I asked this once before, but many moons and many hard
drive replacements later, I managed to lose the
information. :-|

LOADDSKF.EXE appears to run as a native process,
regardless of whether it is launched from a DOS or and
OS/2 command prompt. Is it possible to duplicate this
with Borland C++ 1.0? If so, how?

Borland Turbo Pascal, I think (but do not know!), but not C++ maybe. Maybe that too .. read on.

There are a class of programs that are what I think are called Family programs.
They will operate in more than one platform. Indeed LOADDSKF.EXE is one of them. Another one is the little AEDIT.EXE which works under DOS,WIN, and OS/2 as well in 'native' mode. Let's examine that thought a moment based on what I've researched.

You may or may not have a copy of the old Microsoft PD7 Developer's kit and the
PD-7 compiler. While it would generate code that will work under OS/2 and DOS that's a 16 bit executable only, if my memory of actually doing it is correct.
As well, there has been a utilty around for use with the Borland PASCAL compiler for OS/2 and DOS. It will let you combine the executables for DOS and
OS/2 into one much larger .EXE file. From my research, it is really a switcher. At load time, it decides that you are executing in DOS or OS/2, then
switches to the executable part of the code which is appropriate for either platform.

The older ALLFIX BBS program was written in this style. You could get it as a DOS version. You could get it as an OS/2 native version, or .. You could get it as a UNIVERSAL version which I have. In this case, the .EXE file for each of the programs is rather much larger. You only have one .EXE file on the disk, It works for both platforms as needed. The operation is, like in LOADDSKF.EXE, transparent to the user.

However that toolset which let you do this for Borland PASCAL, if my information is correct, is confined to, again 16 bit native OS/2 programs. It does not extend to 32 Bit PM style operations. Thus its usefulness in the modern GUI world is limited, one would think.

If you think about it, the technique of crafting multi-platform .EXE programs is thus, it seems, a matter of switching at load time, I think I now understand
from the research I did. The author of the tool for the UNIVERSAL deal made the statement in his DOCS, that any program written for OS/2 is really easy to convert to run in any other platform if you really want to do it.

So I querried him about that issue and use for more than the two that were offered and source variations on the theme. He never answered me. Pity.

His web site is now still there, but it is a FAX number and also the only way you get to ask questions is to first, it seems let them charge your VISA or MASTER card for $150 and they send you the tools. I've tried calling the voice
phone number off and on, but all I get is a FAX machine or a MODEM and not into
anything. The outfit still offers or still did offer consulting services for multi-platform switched executables if you want .. But ..

I was going forward on this until I got a note from Dale Barnes who is now the holder of both Intermail and Allfix. He said he was having trouble with the toolset in the OS/2 port off Intermail and that Intermail would likely only be available as a separate DOS and OS/2 version when the new OS/2 version is available. I've got an invite to have dinner with him in Houston the next time
I go down there and Houston is on my trip list about every two weeks or month or so. I intend to discuss the matter with him when I go.

Personally, I want a combined executable which runs unter native OS/2 or WIN or
LINUX as a single distributed .EXE program. What I'd LOVE to do his have that from PowerBASIC source via the PB/CC compiler which is soon to be available for
LINUX, it seems.

I know more than you is interested in multi-platform!

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001




--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Hi Don,

Replying to a message of Don Guy to All:

LOADDSKF.EXE appears to run as a native process, regardless of whether
it is launched from a DOS or and OS/2 command prompt. Is it possible
to duplicate this with Borland C++ 1.0?

Yes, after a fashion. You will need a separate compiler for the DOS part. Borland C/C++ 3.1 or Turbo C 3.x will do.

If so, how?

Let's assume your program is called PROG1 and its source is in PROG1.C

Compile your program PROG1.C for DOS using a DOS C/C++ compiler, and call it, say, PROG1D.EXE; you can link it initially as PROG1.EXE and rename it when the build is finished.

Create a module definition file named PROG1.DEF that includes the statement STUB PROG1D.EXE. Finally, compile your program using Borland for OS/2 and the module definition file for the link step.

The effect is to produce a .EXE file with 2 complete executables in it: a 16-bit, real-mode DOS version; and a 32-bit, protected-mode OS/2 version. The DOS loader will not see the OS/2 program, and the OS/2 loader will skip over the DOS program.

This approach is less than ideal, compared to using FAPI and the DOS-OS/2 binder. But you will need the old 16-bit OS/2 DTK for that, and a compiler that
can produce suitable object code (MS C 5.x/6.x and Watcom C/C++ spring to mind).

It can be a lot simpler if you use the EMX compiler and the RSX DPMI extender. This will give you 32-bit code in DOS, as well as OS/2. The code segments will largely be shared. See my message to Igor Kovac on where to obtain these tools.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

LOADDSKF.EXE appears to run as a native process, regardless of whether
it is launched from a DOS or and OS/2 command prompt. Is it possible
to duplicate this with Borland C++ 1.0?

Yes, in two ways:

The first requires the OS/2 1.x Developers' Toolkit (as I recall). You BIND a DOS stub loader program and family API library onto the OS/2 program. The stub
loader program, when executed, loads the executable proper into memory, binding
the calls to the OS/2 system API to the family API library, which translates them into DOS system API calls.

The second involves linking two separate programs, one for DOS and one for OS/2, and using the former as the stub executable in the latter.

In either case you'll need a replacement for Borland's C library, of course. You won't be able to use the one that Borland supplies, since that uses the DOS
system API and not the Family API. Many years ago, because I didn't have the OS/2 1.x Developers' Toolkit, I wrote a replacement 16-bit library that used the Family API, which I used, in combination with Borland C++ 3.x for DOS and a
Family API to DOS API shim library that I wrote, to create version 1.0 of my Command Line Utilites. I never released the C library to the general public, because Borland came out with a proper 32-bit Borland C++ for OS/2 and it was no longer worth the time and the effort to do so. (I did release the Family API library that I wrote.)

Why do you want to create a bound executable anyway ? I urge you to not encourage the continued use of DOS by making more DOS programs. Encourage the use of OS/2 instead. Make a native OS/2 program and have done with it.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

Hi Jonathan,

On 13-Sep-01, Jonathan de Boyne Pollard wrote to Don Guy:

LOADDSKF.EXE appears to run as a native process, regardless of
whether it is launched from a DOS or and OS/2 command prompt. Is
it possible to duplicate this with Borland C++ 1.0?

JdBP> Yes, in two ways:

No, you can't - as asked! You can however use BC 3.1 for the DOS part
and BCOS/2 for the OS/2 part under your option two.

JdBP> The first requires the OS/2 1.x Developers' Toolkit (as I
JdBP> recall). You BIND a DOS stub loader program and family API
JdBP> library onto the OS/2 program. The stub loader program, when
JdBP> executed, loads the executable proper into memory, binding the
JdBP> calls to the OS/2 system API to the family API library, which
JdBP> translates them into DOS system API calls

LOADDSLF doesn't use this method.

JdBP> The second involves linking two separate programs, one for DOS
JdBP> and one for OS/2, and using the former as the stub executable in
JdBP> the latter

This is the way LOADDSKF works. It has totally separate executables
for DOS and OS/2.

JdBP> In either case you'll need a replacement for Borland's C
JdBP> library, of course. You won't be able to use the one that
JdBP> Borland supplies, since that uses the DOS system API and not the
JdBP> Family API. Many years ago, because I didn't have the OS/2 1.x
JdBP> Developers' Toolkit, I wrote a replacement 16-bit library that
JdBP> used the Family API, which I used, in combination with Borland
JdBP> C++ 3.x for DOS and a Family API to DOS API shim library that I
JdBP> wrote, to create version 1.0 of my Command Line Utilites. I
JdBP> never released the C library to the general public, because
JdBP> Borland came out with a proper 32-bit Borland C++ for OS/2 and
JdBP> it was no longer worth the time and the effort to do so. (I did
JdBP> release the Family API library that I wrote.)

No, for the second method you need the two compilers, 16 bit DOS and
32 bit OS/2, you only need your method for using a 16 bit DOS compiler
to produce native OS/2 .EXE files.

JdBP> Why do you want to create a bound executable anyway ? I urge
JdBP> you to not encourage the continued use of DOS by making more DOS
JdBP> programs. Encourage the use of OS/2 instead. Make a native
JdBP> OS/2 program and have done with it

Good question... :-)

George

--- Terminate 5.00/Pro
* Origin: A country point under OS/2 (2:257/609.6)

LOADDSKF.EXE appears to run as a native process, regardless of
whether it is launched from a DOS or and OS/2 command prompt. Is it
possible to duplicate this with Borland C++ 1.0?

JdBP>> Yes, in two ways:

No, you can't - as asked! You can however use BC 3.1 for the DOS part
and BCOS/2 for the OS/2 part under your option two.

Yes one can. One can use BC/DOS for both the DOS and OS/2 executables. That's
exactly how I created version 1.0 of my Command Line Utilities, after all. But
just as I don't think people should be writing new DOS programs these days, I don't think that people should be writing new 16-bit OS/2 version 1.x programs these days either. If one is going to write a new program, one might as well write a Pure 32-bit OS/2 program right from the start.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

Greetings Ian!

A long time ago, in a galaxy far, far away, a coded message from Ian Moote to DON GUY was intercepted...

Hi, Don! This is on my "things to try" list, but as I haven't yet had
need for such a program I haven't actually tried it for myself.

Same here, that's why I'm looking into it. I don't really *need* to create a multi-platform EXE, I just want to see if I *can*. :-)

I think that I saw it in my Borland C for OS/2 package, but I'm sure
that I've got a copy of Bind around here somewhere.

Not with the distribution of 1.0 that I have...

I quick search found a copy on the Internet at ftp://ftp.nfbnet.org/bbsfiles/os2-prog/FAMAPI.ZIP.

In the queue--thanks.

-Don



... ERROR: something went wrong
---
* Origin: EI/2 [Carleton Place, Ontario, Canada] (1:249/176)

Greetings David!

A long time ago, in a galaxy far, far away, a coded message from David Noon to Don Guy was intercepted...

Create a module definition file named PROG1.DEF that includes the statement STUB PROG1D.EXE. Finally, compile your program using
Borland for OS/2 and the module definition file for the link step.

I gave it a shot just now, but something must be a bit off--the console output is garbled when the final product is run from a DOS window.


-Don



... Network management is like trying to herd cats...
---
* Origin: EI/2 [Carleton Place, Ontario, Canada] (1:249/176)

Hi Don,

Replying to a message of Don Guy to David Noon:

Create a module definition file named PROG1.DEF that includes the
statement STUB PROG1D.EXE. Finally, compile your program using
Borland for OS/2 and the module definition file for the link step.

I gave it a shot just now, but something must be a bit off--the
console output is garbled when the final product is run from a DOS
window.

Have you run your DOS code all by itself (i.e. before linking it to the OS/2 code) in a window?

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Greetings Jonathan!

A long time ago, in a galaxy far, far away, a coded message from Jonathan de
Boyne Pollard to Don Guy was intercepted...

JdBP> Why do you want to create a bound executable anyway ?

Simply because the potential to do so exists.

JdBP> I urge you to not encourage the continued use of DOS by making more
JdBP> DOS programs.

While I prefer OS/2 over the alternatives, I'm not about to ignore the needs of
those who choose alternate operating systems.

-Don



... How do I set my laser printer on stun?
---
* Origin: EI/2 [Carleton Place, Ontario, Canada] (1:249/176)

Don ..

JdBP> I urge you to not encourage the continued use
of DOS by making more
JdBP> DOS programs.

While I prefer OS/2 over the alternatives, I'm not
about to ignore the needs of those who choose
alternate operating systems.

-Don

I was floored by one major embedded systtem poster in the PowerBASIC forums on their web BBS! They noted that by far the largest growth in their commercial programs was in pure DOS! That for elevaators, industrial equipment operataions, vending machines and what not. The systems growth in these embedded systems is, per their account phenomenal!

Of course that might not be OS/2 relevant, if it weren't for the fact that OS2's DOS-VDM's make superb development platforms for DOS!

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001




--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Greetings David!

A long time ago, in a galaxy far, far away, a coded message from David Noon to Don Guy was intercepted...

I gave it a shot just now, but something must be a bit off--the
console output is garbled when the final product is run from a DOS
window.

Have you run your DOS code all by itself (i.e. before linking it to
the OS/2 code) in a window?

Aye, and it behaves properly. Are there any tricks to module definition files that I should know about?

-Don



... TWAIN: Toolkit Without an Interesting Name
---
* Origin: EI/2 [Carleton Place, Ontario, Canada] (1:249/176)

Hi Don,

Replying to a message of Don Guy to David Noon:

I gave it a shot just now, but something must be a bit off--the
console output is garbled when the final product is run from a DOS
window.

Have you run your DOS code all by itself (i.e. before linking it to
the OS/2 code) in a window?

Aye, and it behaves properly. Are there any tricks to module
definition files that I should know about?

Shouldn't be any trick required.

Can you zip up your project files and e-mail them to me at dwnoon@os2bbs.com? I
have BCOS/2 2.0 installed and a variety of DOS-based C/C++ compilers. I will see what I can make of it.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Hi Ian,

Replying to a message of Ian Moote to DON GUY:

I looked around for Bind on my system but could not find it. I think
that I saw it in my Borland C for OS/2 package, but I'm sure that
I've got a copy of Bind around here somewhere.

The BIND.EXE program and the BINDINGS.LIB library are part of OS/2 Developer's Toolkit 1.3, which was on the Dev Con CD's about 6 or 7 years ago. This DTK shipped as a bunch of floppy disk image (.DSK) files. There was also a fixpak for it on the same CD.

If you have some old Dev Con CD's take a look there.

There was also a MS version of this 16-bit DTK, and this was supplied with MS C
6.x, MS FORTRAN 5.x and MASM 5.x/6.0. So, if you have a copy of MASM from that time it will also have the binder, and Programmer's WorkBench will run it automatically if you specify a bound executable as the target.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)