Re: Help with text adventure

See below...
On Thu, 7 Aug 2008 07:11:14 -0700 (PDT), stalepie <uhhhhhhhhhhhhhh@xxxxxxxxx> wrote:

On Aug 7, 9:55 am, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:
I'm not sure why you say you "don't want to use Visual Studio".  News flash: this is the
basic programming tool for Windows.  There is even a express version (although it doesn't
have MFC) which is free.  You can do raw Win32 programming and do everything I suggested,
it is just less convenient.

You can also just write a console app with printf and getline, as an extreme case.
                                        joe


Is there a way to make a Win32 console application?

I'm not sure I know the right language to use to describe what I want.
Basically I want a program that is all text, like ASCII text, you
know, and the background is blakc, and the text is white, and there's
no menus, and it's full screen, and basically it looks like a DOS
application, except the resolution may be higher or kept the same as
whatever the user's current resolution is, and it's a Win32 app rather
than DOS, because I don't want to try to make people run a DOS program
on XP, Vista, etc in this day and age, and if I did I would just
include DOSbox with the program and a batch file to make it run with
DOSBox, but that seems kind of ridiculous because it's the year 2008.
****
Yes. WHen asked what kind of project you want to create, select "Win32 Console
Application".

When you launch it, it runs with a console window.

I have no idea what a "DOS" app is.

But you are asking for contradictory things. You say "I don't want to make people run a
DOS program" (whatever that means) but you say "I want a WIn32 app".

A console app is a native 32-bit application. It runs in a console window. It interacts
with the user with operations like getline and printf. It is a pure text application,
nothing more, nothing less.

You create these using Visual Studio. Since you don't want or need MFC, you could use the
free "Express" edition. I don't know what a "DOSbox" is, and it is certainly nothing you
would ever include in anything you sent to a user under ANY imaginable scenario.
****
So can I just use the C language and Notepad and then with a C
compiler make a win32 app that runs in full screen like this?
****
Notepad as an editor sucks. And I mean REALLY sucks; compared to it, the VS editor (which
also sucks) is simply AMAZINGLY GOOD. You would never want to use it for programming,
especially because there are dozens of perfectly good and completely free editors out
there already. GNU EMACS, vim, etc. are all out there.

To get it to run full-screen you mark its shortcut icon to launch it full-screen. This
has nothing to do with how it is created
*****
Or is it
that people normally learn with Visual Studio and they use the pull-
down menus to add-in code chunks and stuff, and they can't really
program without using the IDE?
****
You can, but why would you want to?

What does programming in the IDE have to do with the kind of program you are developing?
YOu can develop a console app using the IDE development environment; its *just another
program* you are creating!
****
I'll try the IDE, I'll try the Express
version in a minute. Yesterday as I said I was having trouble
downloading it. It was taking a while and seemed to be freezing during
the download/install process. Still, it seems like a lot to download
just to do the kind of simple application I'm talking about. It may be
wiser for me to do this in QuickBASIC using DOSBox and then port it to
Win32 using FreeBASIC, even though that's not supposed to be a very
good program in comparison to PowerBASIC.
****
QuickBasic really sucks. If you want to use Basic, this is not the forum to ask questions
on; this is an MFC newsgroup.

Saying you will do it in QuickBasic or DirectX is like saying "I want to build a house, so
I will either use submarine sandwiches or a space shuttle to accomplish this". The words
have no connection with most forms of reality. Since you are doing something that is
text-based, using a high-performance 3D graphics package or an obsolete 16-bit development
left over from the days when we carved programs into rocks with bronze chisels doesn't
seem to make sense.
****
I suppose it doesn't make
sense to use GDI or GDI+, but I thought that was what handled the
windowing process of Windows, like it was behind any Windows program.
I guess it makes more sense to go with DirectX, but again, why learn
all that directx stuff when I just want to make the equivalent of a
console app?
****
I agree.

What I don't understand is why you start talking about GDI+ and DirectX as if these have
any relevance to a console app. Or a WIndows GUI app? You can write lots of interesting
stuff without once referring to anything in DirectX (which is mostly used for
high-performance and 3-D graphics) or GDI+ (which is used for very sophisticated image
processing, or to get very nice high-level interfaces to the low-level graphics). But
graphics are completely irrelevant to what you are trying to do, and so worrying about
them seems pointless.
****
It was annoying to me, though, running QuickBASIC in XP,
without DOSBox,
****
I don't even understand this sentence. If you run a 16-bit console program, it runs under
NTVDM because ALL 16-bit apps have to run under NTVDM. Since I don't know what a DOSbox
is, I can't figure out what you are talking about.

****
because it ran that Virtual DOS Machine program in the
background (ntvdm.exe)
****
Virtual DOS machines are yet something else again, and they are used to run native Win16
programs. But unless you find a copy of Visual Studio 1.52c somewhere, the chances that
NTVDM will be relevant to anything you do is precisely zero. And in any case, the NTVDM
is built-in to Windows and would not be something you "redistributed"; it is an inherent
part of all 32-bit operating systems (it is gone in 64-bit systems because the 64-bit
hardware cannot support 16-bit execution). NTVDM does not run "in the background", and
I'm not sure how you came up with that idea, but it ain't so.
****
and my little laptop here was like "wft?!" and
the fan kept whirring because it was using up so many CPU cycles.
****
I don't even understand how running a program can cause the fan to run; I don't get any
difference in the fan performance when I run intense compute-bound algorithms for hours.
Ambient temperature has a bigger impact.

I still run some 16-bit apps in XP, and there does not seem to be any problem. I don't
know what you mean "using up so many CPU cycles". Did you run Task Manager and look at
the percentage of the CPU that was being used? What numbers did you see?
****
I found that really lame that Windows doesn't come with a DOS emulator
that's any good.
****
And it's my turn to say "wtf?" I don't even know what you are talking about here. NTVDM
is a 16-bit MS-DOS emulator, but how do you determine "goodness"? What criterion did you
apply to determine it is "not good"?

Anyway, as I said I'll probably just do this in
QuickBASIC and/or DirectX (using C or C++). I'll try the VS Express
thing, but it's probably some 700MB program that makes 800kb-size
"hello world" programs...
****
How in the world have you determined that a "hello world" program takes 800K? What tool
did you use to determine this? Why do you think the measure of a trivial program has
ANYTHING TO DO WITH ANY FORM OF REALITY THAT EXISTS? This kind of comparison is what I
call "childish concerns with irrelevant details that have no meaning"; generally, you have
no idea what is going on in the tools or what they are reporting, or why, and the
mythology of "giant" programs that are "bigger" than Unix or DOS or Basic or whatever,
persists. But if you measure what is REALLY going on, you realize that you are not doing
valid comparisons. For example, the MFC library is gigantic, but since it makes no sense
to use MFC to write a one-line console app, why in the world would anyone thing the
comparison is meaningful? If I write a 20,000-line program, MFC saves me from having to
write, instead, a 100,000-line program because it provides all the code I would have had
to write otherwise.

That's what's called "cost-effective".

A bicycle is cost-effective if you have a daily commute of two miles in a climate with
good weather; it is not a cost-effective solution if your job is to move 30 to 40 tons of
rock in a day. So if you select a task that is a bicycle task and complain that your dump
truck only gets 6 miles to the gallon, you sound silly. But in the real world, we
typically need to move tons of rock, thousands of gallons of oil, millions of cubic feet
of natural gas, thousands of gallons of milk, a household's worth of furniture. These are
not bicycle tasks. That's what MFC is designed for, and if you think measuring the size
of "hello world" is meaningful, you need to get a calibration on life. NOBODY cares how
large a "hello world" program is because we don't write one-line programs in the real
world. Yet there is a childish subculture that thinks this is somehow a metric of the
"goodness" of some system, and that's the only word I can use to describe this subculture.
*I* want a system that I can use to write 200 lines per hour of complex and sophisticated
code (I wrote 3000 lines over the last couple days and I couldn't have done anything that
complex in Basic; I spent perhaps 15 hours at most on the project; most of the code was
written by Microsoft, and they call it "MFC". Those 3000 lines do REAL WORK, as opposed
to meaningless overhead that MFC already does for me. You'll see the finished code posted
in a few weeks when I return from teaching and vacation and have a chance to write up the
essay; essentially, it parses a structured binary file containing recursive structures and
builds a tree representation of the data in the file; when I'm done, I hope to have XML
import-export capabilities as well. Do THAT in Basic with NotePad!)

For $13, you can get a DDK disk shipped to you, which has a C/C++ compiler; you can
download WinDbg free, and you can get a decent editor most anywhere for free. Of course,
you now have a 1987 development environment, but if you don't mind working in an
environment that is 20 years obsolete it is viable. I was productive in 1987 using this
kind of environment and made good money doing it (today, I am considerably more
productive, and actually earning less because I can finish projects in fewer hours)
joe
****

.

Relevant Pages

  • Re: GUI programming, MFC and C#
    ... iterations of a product called Windows that didn't take off until Windows ... VB presented millions of folks with a way to develop GUI ... Microsoft added visual designers to C++ through Visual Studio using MFC. ... Depending on the size of your app, you could go one of two ways or ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Win32 TSR program skeleton
    ... under windows a "comsole" is just a thing used for display. ... are not avaible to Win32 apps, and are not created for Win32 console ... I need to write a TSR that does some periodical checks over another ... You should say that I can simple pipe the output to my app, but, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Is VS2008 a good environment?
    ... Upon programming VS2008 using win32 and C++, I find that it is not ... Every windows app needs to process messages, ... Which takes care of the "Make Windows programming OOP" ...
    (microsoft.public.win32.programmer.ui)
  • Re: Title bar in Doc/View application
    ... While it's true that MFC isn't portable, ... Any app that uses MFC/Win32 is not portable anyway. ... and I'm only interested if it works on Windows anyway. ... Maybe MAC. ...
    (microsoft.public.vc.mfc)
  • Re: edit box population in a dialog box
    ... I all ready have a version of this written using MFC. ... and my MFC app is 33k. ... Windows doesn't have the equivalent of ksh. ... works better for me on *BSD. ...
    (microsoft.public.win32.programmer.gdi)
Loading