I have just got the CD and I note that there are 6 variants of the IDDE:
scw.exe
SCW32.EXE
scw32s.exe
scwmn16.exe
SCWMN32.EXE
SCWMN32S.EXE

Can someone tell me the differences?
I looked in the User's Guide and Reference (Introducing the IDDE) on the CD
and it says:
"Digital Mars C++ ships with three different integrated development and
debugging environments (IDDEs), each tailored to a specific operating system
and target. The Digital Mars C++ installer program asks you to define the
kind of programs you plan to develop, and then installs the appropriate
IDDEs on your system. ... <Text Omitted> ... Not every IDDE can debug every
kind of executable. To debug a Windows NT program, for example, you need the
full 32-bit IDDE running under Windows NT."
which seems to be incorrect, given that there is no installer.

Perhaps this section of the documentation needs to be updated, or I am missing something.

Many thanks in advance for any help.

Andrew Maclean wrote:

> I have just got the CD and I note that there are 6 variants of the IDDE:
> scw.exe
> SCW32.EXE
> scw32s.exe
> scwmn16.exe
> SCWMN32.EXE
> SCWMN32S.EXE

No, I think there are 3 variants...
scwmn16.exe -> The 16 bits IDDE.
scwmn32s.exe -> The 32 bits IDDE for Win32s
scwmn32.exe -> The 32 bits IDDE for Win32 (W95, W98, W2K, WNT, ?)

scw.exe, scw32s.exe and scw32.exe are just the startup code. I always start the 32 bits IDDE through scwmn32.exe as that allows me to start more than one IDDE at one time... <g>

> Can someone tell me the differences?

Hope above helps.

> I looked in the User's Guide and Reference (Introducing the IDDE) on the CD
> and it says:
> "Digital Mars C++ ships with three different integrated development and
> debugging environments (IDDEs), each tailored to a specific operating system
> and target.

I think that's clean now?!

> The Digital Mars C++ installer program asks you to define the
> kind of programs you plan to develop, and then installs the appropriate
> IDDEs on your system. ... <Text Omitted> ... Not every IDDE can debug every
> kind of executable. To debug a Windows NT program, for example, you need the
> full 32-bit IDDE running under Windows NT."
> which seems to be incorrect, given that there is no installer.

No, that's correct. However the Installer has been removed due to copyright reasons...

> Perhaps this section of the documentation needs to be updated, or I am missing something.

Several things needs updating all the time... We are behind in some stuff for sure...

Jan

Thanks! This makes a lot of sense now. Perhaps when you update the documentation you might like to your comments to me.

Many thanks again!


"Jan Knepper" <jan@smartsoft.cc> wrote in message news:3C0423C2.4A19EE0@smartsoft.cc...
> Andrew Maclean wrote:
>
> > I have just got the CD and I note that there are 6 variants of the IDDE:
> > scw.exe
> > SCW32.EXE
> > scw32s.exe
> > scwmn16.exe
> > SCWMN32.EXE
> > SCWMN32S.EXE
>
> No, I think there are 3 variants...
> scwmn16.exe -> The 16 bits IDDE.
> scwmn32s.exe -> The 32 bits IDDE for Win32s
> scwmn32.exe -> The 32 bits IDDE for Win32 (W95, W98, W2K, WNT, ?)
>
> scw.exe, scw32s.exe and scw32.exe are just the startup code. I always
start the
> 32 bits IDDE through scwmn32.exe as that allows me to start more than one
IDDE
> at one time... <g>
>
> > Can someone tell me the differences?
>
> Hope above helps.
>
> > I looked in the User's Guide and Reference (Introducing the IDDE) on the
CD
> > and it says:
> > "Digital Mars C++ ships with three different integrated development and
> > debugging environments (IDDEs), each tailored to a specific operating
system
> > and target.
>
> I think that's clean now?!
>
> > The Digital Mars C++ installer program asks you to define the
> > kind of programs you plan to develop, and then installs the appropriate
> > IDDEs on your system. ... <Text Omitted> ... Not every IDDE can debug
every
> > kind of executable. To debug a Windows NT program, for example, you need
the
> > full 32-bit IDDE running under Windows NT."
> > which seems to be incorrect, given that there is no installer.
>
> No, that's correct. However the Installer has been removed due to
copyright
> reasons...
>
> > Perhaps this section of the documentation needs to be updated, or I am missing something.
>
> Several things needs updating all the time... We are behind in some stuff
for
> sure...
>
> Jan
>
>

I meant "Perhaps when you update the documentation you might like to include the comments made to me in the updated documentation."!


"Andrew Maclean" <a.maclean_remove_this_@acfr.usyd.edu.au> wrote in message news:9u1ah8$24ao$1@digitaldaemon.com...
> Thanks! This makes a lot of sense now. Perhaps when you update the documentation you might like to your comments to me.
>
> Many thanks again!
>
>
> "Jan Knepper" <jan@smartsoft.cc> wrote in message news:3C0423C2.4A19EE0@smartsoft.cc...
> > Andrew Maclean wrote:
> >
> > > I have just got the CD and I note that there are 6 variants of the
IDDE:
> > > scw.exe
> > > SCW32.EXE
> > > scw32s.exe
> > > scwmn16.exe
> > > SCWMN32.EXE
> > > SCWMN32S.EXE
> >
> > No, I think there are 3 variants...
> > scwmn16.exe -> The 16 bits IDDE.
> > scwmn32s.exe -> The 32 bits IDDE for Win32s
> > scwmn32.exe -> The 32 bits IDDE for Win32 (W95, W98, W2K, WNT, ?)
> >
> > scw.exe, scw32s.exe and scw32.exe are just the startup code. I always
> start the
> > 32 bits IDDE through scwmn32.exe as that allows me to start more than
one
> IDDE
> > at one time... <g>
> >
> > > Can someone tell me the differences?
> >
> > Hope above helps.
> >
> > > I looked in the User's Guide and Reference (Introducing the IDDE) on
the
> CD
> > > and it says:
> > > "Digital Mars C++ ships with three different integrated development
and
> > > debugging environments (IDDEs), each tailored to a specific operating
> system
> > > and target.
> >
> > I think that's clean now?!
> >
> > > The Digital Mars C++ installer program asks you to define the kind of programs you plan to develop, and then installs the
appropriate
> > > IDDEs on your system. ... <Text Omitted> ... Not every IDDE can debug
> every
> > > kind of executable. To debug a Windows NT program, for example, you
need
> the
> > > full 32-bit IDDE running under Windows NT."
> > > which seems to be incorrect, given that there is no installer.
> >
> > No, that's correct. However the Installer has been removed due to
> copyright
> > reasons...
> >
> > > Perhaps this section of the documentation needs to be updated, or I am missing something.
> >
> > Several things needs updating all the time... We are behind in some
stuff
> for
> > sure...
> >
> > Jan
> >
> >
>
>

I like to start the IDDE via a short batch file presetting some environment items.  If I open a command prompt under that IDDE (which is easy to set up under the tools menu), it also inherits the environment.  Whatever else you may start with that command prompt also inherits that environment.

Walter or Jan, do you have the list of command variables to specify for passing arguments to programs called under the tools menu?  I have not seen it around.  I probably have a copy from years back laying around somewhere, but has anything regarding this been updated?

The batch file startup sounds mundane, but it can be very useful.

Starting with Windows 2000 and then with XP it got less mundane to start up by doing this.  But both OS's still support setting the environment of the called program with this method.

With XP and 2000 I suggest using "start" before the program name and using cmd.exe.  With the advent of 2000, a batch file will simply wait for a Windows program to cease execution before it executes the next line.

Hope this is useful to some folks.

Also found that some DOSX stuff can compile straight-forwardly as a CONSOLE app with the attendent flat memory model.  If it is "simple" enough.  I guess it depends on the functions and subsequently the "OS" calls you are using.  I have been working away from those asm interrupt calls that many of us grew fond of with DOS.

I am still using "int main (......" in a console app compile.   To Walter or Jan, is this bad?  I do check the std runtime library help to see if functions I use are supported under Win32.  I don't know of much that actually runs on a pure DOS machine anymore.  Windows is running.

Things have gotten quite convoluted over the past several years if you've been around long enough to really stop and think about it.

"John Lance" <JDLance@prodigy.net> wrote in message news:adpibc$2ko2$1@digitaldaemon.com...
> Walter or Jan, do you have the list of command variables to specify for passing arguments to programs called under the tools menu?  I have not
seen
> it around.  I probably have a copy from years back laying around
somewhere,
> but has anything regarding this been updated?

The ones each tool uses are under the html page for that tool.
    www.digitalmars.com/ctg/ctg/html


> I am still using "int main (......" in a console app compile.   To Walter
or
> Jan, is this bad?

No, that's how you do it.

John Lance wrote:

> I like to start the IDDE via a short batch file presetting some environment items.  If I open a command prompt under that IDDE (which is easy to set up under the tools menu), it also inherits the environment.  Whatever else you may start with that command prompt also inherits that environment.

Does the IDDE need any environment variables?
I start it without any of those and it runs fine...

Jan

The only one for the IDDE is the @P to let it know where things are at.  I don't know fully if this is still used however, but I believe that it is.  The file (sc.ini)  is still in the \Bin directory.  Same type of thing as from the older Symantec days.  The file has been considerably updated with more/different information from what was in it then.

It should be possible because of this, to have several directories of DM, with library additions/recompiles and testing all going on without affecting your main DM directories and projects.

I also set up the environment for "shelling" out to or running other programs from the IDDE, to keep things in the "work area" so to speak.

With NT, 2000, and XP, the environments can get rather large.  I usually clear out all of the unnecessary stuff.  It makes it easier to verify environment variables.  Resetting the command path to exactly what is needed is so much better than having a 1024 character (or more) command path in my opinion.  Completely resetting lib and other paths is usually a good idea too.  So many programs installed on a machine insist on setting up a path to the program's home directory as well as putting other stuff in the machines environment.  That is all well and good where it is needed.  But if I don't need it in the "work area" that I am in, I get rid of it.

I also set environment variables for the version control system I use (Burton Systems TLIB) and sometimes a separate programmer's editor, in order for them to be run "locally" with parameters specific to that work area.  It is easy to set up "work area" related information this way and then use the IDDE as the central point of focus.

I also use the cmd.exe prompt often.  I run it from the IDDE and it is dutifully placed right in the directory I am in at the moment.

The tools menu was set up pretty nicely at least as far as being flexible.  The fact that whoever did this also supplied the availability of command line arguments from the IDDE to the called program is just truly great.

My main use for C/C++ right now is in data conversion, so my requirements on the compiler/linker and programming are somewhat modest.

I am truly pleased that you folks kept the torch going for the Symantec product, now outfitted as DigitalMars.  It had, and still does have, such great potential.  Plus being fairly easy to use.  Straight-forward, fast, and flexible I believe would be good terms.

These are the command line arguments I found that can be used when setting up the tools menu:
    $D  - full directory path.
    $L  - A number, I don't know what it is for
    $M  - Project file name, no directory path.
    $P  - Full path & project file name.
    $Q  - Full path & file name of file currently being edited.
    $R  - Full path & file name of the resource file.
    $T  - The project name.

I had requested this info years ago on the old Symantec 7.50 C++ forum.  I forgot who responded with it though.

If you or Walter know of others, please let us all know.

Thanks :)