Borland to show 32 bit Delphi

3 views
Skip to first unread message

Duncan Murdoch

unread,
Jul 31, 1995, 3:00:00 AM7/31/95
to
The current PC Week has an article about plans to demonstrate 32 bit Delphi in
the URL http://www.ziff.com/~pcweek/news/0731/tbit.html. Some quotes:

'"Our No. 1 design aim was full compatibility with the shipping product,"
Robertson [senior product manager] said. Initial benchmarks of the 32-bit
compiler have produced applications that are three to four times faster
thanthe 16-bit version, he said. '

'Developers also have the option of generating a 16-bit Windows 3.1 or 32-bit Windows NT
applications if the code doesn't specifically call Windows 95 features, said Zack Urlocker, group
product manager for Delphi.'

'Borland officials expect to begin shipping Delphi32 by the end of the year. Packaging and pricing
have yet to be determined. '

Duncan Murdoch


Steve Teixeira

unread,
Jul 31, 1995, 3:00:00 AM7/31/95
to

BTW, pardon the shameless plug, but for those interested: we'll be demoing Delphi-32 quite
a bit at next week's Borland Developer's Conference in San Diego. There are still some
spots available, so call 1-800-350-4244 if you're interested in attending.

-Steve Teixeira
stei...@borland.com


Tommy Hsieh

unread,
Jul 31, 1995, 3:00:00 AM7/31/95
to
Any idea how to get into the beta testing of this 32 bit Delphi ?
Thanks.

-tommy


Steve Teixeira (stei...@borland.com) wrote:

: -Steve Teixeira
: stei...@borland.com


--

Duncan Murdoch

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
In article <3vje9h$b...@engnews2.Eng.Sun.COM> to...@Sun.COM (Tommy Hsieh) writes:

>Any idea how to get into the beta testing of this 32 bit Delphi ?

I'd guess the same as beta tests for earlier products: you download an
application from Compuserve, and send it in. If you have something to offer
Borland that they want (e.g. an unusual hardware setup, or the prospect of an
order for a large number of copies of Delphi) then they'll pick you.

A few months before the current release, they opened up the testing to anyone
who wanted to participate, more or less like the Win95 beta. I haven't heard
any announcements that they're doing that with this release.

Duncan Murdoch

horr...@staff.monash.edu.au

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
>Subject: Re: Borland to show 32 bit Delphi

>>'Developers also have the option of generating a 16-bit Windows 3.1 or
32-bit Windows NT>>applications if the code doesn't specifically call Windows
95 features, said Zack Urlocker, group>>product manager for Delphi.'

I am yearning for the speed of 32-bit delphi and the end of the 64-k limits.
Problem is, does the end user have to have Win95 or NT to use the
delphi32-compiled program?

Will there be any support for win32s?


Frank Burleigh

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
It's a ptiy Borland doesn't see fit to include OS/2 support for
Delphi. This makes us choose: Delphi or OS/2.

--
Frank Burleigh 812-333-7082 (home); 812-855-9170 (work)
School of Law, Indiana University, Bloomington, IN 47405
Internet burl...@bronze.ucs.indiana.edu; CIS 72730,1017

Ray Lischner

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
On Mon, 31 Jul 1995 13:39:32 GMT, dmur...@mast.queensu.ca (Duncan
Murdoch) wrote:

>The current PC Week has an article about plans to demonstrate 32 bit Delphi in
>the URL http://www.ziff.com/~pcweek/news/0731/tbit.html. Some quotes:

>'"Our No. 1 design aim was full compatibility with the shipping product,"
>Robertson [senior product manager] said. Initial benchmarks of the 32-bit
>compiler have produced applications that are three to four times faster
>thanthe 16-bit version, he said. '

>'Developers also have the option of generating a 16-bit Windows 3.1 or 32-bit Windows NT


>applications if the code doesn't specifically call Windows 95 features, said Zack Urlocker, group
>product manager for Delphi.'

I would like to verify my assumptions about integers types in 32-bit
Delphi. According to the Object Pascal manual, Integer and Cardinal
will be 32 bits (or rather, Cardinal will be 31 bits...). Word will
continue to be 16 bits.

In other words, for maximum portability, we should be using Word for
unsigned integers that are truly 16 bits, and Cardinal for unsigned
integers that are the "natural" size for the environment. Similarly,
we should use SmallInt for signed integers that are 16 bits, Integer
for signed integers that are the natural size, and LongInt for signed
integers that must be 32 bits.

Is this correct?
--
Ray Lischner (li...@tempest-sw.com)
Tempest Software, Corvallis, Oregon


Steve Teixeira

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
horr...@staff.monash.edu.au wrote:
>>Subject: Re: Borland to show 32 bit Delphi
>>>'Developers also have the option of generating a 16-bit Windows 3.1 or
>32-bit Windows NT>>applications if the code doesn't specifically call Windows
>95 features, said Zack Urlocker, group>>product manager for Delphi.'
>
>I am yearning for the speed of 32-bit delphi and the end of the 64-k limits.
>Problem is, does the end user have to have Win95 or NT to use the
>delphi32-compiled program?
>
>Will there be any support for win32s?

Delphi32 itself will be a Win32 application that runs only in Win95 and NT. Delphi32-
generated applications will be 32-bit. I don't know whether or not they will be runnable
under Win32s. I suppose, in theory, as long as you don't make Win32 calls that your app
depends on working, any Win32 app will run under Win32s. The question is, does VCL depend
on such calls? I don't know.

-Steve Teixeira
stei...@borland.com


Steve Teixeira

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to

Steve Teixeira

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
li...@tempest-sw.com (Ray Lischner) wrote:
>On Mon, 31 Jul 1995 13:39:32 GMT, dmur...@mast.queensu.ca (Duncan
>Murdoch) wrote:
>
>>The current PC Week has an article about plans to demonstrate 32 bit Delphi in
>>the URL http://www.ziff.com/~pcweek/news/0731/tbit.html. Some quotes:
>
>>'"Our No. 1 design aim was full compatibility with the shipping product,"
>>Robertson [senior product manager] said. Initial benchmarks of the 32-bit
>>compiler have produced applications that are three to four times faster
>>thanthe 16-bit version, he said. '
>
>>'Developers also have the option of generating a 16-bit Windows 3.1 or 32-bit Windows NT
>>applications if the code doesn't specifically call Windows 95 features, said Zack Urlocker, group
>>product manager for Delphi.'
>
>I would like to verify my assumptions about integers types in 32-bit
>Delphi. According to the Object Pascal manual, Integer and Cardinal
>will be 32 bits (or rather, Cardinal will be 31 bits...). Word will
>continue to be 16 bits.
>
>In other words, for maximum portability, we should be using Word for
>unsigned integers that are truly 16 bits, and Cardinal for unsigned
>integers that are the "natural" size for the environment. Similarly,
>we should use SmallInt for signed integers that are 16 bits, Integer
>for signed integers that are the natural size, and LongInt for signed
>integers that must be 32 bits.
>

Here are the ones that I know of

type 16-bit size 32-bit size
----------------------------------------
integer 16 32
word 16 16
smallint 16 16
cardinal 16 "31"
longint 32 32

-Steve Teixeira
stei...@borland.com


fred.w...@ntpcug.org

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
b>It's a ptiy Borland doesn't see fit to include OS/2 support for

>Delphi. This makes us choose: Delphi or OS/2.

Taking a realistic look at market share, reduces this decision to less
than rocket science.

Borland does not support OS/2 for exactly the same reason they have
released their last DOS product, _market share_. All the moaning in the
world will not change OS/2 or DOS's market shares.

Life's a bitch and then you die :-)

I don't much care for Windoze, but I have bills to pay.

Fred
---
ş SRP 2.00 #1203 ş Are you Beavis or Butthead??


Ken Carpenter

unread,
Aug 1, 1995, 3:00:00 AM8/1/95
to
In article <3vkh4n$g...@fenris.com>, li...@tempest-sw.com says...

>
>In other words, for maximum portability, we should be using Word for
>unsigned integers that are truly 16 bits, and Cardinal for unsigned
>integers that are the "natural" size for the environment. Similarly,
>we should use SmallInt for signed integers that are 16 bits, Integer
>for signed integers that are the natural size, and LongInt for signed
>integers that must be 32 bits.

And does Delphi32 support a 32-bit unsigned type (i.e., LongWord)?


--
**************************************************************************
* Ken Carpenter * No PGP public key available by finger. *
* Software Design & Development * However, ... *
* Network Group * Middle finger available in public with *
* Delta Controls Inc. * or without request. *
**************************************************************************


Steve Teixeira

unread,
Aug 2, 1995, 3:00:00 AM8/2/95
to
JBa...@onramp.net (John Baima) wrote:

>Steve Teixeira <stei...@borland.com> wrote:
>
>>Delphi32 itself will be a Win32 application that runs only in Win95 and NT. Delphi32-
>>generated applications will be 32-bit.
>
>How about Turbo Debugger? I now live in WinNT and I *really* miss TD
>sometimes! For most things, the IDE debugger is fine, but for some
>things (like large arrays) TD was much quicker. Any hope?
>

There is a 32-bit version of TDW that runs under NT. The reason the 16-bit version
doesn't run under NT is because MS doesn't support 16-bit debuggers under NT (the
integrated debugger works because it's a message-based debugger rather than a low-
level debugger like TDW).

-Steve Teixiera
stei...@borland.com


John Baima

unread,
Aug 2, 1995, 3:00:00 AM8/2/95
to
>>>'"Our No. 1 design aim was full compatibility with the shipping product,"

>Here are the ones that I know of

>type 16-bit size 32-bit size
>----------------------------------------
>integer 16 32

^^^^^^^^^^^^^^^^^^^^^^^^^


>word 16 16
>smallint 16 16
>cardinal 16 "31"
>longint 32 32

> -Steve Teixeira

Steve, this *really sucks* and flys in the face of the "full
compatibility" statement. You should not change the size of the old,
existing types, but you should have made a new type (maybe
"NaturalInt" or whatever) variable size. Now, everyone will have to
carefully examine their existing programs to see which of the current
Integers need to be changed to smallint. I understand that the
variable size will be necessary for some system/vcl calls, but they
should ALL have utilitized the NEW type not the old.

-John

John Baima

unread,
Aug 2, 1995, 3:00:00 AM8/2/95
to
Steve Teixeira <stei...@borland.com> wrote:

>Delphi32 itself will be a Win32 application that runs only in Win95 and NT. Delphi32-
>generated applications will be 32-bit.

How about Turbo Debugger? I now live in WinNT and I *really* miss TD
sometimes! For most things, the IDE debugger is fine, but for some
things (like large arrays) TD was much quicker. Any hope?

-John Baima


Hallvard Vassbotn

unread,
Aug 2, 1995, 3:00:00 AM8/2/95
to
In <3vkh4n$g...@fenris.com> li...@tempest-sw.com (Ray Lischner) writes:
>I would like to verify my assumptions about integers types in 32-bit
>Delphi. According to the Object Pascal manual, Integer and Cardinal
>will be 32 bits (or rather, Cardinal will be 31 bits...). Word will
>continue to be 16 bits.

>In other words, for maximum portability, we should be using Word for


>unsigned integers that are truly 16 bits, and Cardinal for unsigned
>integers that are the "natural" size for the environment. Similarly,
>we should use SmallInt for signed integers that are 16 bits, Integer
>for signed integers that are the natural size, and LongInt for signed
>integers that must be 32 bits.

>Is this correct?

Yep, it is correct.

--
Hallvard Vassbotn | Falcon AS (a Reuters company) | Without programmers,
hall...@falcon.no | Stranden 1, 0250 OSLO, Norway | the world would stop!


Duncan Murdoch

unread,
Aug 3, 1995, 3:00:00 AM8/3/95
to
Some more news on Delphi32 is contained in a short sidebar in the
August/September issue of PC Techniques(p. 103). One thing that wasn't
mentioned in the PC Week article is the following:

"A first in Delphi32 will be the ability of the compiler and linker to deal
with OBJ files. Delphi32 will, as an option, generate OBJ files, and its
linker can link OBJs created (for example) with BC++ and TASM. The enabling
factor here is that Delphi32's Object Pascal compiler is a front end/back end
system that uses the same 32-bit back end as used in BC++ 4.5."

This is good news for the people looking to produce OBJ files, but I'm worried
about the new compiler architecture. One reason TP/BP/Delphi are so fast is
because of the one-pass code generation. I hope that isn't lost in Delphi32.

Duncan Murdoch

Duncan Murdoch

unread,
Aug 3, 1995, 3:00:00 AM8/3/95
to
In article <3vqp3i$5...@news.onramp.net> JBa...@onramp.net (John Baima) writes:

>pig...@evolution.com (Piglet) wrote:


>>My understanding of the Integer and Cardinal types is that they were
>>intended to be "generic" types, used when you wanted the best choice
>>for the hardware underneath, not when you cared what the specific
>>implementation was. When one cares about the specific implementation,
>>one should use the SmallInt and LongInt types.

>Yes, that is the picture NOW. However, I've been using BP for 9 years
>and this is NEW and it will cause lots of problems which could have
>*easily* been avoided.

I don't think either choice (i.e. keeping "integer" as 16 bits, or making it
the natural word size of the machine) is without problems. If they had kept
it at 16 bits, then your old BP programs would work, but they'd all be
unnecessarily slowed down: in the 32 bit modes, 16 bit calculations are
slower than 32 bit calculations. People who had always been careful not to
make assumptions about the sizes of types, i.e. those who had religiously used
"sizeof", would be unnecessarily penalized.

Furthermore, the general principle that has always held with BP that "integer"
should be the default choice for best speed would be violated.

In any case, there's a simple mechanical change to your programs that will
make them work as if Borland had gone with your preference. Just go through
them with a text editor and substitute "smallint" for "integer" in every case.
You'll suffer the performance penalty, but your code should work.

Duncan Murdoch

Chuck Jazdzewski

unread,
Aug 3, 1995, 3:00:00 AM8/3/95
to

Duncan,

Not to worry. This is an option and not the default. We still produce
the 32 bit equivelent to a DCU and will continue to because of the
performance advantages of doing it this way. We have also improved
the linkers performance over 16 bits so link times. We always looking
for ways to improve our turn-around time. The user benefit would have
to be significant and universal for us to introduce a feature that slows
that time down.

Chuck Jazdzewski (cj...@borland.com)
Delphi Development


John Baima

unread,
Aug 3, 1995, 3:00:00 AM8/3/95
to
pig...@evolution.com (Piglet) wrote:


>My understanding of the Integer and Cardinal types is that they were
>intended to be "generic" types, used when you wanted the best choice
>for the hardware underneath, not when you cared what the specific
>implementation was. When one cares about the specific implementation,
>one should use the SmallInt and LongInt types.

Yes, that is the picture NOW. However, I've been using BP for 9 years
and this is NEW and it will cause lots of problems which could have
*easily* been avoided.

-John

Piglet

unread,
Aug 3, 1995, 3:00:00 AM8/3/95
to
JBa...@onramp.net (John Baima) wrote:
>>>>'"Our No. 1 design aim was full compatibility with the shipping product,"

>>Here are the ones that I know of
>>type 16-bit size 32-bit size
>>----------------------------------------
>>integer 16 32
>^^^^^^^^^^^^^^^^^^^^^^^^^

>>smallint 16 16
>>cardinal 16 "31"
>>longint 32 32
>> -Steve Teixeira

>Steve, this *really sucks* and flys in the face of the "full
>compatibility" statement. You should not change the size of the old,
>existing types, but you should have made a new type (maybe
>"NaturalInt" or whatever) variable size. Now, everyone will have to
>carefully examine their existing programs to see which of the current
>Integers need to be changed to smallint. I understand that the
>variable size will be necessary for some system/vcl calls, but they
>should ALL have utilitized the NEW type not the old.

My understanding of the Integer and Cardinal types is that they were


intended to be "generic" types, used when you wanted the best choice
for the hardware underneath, not when you cared what the specific
implementation was. When one cares about the specific implementation,
one should use the SmallInt and LongInt types.


Piglet

bri...@ibm.net

unread,
Aug 4, 1995, 3:00:00 AM8/4/95
to
In <dmurdoch.23...@mast.queensu.ca>, dmur...@mast.queensu.ca (Duncan Murdoch) writes:
>The current PC Week has an article about plans to demonstrate 32 bit Delphi in
>the URL http://www.ziff.com/~pcweek/news/0731/tbit.html. Some quotes:
>
>'"Our No. 1 design aim was full compatibility with the shipping product,"
>Robertson [senior product manager] said. Initial benchmarks of the 32-bit
>compiler have produced applications that are three to four times faster
>thanthe 16-bit version, he said. '
(Snip)

Do you think it will run under OS/2?

Steve.

Rune Moberg

unread,
Aug 4, 1995, 3:00:00 AM8/4/95
to
In article <3vlj9g$s...@druid.borland.com>,

Steve Teixeira <stei...@borland.com> wrote:
> type 16-bit size 32-bit size
> ----------------------------------------
> integer 16 32
> word 16 16

> smallint 16 16
> cardinal 16 "31"
> longint 32 32

I still think a 32 bit word type is missing...?
i.e.: a 32 bit unsigned integer would be nice.


=\
*=- R.Moberg, author of CD-Player Pro! ftp.cica.indiana.edu:
=/ /win3/sounds/cdppro45.zip

Russell Turpin

unread,
Aug 4, 1995, 3:00:00 AM8/4/95
to
-*----
There are some fairly obvious questions about the next release of
Delphi that I have not seen discussed yet.

(1) When will it be available?

(2) Will the documentation be improved?

(3) How, specifically, has OLE support been improved? Is there
any automation for writing OLE server apps?

Russell
--
I'd rather that a bigot mistake me for a lesbian than that a lesbian
mistake me for a bigot.
-- Tovah Hollander

Nick Hodges

unread,
Aug 4, 1995, 3:00:00 AM8/4/95
to
Okay, Chuck, now who's everywhere? <g>


--
* LT Nick Hodges, USN Naval Postgraduate School *
* jnho...@nps.navy.mil Information Technology Management*
* CIS: 71563,2250 AOL: NHodges Monterey, CA *
* The opinions expressed above are entirely my own and not the Navy's. *

Ben Z 23

unread,
Aug 4, 1995, 3:00:00 AM8/4/95
to
For those of you in the know who can tell me,

Will 32 bit Delphi have Threads? How about OCX support?

Thanks in advance,
-Ben

jmm...@nando.net

unread,
Aug 5, 1995, 3:00:00 AM8/5/95
to

> It's a ptiy Borland doesn't see fit to include OS/2 support for
> Delphi. This makes us choose: Delphi or OS/2.

O/S who?


le...@utw.com

unread,
Aug 5, 1995, 3:00:00 AM8/5/95
to
In <3vlj9g$s...@druid.borland.com>, Steve Teixeira <stei...@borland.com> writes:

>Here are the ones that I know of
>

>type 16-bit size 32-bit size
>----------------------------------------
>integer 16 32
>word 16 16
>smallint 16 16
>cardinal 16 "31"
>longint 32 32
>

> -Steve Teixeira
> stei...@borland.com

Word is the native width of the processor so on a 32bit processor with a 32 bit
OS a word is 32 bits. Is Borland changing the meaning of standard terms.

----------------------------------------------------------------------------
Chris Levin |email:le...@utw.com
829 East Elm Avenue | le...@protel-cti.com
Salt Lake City, UT 84106 | WWW:http://www.utw.com/~levin/cl_home.html
801-485-5637 |radio:KB7YOU
----------------------------------------------------------------------------
This letter was composed, filed and mailed under OS/2 Warp. If you are
not WARPED yet start NOW!
----------------------------------------------------------------------------


le...@utw.com

unread,
Aug 5, 1995, 3:00:00 AM8/5/95
to
In <3voilg$8...@news.onramp.net>, JBa...@onramp.net (John Baima) writes:

>Steve, this *really sucks* and flys in the face of the "full
>compatibility" statement. You should not change the size of the old,
>existing types, but you should have made a new type (maybe
>"NaturalInt" or whatever) variable size. Now, everyone will have to
>carefully examine their existing programs to see which of the current
>Integers need to be changed to smallint. I understand that the
>variable size will be necessary for some system/vcl calls, but they
>should ALL have utilitized the NEW type not the old.
>

>-John
>

It is called writing portable code. The definitions of types has been around
for longer then Delphil.

David Prothero

unread,
Aug 5, 1995, 3:00:00 AM8/5/95
to
>Will 32 bit Delphi have Threads? How about OCX support?

I believe OCX support is an affirmative. According to a relative of
mine who is an OCX developer, he confirmed this with Borland. Since
it is apparent that Borland reads this group, perhaps they could
confirm this....

-David Prothero
-International Technology Group
-Salem, Oregon

Vince Risi

unread,
Aug 5, 1995, 3:00:00 AM8/5/95
to
In article <dmurdoch.24...@mast.queensu.ca>,

dmur...@mast.queensu.ca (Duncan Murdoch) wrote:
>Some more news on Delphi32 is contained in a short sidebar in the
>August/September issue of PC Techniques(p. 103). One thing that wasn't
>mentioned in the PC Week article is the following:
>
>"A first in Delphi32 will be the ability of the compiler and linker to deal
>with OBJ files. Delphi32 will, as an option, generate OBJ files, and its
>linker can link OBJs created (for example) with BC++ and TASM. The enabling
>factor here is that Delphi32's Object Pascal compiler is a front end/back end
>system that uses the same 32-bit back end as used in BC++ 4.5."
>
>This is good news for the people looking to produce OBJ files, but I'm worried
>about the new compiler architecture. One reason TP/BP/Delphi are so fast is
>because of the one-pass code generation. I hope that isn't lost in Delphi32.
>
>Duncan Murdoch

Have a look at Virtual Pascal for OS/2. Vitaly Miryanov has done an
interesting thing with Units. He creates OBJs and VPIs. The compiler
is blindingly fast and is a monumental achievement if it is the work
of one man. (Perhaps you do not have access to OS/2 to check it out.)
Here is a man that can produce a Delphi for OS/2.

Vince
=====


Chuck Jazdzewski

unread,
Aug 6, 1995, 3:00:00 AM8/6/95
to
ben...@aol.com (Ben Z 23) wrote:
>For those of you in the know who can tell me,
>
>Will 32 bit Delphi have Threads? How about OCX support?

32 bit Delphi will support the Win32 calls for threads as well
as the compiler extensions for thread local storage found in
other compiled languages. Ole Controls (OCX's) are also going
to be supported.

Don Beusee

unread,
Aug 6, 1995, 3:00:00 AM8/6/95
to
JBa...@onramp.net (John Baima) writes:
> >>>'"Our No. 1 design aim was full compatibility with the shipping product,"
>
> >Here are the ones that I know of
>
> >type 16-bit size 32-bit size
> >----------------------------------------
> >integer 16 32
> ^^^^^^^^^^^^^^^^^^^^^^^^^

> >word 16 16
> >smallint 16 16
> >cardinal 16 "31"
> >longint 32 32
>
> > -Steve Teixeira
>
> Steve, this *really sucks* and flys in the face of the "full
> compatibility" statement. You should not change the size of the old,
> existing types, but you should have made a new type (maybe
> "NaturalInt" or whatever) variable size. Now, everyone will have to
> carefully examine their existing programs to see which of the current
> Integers need to be changed to smallint. I understand that the
> variable size will be necessary for some system/vcl calls, but they
> should ALL have utilitized the NEW type not the old.


Its normally a foregone conclusion that integer will always be based on the
CPU's native integer. Frankly, integer should have already been 32 bit wide.
Programmers should never depend on the size of int (C) or integer (Pascal).
Borland did the right thing, believe it or not.

Regards,
Don.


Russell Turpin

unread,
Aug 6, 1995, 3:00:00 AM8/6/95
to
-*-----
In article <402h0v$l...@inet-nntp-gw-1.us.oracle.com>,

Don Beusee <dbe...@us.oracle.com> wrote:
> Programmers should never depend on the size of int (C) or
> integer (Pascal). ...

This much repeated aphorism is rarely meant literally. Almost
all programs behave differently when the size of their int's and
float's are changed. Typically, they throw up overflow and
underflow exceptions on different data sets, or if such
exceptions are not present, give different answers (one right,
one wrong) in the intermediate range.

Is it worth thinking about what it would take to make a program
that uses integers not depend on their size? Here are two
choices:

(1) Don't use int's. Instead, use arbitrary precision
arithmetic, implemented so that it detects and works
with different int sizes. (Aha! An advantage of C++
operator overloading!)

(2) Rely on some small range for int (e.g., 15 bit),
explicitly check when that range is exceeded during
program execution, and rig the installation so that the
program is never executed on any weird machine with a
smaller int.

Note that the second choice isolates behavioral differences to
the install program, refusing to install because "program X will
not run on this machine because of Y." As a program is
developed, it might be worth keeping a list of such issues as
they come up, so that the install program can be written to check
on them. (Boxes? Who needs them stinkin' boxes?!)

Usually, when programmers say that their programs do not depend
on int size, what they mean is that their programs (in theory)
behave the same for all int values in the common range of any
change, so that when the program moves from the 16-bit to 32-bit
world, it still works on the data sets where it performed
correctly in the 16-bit world. This is a good thing, though it
is not quite independence from int size. Note that the
differences in behavior that such programs exhibit are often
good. "On 32-bit machines the program will work for these data
sets ALSO." "The 64K limit is no longer in place." Since this
kind of difference is usually good, it is exempted from the
measure of int size dependence. After all, what we really want
is int size robustness, not int size independence. We know the
kinds of operations we want to exclude -- e.g., bit operations
that depend on int size -- and the program practices we want to
encourage -- e.g., explicitly typing words whose size depends on
host hardware or OS.

Fair enough. All this is obvious, right? If y'all find this boring,
I'll stop with such early morning musings.

Ben Z 23

unread,
Aug 6, 1995, 3:00:00 AM8/6/95
to
Chuck Jazdzewski (cj...@borland.com) wrote:
<<32 bit Delphi will support the Win32 calls for threads as well
as the compiler extensions for thread local storage found in
other compiled languages. Ole Controls (OCX's) are also going
to be supported.>>

Great!! What would really be nice would be to have a "ThreadForm"
(like MFC's "CWinThread") to save us some work to create Forms that
receive input in their own thread. Sounds like Borland is doing this
product right! (I'm not surprised)

I probably shouldn't say this, but I'd be willing to pay a higher price
for
Delphi to help keep a great company like Borland around to compete
against Micro$oft.

-Ben Ziegler

John Baima

unread,
Aug 6, 1995, 3:00:00 AM8/6/95
to
dmur...@mast.queensu.ca (Duncan Murdoch) wrote:

>>Yes, that is the picture NOW. However, I've been using BP for 9 years
>>and this is NEW and it will cause lots of problems which could have
>>*easily* been avoided.

>I don't think either choice (i.e. keeping "integer" as 16 bits, or making it

>the natural word size of the machine) is without problems. If they had kept
>it at 16 bits, then your old BP programs would work, but they'd all be
>unnecessarily slowed down: in the 32 bit modes, 16 bit calculations are
>slower than 32 bit calculations.

Sorry, Duncan, I don't see why this is necessarily true, even if it
may be true for the current processors. How many cycles does it take
to do 16 bit rather than 32 bit math? Even if it is true that 32 bit
integer math is faster, the speed difference is *completely*
insignificant for the vast majority of programs. Where speed is a
problem, i use assembly language. Places where speed is necessary are
few and far between.

>People who had always been careful not to
>make assumptions about the sizes of types, i.e. those who had religiously used
>"sizeof", would be unnecessarily penalized.

Sorry, but this is not true either. What if you use Integers in file
records like I do?

>Furthermore, the general principle that has always held with BP that "integer"
>should be the default choice for best speed would be violated.

Where has Borland ever said that?

>In any case, there's a simple mechanical change to your programs that will
>make them work as if Borland had gone with your preference. Just go through
>them with a text editor and substitute "smallint" for "integer" in every case.
>You'll suffer the performance penalty, but your code should work.

Yes, I did consider this, but it will not be so simple. There will be
system dependent places where true Integers are necessary and these
places will not be obvious.

I am unconvinced that Borland is not making a big mistake to
*redefine* old types and make new types constant. It does not make
sense to me.

-John Baima


Rune Moberg

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
In article <4016ko$m...@druid.borland.com>,

Chuck Jazdzewski <cj...@borland.com> wrote:
> other compiled languages. Ole Controls (OCX's) are also going
> to be supported.

Supported, as in easily designed?
("easy" like designing a VCL component)

ste...@ibm.net

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
>Delphi32 itself will be a Win32 application that runs only in Win95 and NT. Delphi32-
>generated applications will be 32-bit. I don't know whether or not they will be runnable
>under Win32s. I suppose, in theory, as long as you don't make Win32 calls that your app
>depends on working, any Win32 app will run under Win32s. The question is, does VCL depend
>on such calls? I don't know.
>
> -Steve Teixeira
> stei...@borland.com
>
Should the omission of OS/2 to your list cause me to lose all hope of ever
finding Delphi, an excellent RAD environment, on Warp, an excellent OS?

Steven Hayashi
ste...@ibm.net


Tim Pigden

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
Borland seem to be following the same practice that has applied to C for
a very long time. Doing something else would be just as confusing to
another part of the development community.

People would feel very confused on taking up delphi 2 years down the line
to find that integers were, for a bizarre accident of history, only 16
bits wide.

Tim

Paul Ingram

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
OS/2. You know that cheap OS that everyone ignores because
they would rather have a single source for all their
operating systems and applications. I personally use both
Delphi and OS/2 and I wouldn't want to be without either or
eithers market presence.

Paul.

--
Paul Ingram Group Ltd
140A High Street email: firstname...@ig.co.uk
Godalming voice: +44 1483 424424
Surrey, UK fax: +44 1483 419419

Chuck Jazdzewski

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
mobe...@oslonett.no (Rune Moberg) wrote:
>In article <4016ko$m...@druid.borland.com>,
>Chuck Jazdzewski <cj...@borland.com> wrote:
>> other compiled languages. Ole Controls (OCX's) are also going
>> to be supported.
>
>Supported, as in easily designed?
>("easy" like designing a VCL component)

I cannot comment on the extent of this support other than to say
to expect at the minimun the amount of support we had for VBX's.

Hallvard Vassbotn

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
In <4016ko$m...@druid.borland.com> Chuck Jazdzewski <cj...@borland.com> writes:
>ben...@aol.com (Ben Z 23) wrote:
>>For those of you in the know who can tell me,
>>
>>Will 32 bit Delphi have Threads? How about OCX support?

>32 bit Delphi will support the Win32 calls for threads as well

>as the compiler extensions for thread local storage found in

>other compiled languages. Ole Controls (OCX's) are also going
>to be supported.

>Chuck Jazdzewski (cj...@borland.com)
>Delphi Development

A key question for us is how extensive this OCX support will be.

Will it only support the usage of pre-written OCXs (à la the VBX support
today) or will it include support for _writing_ your own OCXs? This is
a cruical difference.

I take it for granted that it will be possible to write OCX by way of
directly calls to OLE2 libraries and following MS standards, but it would
be much more powerful if you could write OCXs the same way as we write
componetnts today.

Many of the concepts are very similar in OCXs and VCL components: properties,
methods etc. Would be very powerful to have a one-to-one mapping here.


--
Hallvard Vassbotn | Falcon AS (a Reuters company) | Without programmers,
hall...@falcon.no | Stranden 1, 0250 OSLO, Norway | the world would stop!


Chad Z. Hower

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to

Subject: Re: Borland to show 32 bit Delphi

>Steve, this *really sucks* and flys in the face of the "full
>compatibility" statement. You should not change the size of the old,
>existing types, but you should have made a new type (maybe
>"NaturalInt" or whatever) variable size. Now, everyone will have to
>carefully examine their existing programs to see which of the current
>Integers need to be changed to smallint. I understand that the
>variable size will be necessary for some system/vcl calls, but they
>should ALL have utilitized the NEW type not the old.

1) Ever heard of search and replace?

2) Are you experienced? EVERY Pascal compilers INTEGER is SYSTEM
specific.

What you propose would make Delphi REALLY incompatible with the rest of
the world. I suggest if you WANT 16 bit then use WORD as the DOCS specify it
as.

INTEGER is NEVER guaranteed to be 16 bits.

_
"640K ought to be enough for anybody." (Bill Gates, 1981)
QWicKeSST - The ultimate database QWK reader, and NO limits. #BLYGJOMK
Special Compile: 1.008A (Alpha)


'[1;35;40m-=> Delphi Internet Jet SST v3.013A (Alpha) - (C) PBE

Chad Z. Hower

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to

Subject: Re: Borland to show 32 bit Delphi

>>My understanding of the Integer and Cardinal types is that they were


>>intended to be "generic" types, used when you wanted the best choice
>>for the hardware underneath, not when you cared what the specific
>>implementation was. When one cares about the specific implementation,
>>one should use the SmallInt and LongInt types.
>

>Yes, that is the picture NOW. However, I've been using BP for 9 years
>and this is NEW and it will cause lots of problems which could have
>*easily* been avoided.

And (respectfully) let me guess. A PC is the only thing you have
programmed on?

John Baima

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
> 1) Ever heard of search and replace?

Yes, but would that solve the problem? No. Can you figure out why?

> 2) Are you experienced? EVERY Pascal compilers INTEGER is SYSTEM
>specific.

Well, see this is the problem. I've got a couple hundred thousand
lines of TP code which will break (in some places) with this change.
Borland Pascal is not Pascal anyway and we are talking of Delphi.

> What you propose would make Delphi REALLY incompatible with the rest of
>the world. I suggest if you WANT 16 bit then use WORD as the DOCS specify it
>as.

Oh, is a Word now a 16 bit signed value? Is word size a constant
across different micro processors?

> INTEGER is NEVER guaranteed to be 16 bits.

No, but it has been for a long time.

-John Baima


John Baima

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
>>Yes, that is the picture NOW. However, I've been using BP for 9 years
>>and this is NEW and it will cause lots of problems which could have
>>*easily* been avoided.

> And (respectfully) let me guess. A PC is the only thing you have
>programmed on?

Actually, I started on IBM and CDC mainframes. I've also developed
software on a variety of UNIX boxes and taught college Pascal on DEC
minis. Is that enought?

-John


Russell Turpin

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
-*----
In article <qPoJwAb...@falcon.no>,

Hallvard Vassbotn <hall...@falcon.no> wrote:
> I take it for granted that it will be possible to write OCX by way of
> directly calls to OLE2 libraries and following MS standards, but it
> would be much more powerful if you could write OCXs the same way as we
> write componetnts today.

Yes. A "generate OCX" option.

> Many of the concepts are very similar in OCXs and VCL components:
> properties, methods etc. Would be very powerful to have a one-to-one
> mapping here.

It would be a great and much desired feature even if the mapping
were 85% to 93%.

Russell
--
The difference between genius and stupidity is that genius has its limits.
-- Albert Einstein

Don Beusee

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
mobe...@oslonett.no (Rune Moberg) writes:
> In article <3vlj9g$s...@druid.borland.com>,

> Steve Teixeira <stei...@borland.com> wrote:
> > type 16-bit size 32-bit size
> > ----------------------------------------
> > integer 16 32
> > word 16 16
> > smallint 16 16
> > cardinal 16 "31"
> > longint 32 32
>
> I still think a 32 bit word type is missing...?
> i.e.: a 32 bit unsigned integer would be nice.

Something the matter with longint? Actually Steve did not say if it was
signed or not.

Regards,
Don.


Ray Lischner

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
On 6 Aug 1995 01:41:44 GMT, Chuck Jazdzewski <cj...@borland.com> wrote:

>ben...@aol.com (Ben Z 23) wrote:
>>For those of you in the know who can tell me,
>>
>>Will 32 bit Delphi have Threads? How about OCX support?

>32 bit Delphi will support the Win32 calls for threads as well
>as the compiler extensions for thread local storage found in
>other compiled languages. Ole Controls (OCX's) are also going
>to be supported.

Will the VCL be thread-safe?

The VCL keeps its own global data, and a reference to a property can
result in changes to global variables. Thus, in a multi-threaded
environment, these global variables need mutual-exclusion protection.

For the VCL user, the only safe option is to protect every property
access and every method call, which is too unwieldy. Most of the VCL
is re-entrant, and only some parts need protection. Thus, I expect
that the VCL will contain the proper semaphores, and do the "right
thing" for us.
--
Ray Lischner (li...@tempest-sw.com)
Tempest Software, Corvallis, Oregon


Don Beusee

unread,
Aug 7, 1995, 3:00:00 AM8/7/95
to
JBa...@onramp.net (John Baima) writes:
> Well, see this is the problem. I've got a couple hundred thousand
> lines of TP code which will break (in some places) with this change.
> Borland Pascal is not Pascal anyway and we are talking of Delphi.

Then fix those "some places" and use smallint or word!

> > What you propose would make Delphi REALLY incompatible with the rest of
> >the world. I suggest if you WANT 16 bit then use WORD as the DOCS specify it
> >as.
>
> Oh, is a Word now a 16 bit signed value? Is word size a constant
> across different micro processors?

smallint is signed, if you really need signed. I suspect you don't, since you
are more concerned with the size of the word. But both are available in any
case.

> > INTEGER is NEVER guaranteed to be 16 bits.
>
> No, but it has been for a long time.

Thats because DOS & compilers did not keep up with the times. Portable
programs will not use integer in such a way that if its storage size increases
the program fails. You always want to check the manuals/help to make sure
you use types other than "integer" when you require that the storage size
to always remain the same.

Integer is always system specific, so get used to it, and program with that
in mind in the future. Use Word, LongInt, or SmallInt depending on your needs.
Use Integer if you use it in a way that size does not matter. Integer is the
quickest way to do array indexing and very simple math, etc., when run on
CPU's with that same native integer size.

> -John Baima

Regards,
Don.


Al Grabauskas

unread,
Aug 8, 1995, 3:00:00 AM8/8/95
to
Chuck Jazdzewski <cj...@borland.com> wrote:

>ben...@aol.com (Ben Z 23) wrote:
>>For those of you in the know who can tell me,
>>
>>Will 32 bit Delphi have Threads? How about OCX support?

>32 bit Delphi will support the Win32 calls for threads as well
>as the compiler extensions for thread local storage found in
>other compiled languages. Ole Controls (OCX's) are also going
>to be supported.

>Chuck Jazdzewski (cj...@borland.com)
>Delphi Development

i LIKE that answer. any other good stuff y'all can share?


Don Beusee

unread,
Aug 8, 1995, 3:00:00 AM8/8/95
to
hall...@falcon.no (Hallvard Vassbotn) writes:
> In <3vkh4n$g...@fenris.com> li...@tempest-sw.com (Ray Lischner) writes:
> >I would like to verify my assumptions about integers types in 32-bit
> >Delphi. According to the Object Pascal manual, Integer and Cardinal
> >will be 32 bits (or rather, Cardinal will be 31 bits...). Word will
> >continue to be 16 bits.
>
> >In other words, for maximum portability, we should be using Word for
> >unsigned integers that are truly 16 bits, and Cardinal for unsigned
> >integers that are the "natural" size for the environment. Similarly,
> >we should use SmallInt for signed integers that are 16 bits, Integer
> >for signed integers that are the natural size, and LongInt for signed
> >integers that must be 32 bits.
>
> >Is this correct?
>
> Yep, it is correct.

I'd like to know more about Cardinal storage. Steve says its 31 bits, but
what is done with the 32nd bit?

Regards,
Don.


Chuck Jazdzewski

unread,
Aug 8, 1995, 3:00:00 AM8/8/95
to

Well, like it has an optimizing compiler that produces code that
executes around 4 times faster than the 16 bit compiler (sieve,
etc) but still compiles as fast and links even faster. There
is going to be a lot of neat stuff in the next version.

Also, we gave a preview at the Borland Languages Conference,
maybe people that where there could give a summary of what they
saw... (being safer for me so I don't let something slip that
I wasn't supposed to..)

Chuck Jazdzewski

unread,
Aug 8, 1995, 3:00:00 AM8/8/95
to
li...@tempest-sw.com (Ray Lischner) wrote:

>On 6 Aug 1995 01:41:44 GMT, Chuck Jazdzewski <cj...@borland.com> wrote:
>
>>ben...@aol.com (Ben Z 23) wrote:
>>>For those of you in the know who can tell me,
>>>
>>>Will 32 bit Delphi have Threads? How about OCX support?
>
>>32 bit Delphi will support the Win32 calls for threads as well
>>as the compiler extensions for thread local storage found in
>>other compiled languages. Ole Controls (OCX's) are also going
>>to be supported.
>
>Will the VCL be thread-safe?
>
>The VCL keeps its own global data, and a reference to a property can
>result in changes to global variables. Thus, in a multi-threaded
>environment, these global variables need mutual-exclusion protection.
>
>For the VCL user, the only safe option is to protect every property
>access and every method call, which is too unwieldy. Most of the VCL
>is re-entrant, and only some parts need protection. Thus, I expect
>that the VCL will contain the proper semaphores, and do the "right
>thing" for us.

We are only committing publically to what I stated, we will support
the operating system API calls and the language extensions that
support threads.

That said, making VCL thread-safe is much harder than you make it
out to be. Every instance variable is essentially a "global
variable" with respect to its methods. So a change to any instance
variable would, in theory, need to be protected. If this was done
in general it would generate a lot of extra code to support threads.
This is a lot of code that many users would never need or use. But
this still doesn't solve the problem because every component writer
would have to do the same things to make their components thread-
safe. This would make component writing difficult to do so many
component writers won't do it right or at all. But, once one
component is not thread-safe then all components need to be assumed
to be non-thread-safe since you don't know when or where the
non-thread-safe component will be invoked since VCL passes a lot
of messages around and their is always that user out their dragging
the mouse around.

So we are looking at a number of solutions and partial solutions
to VCL and thread safety, but we won't commit to doing anything
about it. We need to walk a fine line that allows us to give most
of the benefit of thread safety without bloating the code nor making
it difficult on the component writer.

Rune Moberg

unread,
Aug 8, 1995, 3:00:00 AM8/8/95
to
In article <DCxnG...@cix.compulink.co.uk>,

tpi...@cix.compulink.co.uk ("Tim Pigden") wrote:
> Borland seem to be following the same practice that has applied to C for
> a very long time. Doing something else would be just as confusing to
> another part of the development community.

I feel that Pascal is percepted as an inferior language when compared
to C. Whenever this topic comes up, someone will effectively make the
statment that they use Pascal for the sissy stuff (user interface e.g.)
and C for the low-level hardware stuff. I think that's doing Turbo Pascal,
Borland Pascal and now Delphi great injustice. Borland Pascal can produce
tighter EXE files than C, and add more functionality at the same time.

Anyway, if "we" choose to do something different than what the C community
have been doing with their int type for years, then Pascal will definately
become a langauge mentioned in the same breath as BASIC. :-(

Ah... I had to get it off my chest...

Hallvard Vassbotn

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to

So the implication is that you can use threads as long as you don't use
any VCL code in those threads? The main program could still be written
using VCL, but the threads doing background processing (calculations,
network access etc.) must be non-VCL?

At least the heavy duty operations like database searching, queries etc
should support threading. That's the point of multitasking, right?

I wonder why Borland made it so difficult to make VCL thread-safe. After
all VCL was _designed_ primarily with Win95 in mind, wasn't it? One of
the main points in that design should be, IMHO, that threads should
be supported from ground-up.

Hallvard Vassbotn

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to
In <409emg$7...@news.cais.com> mos...@aed.aed.org (Moscow) writes:
>: what is done with the 32nd bit?

>: Regards,
>: Don.

>Tis' very easy.
>31 bits unsigned integer belongs to LongInt, which is the largest
>compatible integer type, 32bits doesn't

But he has a valid point. For instance what would happen here:

var
C: Cardinal;
begin
C := $FFFFFFFF; { Compile-time error or ok? }
{ Will the high bit implicitly be zeroed out? }
Writeln(C); { 4 bill or 2 bill? }
end.

Don Beusee

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to
mos...@aed.aed.org (Moscow) writes:
> : what is done with the 32nd bit?
>
> : Regards,
> : Don.
>
> Tis' very easy.
> 31 bits unsigned integer belongs to LongInt, which is the largest
> compatible integer type, 32bits doesn't

LongInt is 32 bits (32nd bit is the sign bit). My problem is that Steve said
cardinal is 31 bits. What does that mean? Is cardinal signed or not? If
not, why would it be limited to 31 bits and not use the 32nd bit for a 4gig
number instead of a 2gig number? There is no help page for cardinal, so how is
someone supposed to know it exists and what it does?

If its signed, whats the difference between it and Integer?

If its 16 bits now (and not 15 bits), why would it jump to 31 bits and not
32 bits? Can someone explain this?

Regards,
Don.


Moscow

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to
: what is done with the 32nd bit?

: Regards,
: Don.

Tis' very easy.
31 bits unsigned integer belongs to LongInt, which is the largest
compatible integer type, 32bits doesn't

;)

Gor Nishanov (go...@cs.msu.su)

Rick Rutt

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to
Hallvard Vassbotn <hall...@falcon.no> writes:

>Will it only support the usage of pre-written OCXs (à la the VBX support
>today) or will it include support for _writing_ your own OCXs? This is
>a cruical difference.
>
>I take it for granted that it will be possible to write OCX by way of
>directly calls to OLE2 libraries and following MS standards, but it would
>be much more powerful if you could write OCXs the same way as we write
>componetnts today.


Finally, more people are starting to "see the light" regarding
component-based software development, and are asking the right questions.
-
So has the "new" Borland seen the light yet?
-
The "old" Borland mapped .DLL development details very nicely into
high-level Pascal unit concepts, giving us the "Library" module.
Borland Pascal 7.0's ability to write .DLL's made anyone writing a
.DLL in C look like a masochist.
-
Now we need the "new" Borland to make writing OLE2 Automation components
(including OCX's) just as simple. The low-level details of OLE2 are
horrendous. However, the actual information content of an OCX definition
consists of Properties, Methods, and Interfaces (sets of Methods).
Map this "information content" to high-level Pascal, PLEASE!, and hide
the underlying gory details.
-
I have been trying to pry from the Visual Basic 4.0 beta testers whether
that product will allow development of OLE2 Automation components in
Visual Basic. Finally, one person has explicitly said it will.
One person does not make a product feature announcement, but it does
raise my hopes.
-
I view this as the key "arms race" between the 32-bit versions of
Visual Basic and Delphi. If one product allows development of
OLE2 Automation components within its own language, and the other
doesn't, then the war is over. The one that lets us develop
OCX's will be the winner. If BOTH allow this, then life in
corporate applications development will be interesting again!
-
You see, OLE2 Automation in a high-level language will allow the
analogy of creating "printed circuit boards", whereas the current
use of C++ for these items is analogous to creating the
"integrated circuit chips". We need both levels of detail.
-
The systems programmers with computer science degrees, etc. can
write the "integrated circuits", using C++ (and hopefully
Delphi).
-
The applications programmers (some also with computer science
degrees) need to be able to write the "circuit boards", hopefully
using Delphi, Visual Basic, or even Smalltalk. These will be used to
implement the "business objects" layers of client-server computing.
-
The 32-bit product releases this fall/winter will indicate if
we are truly ready for software development for the next millenium!

-- Rick
--

(Rick Rutt is a system architect living and working in Midland, Michigan.)

Moscow

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to
Don Beusee (dbe...@us.oracle.com) wrote:
: mos...@aed.aed.org (Moscow) writes:
: > : what is done with the 32nd bit?

: >
: > : Regards,
: > : Don.
: >
: > Tis' very easy.
: > 31 bits unsigned integer belongs to LongInt, which is the largest
: > compatible integer type, 32bits doesn't

: LongInt is 32 bits (32nd bit is the sign bit). My problem is that Steve said


: cardinal is 31 bits. What does that mean? Is cardinal signed or not? If
: not, why would it be limited to 31 bits and not use the 32nd bit for a 4gig
: number instead of a 2gig number? There is no help page for cardinal, so how is
: someone supposed to know it exists and what it does?

Don.

Cardinal is unisgned integer ranged from 0..2gigs.
It is subrange of LongInt which is -2gigs..+2gig.
If they made 32 cardinal, they would have two types with incompatible
ranges. 0..4gig (Cardinal) and -2gig..+2gig. It isn't convenient,
at least for compiler writers.

Gor

Ben Z 23

unread,
Aug 9, 1995, 3:00:00 AM8/9/95
to
<<So the implication is that you can use threads as long as you don't use
any VCL code in those threads? The main program could still be written
using VCL, but the threads doing background processing (calculations,
network access etc.) must be non-VCL?>>

I still think it should be relatively easy to create a ThreadForm. As
long as no other forms access its properties or methods (through
non-thread safe means) it should be safe, and *very* useful. Does that
sound reasonable, Borland?

-Ben

Ray Lischner

unread,
Aug 10, 1995, 3:00:00 AM8/10/95
to

That's a good example. Unless the VCL protects its internal data
structures, a programmer cannot create a simple application that has
two completely independent forms running in their own threads.

If I, as a programmer, create multiple threads and access the same
data in different threads, then it is my responsibility to protect
those variables. If the variables refer to objects, then I need to
protect all accesses to those objects.

If I create threads with completely independent variables and data,
then I should not have to add my own mutexes to access those
individual variables.

John Baima

unread,
Aug 10, 1995, 3:00:00 AM8/10/95
to
Steve Teixeira <stei...@borland.com> wrote:

>The current PC Week has an article about plans to demonstrate 32 bit Delphi in

How about Unicode? Will that be supported as part of the 32 bit
Delphi? It is part of the NT API--not sure about Win95. Will there be
a new string type or what?

-John Baima


Chuck Jazdzewski

unread,
Aug 10, 1995, 3:00:00 AM8/10/95
to
hall...@falcon.no (Hallvard Vassbotn) wrote:

[old stuff deleted ]

>So the implication is that you can use threads as long as you don't use
>any VCL code in those threads? The main program could still be written
>using VCL, but the threads doing background processing (calculations,
>network access etc.) must be non-VCL?

I think you mis-read my message. I don't mean to imply that you cannot
use threads and VCL. I just cannot promise it to you. We have a number
of solutions that we are looking at to make VCL "thread-aware". The point
of my message was that it is not as easy Ray made it out to be.

Chuck Jazdzewski

unread,
Aug 10, 1995, 3:00:00 AM8/10/95