DOS to Windows

[Stan Weiss]

I have a program writeen in Microsoft QC 2.5 for DOS which has a very
simple interface of using printf and sscanf also gets and puts. Is there
an easy way to convert this to Window?
Thanks
Stan

 

[dandelion]

I have a program writeen in Microsoft QC 2.5 for DOS which has a very
simple interface of using printf and sscanf also gets and puts. Is there
an easy way to convert this to Window?

Of topic of course, but you could just run it in a DOS window...

 

[Joona I Palaste]

I have a program writeen in Microsoft QC 2.5 for DOS which has a very
simple interface of using printf and sscanf also gets and puts. Is there
an easy way to convert this to Window?

Try using the exact same source code. The functions printf, sscanf, gets
and puts are portable across all implementations.
However please note that the function gets is broken as designed. It is
considered impossible to use safely. You may wish to use fgets instead.

 

[Stan Weiss]

I do this now under Win 98SE and W2K but I have been told that it will
not run on XP. I do not have XP and was just looking to upgrade it. I
have Visual Studio 6 with SP5 and have only been using VB, so now was
look to move to VC++.
Stan

 

[dandelion]

I do this now under Win 98SE and W2K but I have been told that it will
not run on XP.

Huh? Why not?

I do not have XP and was just looking to upgrade it. I
have Visual Studio 6 with SP5 and have only been using VB, so now was
look to move to VC++.

From VB that's a good move. Sorry I cannot help you, but my expirience with
Windows (programminG) is not as extensive as the experts of a dedicated
news-group.

I suggest you try there to get expert advice.

 

[Kenny McCormack]

Huh? Why not?

It works. Despite what you may have heard, XP does have a "Command Prompt".

In their eternal wisdom, Microsoft keeps trying to scare people into
thinking that the "Command Prompt" (aka, "DOS Window") is going to go away
at some point, and has even managed to convince some people that it *has*
gone away in XP, but such claims are BS.

Note: It *might* be the case that some installations of XP have disabled
the ability to "shell out" (I've heard rumors to this effect - that you can
configure XP this way, but I've never seen an actual instance of it), but
even then, you should be able to run your program (i.e., the CMD.EXE is
still there, but is somehow made inaccessible to the casual user).

(All O/T, of course)

 

[Joona I Palaste]

It works. Despite what you may have heard, XP does have a "Command Prompt".

In their eternal wisdom, Microsoft keeps trying to scare people into
thinking that the "Command Prompt" (aka, "DOS Window") is going to go away
at some point, and has even managed to convince some people that it *has*
gone away in XP, but such claims are BS.

Note: It *might* be the case that some installations of XP have disabled
the ability to "shell out" (I've heard rumors to this effect - that you can
configure XP this way, but I've never seen an actual instance of it), but
even then, you should be able to run your program (i.e., the CMD.EXE is
still there, but is somehow made inaccessible to the casual user).

(All O/T, of course)

Note that ever since Windows NT, Windows doesn't have an underlying DOS
installation any more. On the contrary, Windows is the underlying
installation, and an *emulation* of DOS runs over it. For ISO standard C
programs, there won't be any difference, but attempts to use
DOS-specific features (such as bitmap graphics) might not work, or might
even crash the computer.

 

[Raymond Martineau]

Note that ever since Windows NT, Windows doesn't have an underlying DOS
installation any more. On the contrary, Windows is the underlying
installation, and an *emulation* of DOS runs over it.

This is generally correct. There are some cases where the emulation is not
correct such as with sound cards, but that's another story.

For ISO standard C
programs, there won't be any difference, but attempts to use
DOS-specific features (such as bitmap graphics) might not work, or might
even crash the computer.

Dos specific features work perfectly under Windows 95 and NT. Windows XP
supports the standard VGA and VESA graphics modes without problem (although
require the program to be run full-screen). The only two things which I
know don't work under Windows would be Soundblaster emulation (and a
3rd-party fixed that), and high-resolution timers used to emulate
high-quality sound on the PC speaker.

The only significant implementation difference between Dos and Windows
would be differences in using malloc() and accessing memory just outside of
the allocated memory. This enters the realm of undefiend behaviour, but is
only important if you wonder why your program only crashes in one of the
two settings.

 

[Eric Sosman]

[...] This enters the realm of undefiend behaviour, [...]

What a serendipitous spelling error! We have at last
learned what sort of demons inhabit the nasal passages:
they are the undefiends!

 

[Mark McIntyre]

I do this now under Win 98SE and W2K but I have been told that it will
not run on XP.

Then you were almost certainly misinformed - if anything, XP is more
tolerant of 16-bit apps than W2K, and it even has a Win98 compatability
mode to help you further (I run several of my kids' games in this mode,
works a treat).

But this is offtopic here, and you will get authorative answers in one of
the MS groups so please ask there.

 

[Mark McIntyre]

On Mon, 08 Nov 2004 17:38:29 GMT, in comp.lang.c ,

Note: It *might* be the case that some installations of XP have disabled
the ability to "shell out" (I've heard rumors to this effect - that you can
configure XP this way, but I've never seen an actual instance of it),

Security policy.

but
even then, you should be able to run your program (i.e., the CMD.EXE is
still there, but is somehow made inaccessible to the casual user).

Nope, totally inaccessible.

 

[Neil Kurzman]

Try using the exact same source code. The functions printf, sscanf, gets
and puts are portable across all implementations.
However please note that the function gets is broken as designed. It is
considered impossible to use safely. You may wish to use fgets instead.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"To err is human. To really louse things up takes a computer."
- Anon

You would of course make it a console application.

 

[Richard Bos]

On Mon, 08 Nov 2004 17:38:29 GMT, in comp.lang.c ,


Security policy.

Myeah, but that's not XP's fault. The DOS box _is_ there, but it's
possible for the sysadmin to disable it. This is actually quite a useful
feature - can _you_ trust (all) your users with a DOS prompt?

Richard

 

[Thomas Stegen]

[...] This enters the realm of undefiend behaviour, [...]

What a serendipitous spelling error! We have at last
learned what sort of demons inhabit the nasal passages:
they are the undefiends!

Class! Uh, I mean, Struct!

 

[Stan Weiss]

First I would like to Thank every one who has responded. I do not have
XP but the person who said it did not work did have a DOS window. From
what he said it looks like the program stopped at about the point it
would have run a time function.
Stan

 

[Richard Bos]

First I would like to Thank every one who has responded. I do not have
XP but the person who said it did not work did have a DOS window. From
what he said it looks like the program stopped at about the point it
would have run a time function.

Then converting to using Windows-specific output functions isn't likely
to solve the problem, is it?
Maybe your use of the time functions isn't conforming, and invokes UB.
What function would've been called, and how do you call it?

Richard

 

[Stan Weiss]

It was a couple of years ago that this happened and based on his emails
believe it happened when I called this function.

void sleep( int n)
{
timeval = time(NULL);
while ( time(NULL) < timeval + n);
}

 

[Mark McIntyre]

On Mon, 08 Nov 2004 17:38:29 GMT, in comp.lang.c ,


Security policy.

Myeah, but that's not XP's fault. The DOS box _is_ there, but it's
possible for the sysadmin to disable it. This is actually quite a useful
feature - can _you_ trust (all) your users with a DOS prompt?[/QUOTE]

If I had my way, when some of my users tried to open a dos prompt, a black
light would light up in black on a black background to tell them not to
click that button again. And then send 20 KV through the mouse, "pour
encourager les autres".

Sorry, I'm training for my BOFH exam...

 

[Michael Mair]

Stan Weiss wrote:

[repaired order]

Then converting to using Windows-specific output functions isn't likely
to solve the problem, is it?
Maybe your use of the time functions isn't conforming, and invokes UB.
What function would've been called, and how do you call it?

Richard

[/repaired order]

It was a couple of years ago that this happened and based on his emails
believe it happened when I called this function.

void sleep( int n)
{
timeval = time(NULL);
while ( time(NULL) < timeval + n);
}

yuck! Make this

#include <time.h>

void sleep (int n)
{
time_t reftime = time(NULL);
while (difftime(time(NULL),reftime)<(double) n);
}

(untested). time_t is not necessarily an integer type.
However, there hopefully are better ways of achieving this
than polling.


Please do not top-post.


Cheers
Michael

 

[Allin Cottrell]

FWIW, that is not a DOS box or DOS prompt. DOS has nothing to do with
it; it's a win32 console window.

Also FWIW, most Windows users are perectly capable of screwing up
their systems with or without the help of the command prompt in
a console window.

Allin Cottrell