[comp.windows.ms.programmer] How can I get BCX to work inside of Windows?

LIBCRN@BYUVM.BITNET (03/08/91)

   I am trying to get the extended version of Borland's IDE (BCX.EXE)
to work from within Windows.  I have set up a .PIF file for this
purpose which specifies that BCX is to be given 800 Kbytes of extended
memory to work with (XMS does stand for extended memory, doesn't it?).
Unfortunately, when I invoke BCX, I always get an error message that
says that 0 Kbytes of extended memory is available when 706 Kbytes is
needed.  Is is possible to get BCX to work from within Windows?  BCX
works great outside of Windows but it is a REAL pain to have to get
out of Windows every time you want to recompile a program.

   To illustrate why I would rather use BCX.EXE instead of BC.EXE, here
are two comparisons of compile-and-link times between BCX and BC.  The
two programs are very simple.

PARTY.C      (from Petzold's book)
        BC   --  5.5 minutes.
        BCX  --  16 seconds.

WHELLO.CPP   (one of the example programs that comes with BC++)
        BC   --  8 minutes  (thats right EIGHT MINUTES !)
        BCX  --  40 seconds.


   My Hardware:  IBM PS/2  Model 55sx    with   4 Mbytes RAM.

Thanks for any help.

-- Cory  (libcrn@byuvm.bitnet)

dave@interlan.Interlan.COM (Dave Goldblatt) (03/08/91)

The question was asked as to how to get BCX to work under Windows.

The answer: You can't.

The reason: BCX (and BCCX) incorporate built-in DOS extenders.  Said DOS
extenders are VCPI-compliant.  Windows is DPMI-compliant.  The two are
mutually exclusive.  Because BC[C]X is VCPI-compliant, however, it will
run under QEMM and the like.  Just now Windows.

TASM 2.5 _is_ DPMI-compliant, however, and will run just fine under Windows.

DPMI support will be forthcoming; however, it was not deemed necessary at
release time (according to the reports I've seen; I very much agree with
that assessment -- No matter what, compiling under Windows will be slower
that compiling under DOS).

To speed up BC's operation under Windows, set up a PIF file allocating
lots of _expanded_ memory, and have BC run with the /e switch (to use
expanded memory).  That should speed up its operation significantly.

Overall, though, I think you'd be better served by compiling under DOS;
it will be _much_ faster.

-dg-

--
 "Hey, Copperfield!  		*	Dave Goldblatt	[dave@interlan.com]
   Suck on this!"		*	
     - Penn Jillette, of	*	(No longer working for, and certainly
	Penn & Teller          	*	 not representing, Racal InterLan)

tmkk@uiuc.edu (Scott Coleman) (03/08/91)

In article <DAVE.91Mar7234444@slam.InterLan.COM> dave@interlan.Interlan.COM (Dave Goldblatt) writes:
>
>The question was asked as to how to get BCX to work under Windows.
>
>The answer: You can't.

Wow, really? Guess I'll have to run right home and delete all that stuff
from my Development .GRP ;-)

Seriously, you most certainly CAN run BCX under Windows. Follow this
procedure (which is outlined somewhere in the manuals, but I've
forgotten exactly where):

1. Run TKERNEL.EXE from DOS before starting windows.

2. Start windows in either Standard or Real mode. Note: Your statement
above is correct *only* if you add the words "in 386 Enhanced mode."

3. Start BCX from the Program manager as you normally would.

Works just fine for me.

As to why you would want to run BCX from within Windows, I don't know
about you, but I often need to switch quickly from "edit the source
code" mode to "run the program" mode, and starting/exiting Windows
every time gets to be a REAL drag.

jarober@aplcen.apl.jhu.edu (DE Robertson james an 740-9172) (03/08/91)

dave@interlan.Interlan.COM (Dave Goldblatt) writes:


>The question was asked as to how to get BCX to work under Windows.

>The answer: You can't.

>The reason: BCX (and BCCX) incorporate built-in DOS extenders.  Said DOS
>extenders are VCPI-compliant.  Windows is DPMI-compliant.  The two are
>mutually exclusive.  Because BC[C]X is VCPI-compliant, however, it will
>run under QEMM and the like.  Just now Windows.

Not that I've tried it yet, but this is what TFM says about it:

"You can use the protected mode version of the IDE while running Windows. To
do so, first load TKERNEL.EXE with the command:
	TKERNEL hi=yes kilos=nnnn

where nnnn is the number of Kbytes to be managed by the kernel. We suggest 
kilos=2048. The remaining extended memory is available for Windows and other
programs. Then run Windows in standard mode (type the command WIN /s). With
Windows in standard mode, you can't run the IDE in a virtualized DOS window,
but only as a full screen.

You can run the protected mode IDE in Windows in standard or real mode, not
in enhanced mode"

	The above is quoted verbatim from pg. 5, USERS GUIDE. So yes,
it can be run in Windows so long as the proper steps are taken ahead of
time. Hope this helps.


Jim Robertson


--
Jim Robertson,   INET: jarober@warper.jhuapl.edu, jarober@aplcen.apl.jhu.edu
Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcen!jarober

LIBCRN@BYUVM.BITNET (03/08/91)

=========================================================================
>The question was asked as to how to get BCX to work under Windows.

>The answer: You can't.

>The reason: BCX (and BCCX) incorporate built-in DOS extenders.  Said DOS
>extenders are VCPI-compliant.  Windows is DPMI-compliant.  The two are
>mutually exclusive.  Because BC[C]X is VCPI-compliant, however, it will
>run under QEMM and the like.  Just now Windows.

>TASM 2.5 _is_ DPMI-compliant, however, and will run just fine under Windows.

>DPMI support will be forthcoming; however, it was not deemed necessary at
>release time (according to the reports I've seen; I very much agree with
>that assessment -- No matter what, compiling under Windows will be slower
>that compiling under DOS).

>To speed up BC's operation under Windows, set up a PIF file allocating
>lots of _expanded_ memory, and have BC run with the /e switch (to use
>expanded memory).  That should speed up its operation significantly.

>Overall, though, I think you'd be better served by compiling under DOS;
>it will be _much_ faster.

>-dg-

>--
> "Hey, Copperfield!             *       Dave Goldblatt  [dave@interlan.com]


   Well that's not entirely true (that you can't run BCX under Windows).
If I wasn't such an idiot, I would have found the answer myself in the
manuals but I never can seem to find something when I'm looking for it.

   Anyway, you can't run BCX in Windows ENHANCED mode but you CAN run it
in Windows STANDARD mode.  Before you run Windows, however, you need to
run TKERNEL.EXE (this is all covered on pgs. 4-5 in the User's Guide).

   I am now running Windows in standard mode so BCX works but I have yet
to decide whether its worth it to give up the advantages of enhanced mode
Windows just so I can do my compiling from within Windows.

   Many thanks to those who responded privately to me for answering my
question.  Next time I promise to search the manuals more thoroughly
before I waste bandwidth on the net.

-- Cory  (libcrn@byuvm.bitnet)

johnm@spudge.UUCP (John Munsch) (03/08/91)

In article <91066.163143LIBCRN@BYUVM.BITNET> LIBCRN@BYUVM.BITNET writes:
>   I am trying to get the extended version of Borland's IDE (BCX.EXE)
>to work from within Windows.

BCX will only work in Windows Standard mode (win -s).  This information and
the info on how to use the program TKERNEL is on pages 4 and 5 of the 
Borland C++ manual.

John Munsch

wew@naucse.cse.nau.edu (Bill Wilson) (03/09/91)

From article <91066.163143LIBCRN@BYUVM.BITNET>, by LIBCRN@BYUVM.BITNET:
> 
>    I am trying to get the extended version of Borland's IDE (BCX.EXE)
> to work from within Windows.  I have set up a .PIF file for this
> *** a bunch deleted ***

To get BCX to work correctly with Windows, you will need to load
the tkernel program before starting Windows.  You should use
the following options:

   tkernel hi=yes kilos=1000

the 1000 indicates the number of K of ram to assign to the task.
Then the pif for Windows should work OK.  Borland says that you should
have at least 1000 for correct operation.  700 will work most of
the time though.

 
-- 
Let sleeping dragons lie........                    | The RoleMancer 
--------------------------------------------------------------------
Bill Wilson (wew@naucse.cse.nau.edu | ucc2wew@nauvm | wilson@nauvax)
Northern AZ Univ  Flagstaff, AZ 86011

wew@naucse.cse.nau.edu (Bill Wilson) (03/09/91)

From article <DAVE.91Mar7234444@slam.InterLan.COM>, by dave@interlan.Interlan.COM (Dave Goldblatt):
> 
> The question was asked as to how to get BCX to work under Windows.
> 
> The answer: You can't.
>

Although BCX is a DOS application, I use it with Windows all the time.
The tkernel TSR (see my other post) must be used to get things talking
correctly.  Granted when I switch tasks the process halts, but I can
switch back and resume where I left off.  I typically compile, switch
to Windows and run the debugger and switch back without any difficulties.

 
-- 
Let sleeping dragons lie........                    | The RoleMancer 
--------------------------------------------------------------------
Bill Wilson (wew@naucse.cse.nau.edu | ucc2wew@nauvm | wilson@nauvax)
Northern AZ Univ  Flagstaff, AZ 86011

dave@interlan.Interlan.COM (Dave Goldblatt) (03/10/91)

Yeah, I realized after I posted that I should have explicitly cast Windows
to (enhanced mode) Windows.

I only use enhanced mode, and was only referring to the default version run
on a 386 (enhanced).  If you're running standard or real mode, you can
preload TKERNEL and off you go.  Slow, but off you go. :-)

A DPMI version will be nice, because starting/exiting Windows _is_ a
real drag.  But then again, I feel compiling (actually, linking) in
standard mode is more of one....

-dg-
--
 "Hey, Copperfield!  		*	Dave Goldblatt	[dave@interlan.com]
   Suck on this!"		*	
     - Penn Jillette, of	*	(No longer working for, and certainly
	Penn & Teller          	*	 not representing, Racal InterLan)

ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/11/91)

You're right about BCX being a lot faster than the doc memory only program
bc.

Here's how you run it in windows:

1.	make sure you're in standard mode (or at least aren't in 
	386 enhanced mode).

2.	don't set aside extended memory with the .pif file.

3.	before starting windows, type in:

	TKERNEL hi=yes,kilos=1024

4.	win /s 

5.	now you can run bcx


This stuff is in the manuals if you run into problems.

Terrell

poffen@sj.ate.slb.com (Russ Poffenberger) (03/12/91)

In article <1991Mar8.190821.22675@ux1.cso.uiuc.edu> tmkk@uiuc.edu (Scott Coleman) writes:
>
>In article <DAVE.91Mar7234444@slam.InterLan.COM> dave@interlan.Interlan.COM (Dave Goldblatt) writes:
>>
>>The question was asked as to how to get BCX to work under Windows.
>>
>>The answer: You can't.
>
>Wow, really? Guess I'll have to run right home and delete all that stuff
>from my Development .GRP ;-)
>
>Seriously, you most certainly CAN run BCX under Windows. Follow this
>procedure (which is outlined somewhere in the manuals, but I've
>forgotten exactly where):
>
>1. Run TKERNEL.EXE from DOS before starting windows.
>
>2. Start windows in either Standard or Real mode. Note: Your statement
>above is correct *only* if you add the words "in 386 Enhanced mode."
>
>3. Start BCX from the Program manager as you normally would.
>
>Works just fine for me.
>
>As to why you would want to run BCX from within Windows, I don't know
>about you, but I often need to switch quickly from "edit the source
>code" mode to "run the program" mode, and starting/exiting Windows
>every time gets to be a REAL drag.


If you had read the original post, you would see that he is running an IBM
model 55sx which is a 386sx machine. I would assume he is running windows in
enhanced mode.

It is true you can get it to work in standard or real mode, but you can't do
it within a DOS window that way, or in the background either. This makes it
much more difficult to develop in. It is nice to build your program, do other
things at the same time (edit files?), and try out the changes immediately
without exiting to DOS, or switching full screen DOS sessions.

I find it much more convenient to just compile in a DOS window, and suffer the
slowdown than to do all this switching around. Hopefully Borland will come up
with a way for us to have our cake and eat it too.

Russ Poffenberger               DOMAIN: poffen@sj.ate.slb.com
Schlumberger Technologies       UUCP:   {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive		CIS:	72401,276
San Jose, Ca. 95110             (408)437-5254

brent@well.sf.ca.us (Brent Southard) (03/12/91)

In article <91066.163143LIBCRN@BYUVM.BITNET> LIBCRN@BYUVM.BITNET writes:
>
>   I am trying to get the extended version of Borland's IDE (BCX.EXE)
>to work from within Windows.  I have set up a .PIF file for this
>purpose which specifies that BCX is to be given 800 Kbytes of extended
>memory to work with (XMS does stand for extended memory, doesn't it?).
>Unfortunately, when I invoke BCX, I always get an error message that
>says that 0 Kbytes of extended memory is available when 706 Kbytes is
>needed.

Well, XMS stands for Extended Memory Specification, which defines extended
memory which is managed by an XMM (extended memory manager), such as
himem.sys.  Unfortunately, Borland didn't see fit to use this spec as far as
I can tell for their protected mode products.  I sure don't know why.

The point is moot in this case, since the Borland protected mode tools
(except for TASMX) are not DPMI-compliant and hence will not run in Enhanced
mode.  You can run BCX in Standard mode though, if you follow the
instructions in the User's Guide.

brent
-- 
brent southard  (313) 643-1971   |   usenet:  ...!well!brent
ImageTech Corp  (313) 353-7900   |   bix:     brent

"When frog licking is outlawed, only outlaws will lick frogs."