Borland to show 32 bit Delphi
Duncan Murdoch
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
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
Thanks.
-tommy
Steve Teixeira (stei...@borland.com) wrote:
: -Steve Teixeira
: stei...@borland.com
--
Duncan Murdoch
>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
>>'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
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
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
>32-bit Windows NT>>applications if the code doesn't specifically call Windows
>95 features, said Zack Urlocker, group>>product manager for Delphi.'
>
>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
Steve Teixeira
>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. '
>
>>applications if the code doesn't specifically call Windows 95 features, said Zack Urlocker, group
>>product manager for Delphi.'
>
>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
>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
>
>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
>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.
>
>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
>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
>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
>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
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
>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
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
>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
>>>>'"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
>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:
>
>compiler have produced applications that are three to four times faster
>thanthe 16-bit version, he said. '
Do you think it will run under OS/2?
Steve.
Rune Moberg
Steve Teixeira <stei...@borland.com> wrote:
> type 16-bit size 32-bit size
> ----------------------------------------
> integer 16 32
> 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
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
--
* 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
Will 32 bit Delphi have Threads? How about OCX support?
Thanks in advance,
-Ben
jmm...@nando.net
> 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
>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
>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
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
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.
>
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
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
> >>>'"Our No. 1 design aim was full compatibility with the shipping product,"
>
>
> >type 16-bit size 32-bit size
> >----------------------------------------
> >integer 16 32
> >word 16 16
> >smallint 16 16
> >cardinal 16 "31"
> >longint 32 32
>
> > -Steve Teixeira
>
> 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
In article <402h0v$l...@inet-nntp-gw-1.us.oracle.com>,> 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
<<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
>>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
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
>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
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
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
>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
>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
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
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
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
>>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
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
> In article <3vlj9g$s...@druid.borland.com>,
> Steve Teixeira <stei...@borland.com> wrote:
> > type 16-bit size 32-bit size
> > ----------------------------------------
> > integer 16 32
> > smallint 16 16
> > cardinal 16 "31"
> > longint 32 32
>
> 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
>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
> 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
>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
> 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
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
>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.
>
>
>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
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
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
>: 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
> : 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
: 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
>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.
>
>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.
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
: 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
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
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
>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
[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
We have added several new types to support Unicode.
Francis Pauwelyn
>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
>=====
Since I'm constantly looking for a good OS/2 pascal compiler ...
Where can I find Virtual Pascal for OS/2 ???
Francis Pauwelyn
>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!
You probably don't know, but you CAN write VBX's in both TPW, Borland
Pascal and Delphi. If you don't know how, try to get a back issue of
the PASCAL Magazine (I think it was in issue 5)
Russell Turpin
In article <40ddea$7...@ping1.ping.be>,
Francis Pauwelyn <Francis....@ping.be> wrote:
> You probably don't know, but you CAN write VBX's in both
Of course. Just as they can be written in C or C++. But this
misses the point.
Components (whether packaged as VBX's, OCX's, or Delphi
components) are a significant new way to reuse software.
Currently, creating a component is much like programming a GUI
application used to be prior to visual development environments.
Component programmers have to learn a fairly complex API and work
with a not-too-friendly debugging environment. This is NOT due
to the inherent CONCEPTUAL complexity of component writing, but
due to the weakness of current development environments and the
presence of multiple standards.
Delphi is an example of what COULD BE a great environment for
making components. Imagine ... you begin with an instance of the
desired base component. You add code that provides the special
functions you want in your component. You embed it in an
application that lets you test this new component. (So far, this
is all just Delphi programming.) You hide some properties, and
add some new properties and events USING THE VISUAL ENVIRONMENT.
(This would be new.) And when your component works the way you
want, you select the component, pull down the Compile menu, and
choose the "Export as OCX" option. (Ta-da!)
THAT is what people want to build components and what this
discussion is about. We all recognize that Delphi can be used as
a Pascal compiler, and that Pascal is a general-purpose programming
language. That does NOT make Delphi a component-construction
environment.
Rick Rutt
>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?
API functions that convert to and from Unicode.
Steve Teixeira
>
>Something the matter with longint? Actually Steve did not say if it was
>signed or not.
>
AFAIK, longint isn't changing.
-Steve Teixeira
stei...@borland.com
l...@polaris.net
: > INTEGER is NEVER guaranteed to be 16 bits.
: No, but it has been for a long time.
How about an "Integer = 16 bits" switch? Some developers have to share
their code between DOS & Windows, and this seems like a pretty big
transition. Of course, if there *were* BP32 for DOS, it wouldn't matter
anymore . . .
This probably won't work, right? :-)
type
Integer = Smallint;
Don Beusee
> 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.
Seems to me its more inconvenient not to have 0..4gigs range. You did not
explain the sizeof(Cardinal)... Is it 31 or 32? Is 32nd bit there, but not
used? How come 16 bit cardinal is 16 but 32 bit is 31?
Regards,
Don.
Steve Teixeira
>Steve Teixeira <stei...@borland.com> wrote:
>
>>The current PC Week has an article about plans to demonstrate 32 bit Delphi in
>
>Delphi? It is part of the NT API--not sure about Win95. Will there be
>a new string type or what?
>
Since Delphi32 will provide you access to the entire Win32 API, yes, UNICODE will
be supported.
-Steve Teixeira
stei...@borland.com
Don Beusee
>dbe...@us.oracle.com (Don Beusee) wrote:
>
>|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.
>
>
>even Pascal - it is Borland Pascal (underneath the wrappers). Integer
>has always been 2-bytes in Borland (Turbo) Pascal. I Quote:
>
> "Integers are whole numbers; in Turbo Pascal limited to a range of
>-32768 through 32767. Integers occupy two bytes in memory."
>
> [from "Turbo Pascal Reference Manual" for CP/M-80, CP/M-86 and
>MS-DOS, copyright 1983]
>
>You can argue the advantages of changing this. but it is a change to a
>long tradition.
Funny you should quote a manual 12 years old. 12 years is a long time to
keep it the same, but then DOS is barely older than that. Now times are
changing - to Win/95 - 32 bit era - FINALLY!!!! It is LONG overdue...
DOS is a 16 bit O/S, since birth, and we are finally moving to a 32 bit O/S.
Having the experience of OTHER operating systems which have not been so
stagnant, we know the true nature of the majic word "Integer" in programming
languages as C, Pascal, Basic, etc.
Even the C language on all unix platforms are different between them.
Programming with portability in mind means not depending on int's being the
same size.
Think of this as moving to a new platform. After all, you are: from DOS to
Win/95. From a 16 bit architecture to a 32 bit one.
The changes are for the better, even if its not 100% portable. You just have
to trust me on this.
Yes, it should have been documented that the size and value range of Integer
is platform specific.
I am only disappointed that the String type has been stagnant since the days
of 8 bit. :-( The price of this is its serious limitation max len of 255.
Good thing Basic did not stay stagnant with its strings.
Regards,
Don.
pgr...@interaccess.com
|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.
Spoken line a true C programmer. Delphi is not C - it is not quite
even Pascal - it is Borland Pascal (underneath the wrappers). Integer
has always been 2-bytes in Borland (Turbo) Pascal. I Quote:
"Integers are whole numbers; in Turbo Pascal limited to a range of
-32768 through 32767. Integers occupy two bytes in memory."
[from "Turbo Pascal Reference Manual" for CP/M-80, CP/M-86 and
MS-DOS, copyright 1983]
You can argue the advantages of changing this. but it is a change to a
long tradition.
Phil
The earth is populated by scientists who practice the art
of infallibility, and non-scientists who are taken in by it.
(with credit to whoever I copied it from)
John Baima
>Since Delphi32 will provide you access to the entire Win32 API, yes, UNICODE will
>be supported.
That's the right answer. I was part of the Unicode/ISO 10646 BITNET
wars in the dark ages and I've been dying to be able to use Unicode
for a long time (I was on the Unicode side). Please sign me up
yesterday :-)
You did not mention what new string type and string functions would be
provided.
-John Baima
Steve Teixeira
I think Chuck J. mentioned that there would be new wide string and char types.
-Steve Teixeira
stei...@borland.com
Steve Teixeira
>In article <40fu18$r...@druid.borland.com>,
>Steve Teixeira <stei...@borland.com> wrote:
>>dbe...@us.oracle.com (Don Beusee) wrote:
>>>I am only disappointed that the String type has been stagnant since the days
>>>of 8 bit. :-( The price of this is its serious limitation max len of 255.
>>>
>>
>>week. They can contain up to 2 or 4 gigs (don't remember which off the top of my head)
>>of characters, the memory for them is automatically managed, and -- best of all -- when
>>you need to use one as a PChar, all you need to do is typecast.
>>
>
>Way to go!
>
>This is a great much needed feature. Can I ask if the new strings are
>compatible with the onld string functions, such as +, pos, copy etc..
>
Of course, you'll still be able to use the old string functions you know and love.
-Steve Teixeira
stei...@borland.com
Ron Loewy
Steve Teixeira <stei...@borland.com> wrote:
>
>Of course, you'll still be able to use the old string functions you know and love.
That's great news. It's going to be a drag&drop replacement for some of
my parsing code. Cool. <g>
Thanks for the answer.
Ron.
--
Ron Loewy, HyperAct, Inc. +1 (319) 351 8413 | rlo...@hyperact.com
Author of HLPDK/PA, CatMake, Interactive Help and PASTERP.
Visit our home page at http://www.hyperact.com .
Steve Teixeira
>I am only disappointed that the String type has been stagnant since the days
>of 8 bit. :-( The price of this is its serious limitation max len of 255.
>
We demonstrated the new long strings (ANSIStrings) provided in Delphi32 at BDC this
week. They can contain up to 2 or 4 gigs (don't remember which off the top of my head)
of characters, the memory for them is automatically managed, and -- best of all -- when
you need to use one as a PChar, all you need to do is typecast.
-Steve Teixeira
stei...@borland.com
Ron Loewy
Way to go!
This is a great much needed feature. Can I ask if the new strings are
compatible with the onld string functions, such as +, pos, copy etc..
Thanks,
Hallvard Vassbotn
>hall...@falcon.no (Hallvard Vassbotn) wrote:
[old stuff deleted]
>>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.
>You probably don't know, but you CAN write VBX's in both TPW, Borland
>Pascal and Delphi. If you don't know how, try to get a back issue of
>the PASCAL Magazine (I think it was in issue 5)
Yes, I know that VBXs can be written in BP. I have all the Pascal Magazine
issues. My point is that there is no specific support for it. You have
to do all the nitty gritty details yourself.
Using a VBX in Delphi, on the other hand, is very easy. You just install
it and Delphi will write and compile a wrapper VCL component for it
automatically. I guess the support for using OCXs will be similar.
Writing OCXs yourself is another story, though. If Delphi32 would support
writing OCXs in a similar way that we write VCL-components today it
would really be a quantum leap in component programming!
Hallvard Vassbotn
>type
> Integer = Smallint;
No, but you can do it the other way around for BP/TP/TPW compilation
of your code:
{$IFNDEF VER80}
type
SmallInt = Integer;
{$ENDIF}
Now use SmallInt whenever you want a 16-bit integer.
Vince Risi
tur...@cs.utexas.edu (Russell Turpin) wrote:
>Of course. Just as they can be written in C or C++. But this
>misses the point.
>Components (whether packaged as VBX's, OCX's, or Delphi
>components) are a significant new way to reuse software.
>Currently, creating a component is much like programming a GUI
>application used to be prior to visual development environments.
>Component programmers have to learn a fairly complex API and work
>with a not-too-friendly debugging environment. This is NOT due
>to the inherent CONCEPTUAL complexity of component writing, but
>due to the weakness of current development environments and the
>presence of multiple standards.
If it was hard to write then it must be hard to use?
>Delphi is an example of what COULD BE a great environment for
>making components. Imagine ... you begin with an instance of the
>desired base component. You add code that provides the special
>functions you want in your component. You embed it in an
>application that lets you test this new component. (So far, this
>is all just Delphi programming.) You hide some properties, and
>add some new properties and events USING THE VISUAL ENVIRONMENT.
>(This would be new.) And when your component works the way you
>want, you select the component, pull down the Compile menu, and
>choose the "Export as OCX" option. (Ta-da!)
Delphi is a great environment for making Delphi components.
Please explain to me the importance of OCXs.
Why would I want to use them?
Are we not already suffering from an overabundance of DLLs, VBXs
and such? (Last time I looked at my Windows directory I nearly
puked).
>THAT is what people want to build components and what this
>discussion is about. We all recognize that Delphi can be used as
>a Pascal compiler, and that Pascal is a general-purpose programming
>language. That does NOT make Delphi a component-construction
>environment.
Delphi is a component construction environment for Delphi.
What else is there worth using to program Windows?
|| \
=== |
|| /
Vince
=====
Russell Turpin
In article <y/+Kwg2yqf...@iaccess.za>,
Vince Risi <vin...@iaccess.za> wrote:
> Delphi is a component construction environment for Delphi.
> What else is there worth using to program Windows?
One does not convert customers by telling them what to buy.
One converts customers by selling them what they currently
want, and letting them see THROUGH THAT the better route
that one has.
Larry Kilgallen
Should a hexidecimal value of FF00FF00 in my_integer be equal to a
hexadecimal value of FF00FF00 in my_cardinal ? I think not. Setting
the range of Cardinal to use only 31 bits certainly solves that issue.
You might say that Borland took the "easy way out" and could generate
many machine instructions to range check the Cardinal before comparing
it to the Integer, but others might prefer tighter machine code.
I have no idea whether the above is Borland's reasoning, but I do
know that Borland's decision matches the decision made for the Ada
programming language by the body which interprets the Ada standard.
I feel happier when a Pascal implementation behaves like another
strongly typed language (Ada) than when it behaves like C*.
Larry Kilgallen
Rune Moberg
Steve Teixeira <stei...@borland.com> wrote:
> >This is a great much needed feature. Can I ask if the new strings are
> >compatible with the onld string functions, such as +, pos, copy etc..
Oops... I guess I just got punished for using somestring[0] instead of
Length(somestring)... :-) Speaking of which, how are you supposed to
set the length of the bugger anyway? Is newstring[0] a longint now?
(Steve, I'd love a preview version of Delphi! I could kill for it, perhaps
even cut my hair for it! :-) )
=\
*=- R.Moberg, author of CD-Player Pro! ftp.cica.indiana.edu:
=/ /win3/sounds/cdppro45.zip
Vince Risi
tur...@cs.utexas.edu (Russell Turpin) wrote:
>-*-----
>In article <y/+Kwg2yqf...@iaccess.za>,
>Vince Risi <vin...@iaccess.za> wrote:
>> Delphi is a component construction environment for Delphi.
>> What else is there worth using to program Windows?
>One does not convert customers by telling them what to buy.
>One converts customers by selling them what they currently
>want, and letting them see THROUGH THAT the better route
>that one has.
You can fool some of the people all of the time.
You can fool all of the people some of the time.
But you cant fool all of the people all of the time.
Vince
=====
Chuck Jazdzewski
>In article <40fu18$r...@druid.borland.com>,
>Steve Teixeira <stei...@borland.com> wrote:
>>dbe...@us.oracle.com (Don Beusee) wrote:
>>>I am only disappointed that the String type has been stagnant since the days
>>>of 8 bit. :-( The price of this is its serious limitation max len of 255.
>>>
>>
>>We demonstrated the new long strings (ANSIStrings) provided in Delphi32 at BDC this
>>week. They can contain up to 2 or 4 gigs (don't remember which off the top of my head)
>>of characters, the memory for them is automatically managed, and -- best of all -- when
>>you need to use one as a PChar, all you need to do is typecast.
>>
>
>Way to go!
>
>compatible with the onld string functions, such as +, pos, copy etc..
Yes. They are. We tried to make the transition as transparent as possible.
Most code will convert straight across with no changes. Other will have
to be modified slightly depending on how much they depended on the physical
layout of the string.
Rob J. Nauta
>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.
>It is called writing portable code. The definitions of types has been around
>for longer then Delphil.
Indeed, if the word length was important, eg. for a system or vcl call,
one shouldn't have been using integer anyway. Integer's machine-dependent
and unless it's code from the 8088 days, programmers should have known
about 32-bits code.
Rob
--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Rob J. Nauta r...@redwood.nl
NOTE: my opinions are strictly my own and not those of my employer
Rick Rutt
>Delphi is a great environment for making Delphi components.
>Please explain to me the importance of OCXs.
>Why would I want to use them?
programmers.
-
.VBX's and .OCX's are binary-level components, usable by any user with
any programming/scripting tool.
-
If you write a Delphi application as a binary component, you now have a
larger market: both Delphi and non-Delphi believers can buy and use your
product.
-
Also, large corporate applications rarely involve only a single programming
language. Even if a single language provides the necessary features,
you have version control and "schema evolution" issues with older subsystems
that were written before that language was chosen.
-
In the character-cell terminal and minicomputer days, Digital make a bold
move in specifying the VAX Calling Architecture. This was the first,
and still is the only, environment where a routine in ANY programming language
can call another routine in ANY OTHER programming language and be linked
into a single executable image.
-
The OLE (and hopefully OpenDoc) binary-component models finally promise to
bring a similar flexibility to the microcomputer era.
Malcolm Coulter
>From: Chuck Jazdzewski <cj...@borland.com>
>Subject: Re: Borland to show 32 bit Delphi
>Date: 14 Aug 1995 16:44:56 GMT
[with cuts]
<<We demonstrated the new long strings (ANSIStrings) provided in Delphi32 at
BDC this week. They can contain up to 2 or 4 gigs (don't remember which off
the top of my head) of characters, the memory for them is automatically
managed, and -- best ofall -- when you need to use one as a PChar, all you
need to do is typecast.>>
<<This is a great much needed feature. Can I ask if the new strings are
compatible with the onld string functions, such as +, pos, copy etc..>>
<<Yes. They are. We tried to make the transition as transparent as possible.
Most code will convert straight across with no changes. Other will have
to be modified slightly depending on how much they depended on the physical
layout of the string.>>
-----------------------------------------------------------------
This is indeed great news!
However, we have a lot of legacy code that assumes the length-byte/char-array
structure in order to pack stings. It would help me to know if
"ANSIString" is a new type with "string" still 255 chars
or
are all "string" definitions of the new structure?
If the latter, it would have been nice to have a shortstring type with the old
structure - its much easier, and safer, to change var statements than to check
through all uses of a string to see that it is not affected.
And what about "widestrings"?
Steve Teixeira
Vince Risi
>Vince Risi <vin...@iaccess.za> writes:
>
Let me rephrase my question.
Will OCXs deliver the goods for open components, or is the complexity
of creating and using them to great? Look at VBXs and DLLs. Do you
know how may DLLs and VBXs you have cluttering up your machine?
I would like to see VCLs become exportable (preferably as static
libraries rather than dynamic libraries (I hate suprises)).
Also who is actively using OCXs at the present moment? Is this
just another vapour trail in the disinformation saga?
Vince
=====
Chad Z. Hower
Subject: Re: Borland to show 32 bit Delphi
>as the compiler extensions for thread local storage found in
>other compiled languages. Ole Controls (OCX's) are also going
>to be supported.
How about support for DEVELOPMENT of OCX controls?
_
"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
Subject: Re: Borland to show 32 bit Delphi
>>People who had always been careful not to
>>make assumptions about the sizes of types, i.e. those who had religiously us
>>"sizeof", would be unnecessarily penalized.
>
>Sorry, but this is not true either. What if you use Integers in file
>records like I do?
The DON'T use integers. Use Small Ints.
Again, it is all documented, so if it breaks your programs, it is not
Borland's fault.
>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.
And thus you have answered your own question. The need for the varying
integer size.
It seems to me that even you now realize you should have been using
Small Ints and INTEGER from the start, and not just INTEGER.
>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.
They are not redefining them. LOOK in the docs.
Chad Z. Hower
Subject: Re: Borland to show 32 bit Delphi
>>> 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.
That's not very encouraging.
Chad Z. Hower
Subject: Re: Borland to show 32 bit Delphi
>> 1) Ever heard of search and replace?
>
>Yes, but would that solve the problem? No. Can you figure out why?
Yes. You used INTEGER where some spots it is system specific, and other
spots it is not.
Respectfully, it sounds like your own fault here.
>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.
So since it is not ANSI Pascal, we should make it as incompatible as
possible so a mistake you made will not cause you grief?
>> INTEGER is NEVER guaranteed to be 16 bits.
>
>No, but it has been for a long time.
Only in your Windows programming. And it still was not guaranteed.
pgr...@interaccess.com
| The DON'T use integers. Use Small Ints.
| Again, it is all documented, so if it breaks your programs, it is not
|Borland's fault.
| It seems to me that even you now realize you should have been using
|Small Ints and INTEGER from the start, and not just INTEGER.
| They are not redefining them. LOOK in the docs.
I can resist no longer. What world do you come from? Certainly not
Borland Pascal, which is what Delphi is! Small Ints did not exist in
Borland Pascal, and integers have been defined as being 2 bytes for 12
years by Borland.
It may now be time to change but it is a major change!
Phil
The earth is populated by scientists who practice the art
of infallibility, and non-scientists who are taken in by it.
(with credit to whomever I copied it from)