Requested for IDE to support more RAM (vote/discuss if you care)

[A.M. Hoornweg 138]

1 minute ago, dummzeuch said:

That's not restricted to the Delphi IDE and packages though. Basically any DLL loaded into a process can do the same to that process.

(I'm not sure about dotNET in that respect though.)

Of course.  But I've seen many designtime packages of poor quality.  And certain packages that I have installed inn Delphi 11.3 cause the IDE to throw an exception when I close it. 

[A.M. Hoornweg 138]

2 minutes ago, Brandon Staggs said:

I cannot fathom the paradigm shift that would be. Well, I can fathom it, and I think it would be Delphi 8 all over again for them to introduce such a massive breaking change in concept and code. It would be nice if they could isolate the design-time packages enough to protect the IDE, but removing them from the IDE would eliminate one of Delphi's few core advantages over other systems. Whatever they change it to would also require the participation of everyone making packages, which is not going to happen.

One way to achieve isolation would be to load each package into a separate helper process. And yes, it would be a monumental breaking change.

[David Heffernan 2300]

1 hour ago, Brandon Staggs said:

I cannot fathom the paradigm shift that would be. Well, I can fathom it, and I think it would be Delphi 8 all over again for them to introduce such a massive breaking change in concept and code. It would be nice if they could isolate the design-time packages enough to protect the IDE, but removing them from the IDE would eliminate one of Delphi's few core advantages over other systems. Whatever they change it to would also require the participation of everyone making packages, which is not going to happen.

Wouldn't they ship 32 and 64 bit IDEs and users could choose which they used. You have to recompile packages for new versions anyway. It would just be a recompile for 64 bit. I don't think it would be so bad. I know that I can compile all the design time packages I use for 64 bit quite easily.

[Brandon Staggs 185]

2 hours ago, David Heffernan said:

Wouldn't they ship 32 and 64 bit IDEs and users could choose which they used. You have to recompile packages for new versions anyway. It would just be a recompile for 64 bit. I don't think it would be so bad. I know that I can compile all the design time packages I use for 64 bit quite easily.

Sure. Different issue than what my comment you were replying to is about. I was talking about removing design-time from the IDE, not a 64-bit IDE.

[David Heffernan 2300]

3 hours ago, Brandon Staggs said:

Sure. Different issue than what my comment you were replying to is about. I was talking about removing design-time from the IDE, not a 64-bit IDE.

OK, but it would obviously be far easier to just recompile than make some new out of proc add in tech for design time. 

[A.M. Hoornweg 138]

How do other IDE's handle design time support for third-party GUI elements?

[Brandon Staggs 185]

15 hours ago, David Heffernan said:

OK, but it would obviously be far easier to just recompile than make some new out of proc add in tech for design time. 

What I am saying is that any technology change in the IDE that decouples design-time components from the IDE process is going to require people who make packages to adapt to those changes. Maybe that really could be as simple as a recompile. If so, that would be a credit to the designers at Embarcadero, and I would love to see it. I just don't have that confidence. I guess what I am saying on all this is that I fear any "big changes" to the IDE being made at this time. Even the small improvements they make seem to come with big side helpings of bugs. 

 

Theoretically, a 64-bit IDE should not be too bad, since they enabled large address awareness in it many years ago.  That should have allowed any pointer<>integer bugs to have been sniffed out by now, so 64-bit should be doable. I personally question the need for it, but if people are experiencing legitimate out-of-memory errors in the IDE, then it is obviously needed. My multi-million LOC projects don't bring down the IDE because of memory availability, but if they did, I would be singing a different tune.

[dummzeuch 1392]

9 minutes ago, Brandon Staggs said:

Theoretically, a 64-bit IDE should not be too bad, since they enabled large address awareness in it many years ago.  That should have allowed any pointer<>integer bugs to have been sniffed out by now, so 64-bit should be doable.

Unfortunately they (Borland? Or was it already Embarcadero?) decided, to keep Integer a 32 bit data type rather changing it to the same bitness as Pointer. So even with large address awareness this leaves a lot of room for compile and runtime errors. They even managed to make a mistake in the declaration of NativeInt in Delphi 7 to 2007 where it was 64 bit rather than 32 bit, even though the compilers were all 32 bit back then.  OK, that's ancient history, but the fact that Integer is still 32 bit remains.

[David Heffernan 2300]

1 hour ago, dummzeuch said:

Unfortunately they (Borland? Or was it already Embarcadero?) decided, to keep Integer a 32 bit data type rather changing it to the same bitness as Pointer. So even with large address awareness this leaves a lot of room for compile and runtime errors.

This wasn't a mistake. This reflects the underlying platform. 

 

It's wrong to blame Emba for all the programmers using Integer as though it was pointer sized. 

 

Your argument is akin to wanting char to be 4 bytes on 64 bit. It's just a non sequitur. There's literally no reason for integer to be pointer sized. It's a completely different thing. 

Edited June 14, 2023 by David Heffernan

[Brandon Staggs 185]

1 hour ago, dummzeuch said:

Unfortunately they (Borland? Or was it already Embarcadero?) decided, to keep Integer a 32 bit data type rather changing it to the same bitness as Pointer.

I don't see why that's a mistake. An integer is not a pointer.

[dummzeuch 1392]

1 hour ago, David Heffernan said:

2 hours ago, dummzeuch said:

Unfortunately they (Borland? Or was it already Embarcadero?) decided, to keep Integer a 32 bit data type rather changing it to the same bitness as Pointer. So even with large address awareness this leaves a lot of room for compile and runtime errors.

This wasn't a mistake. This reflects the underlying platform. 

It might not have been a mistake, but it did make it harder to port code that assumed that Integer and Pointer have the same size from 32 bit to 64 bit. That's all I said.

[Brandon Staggs 185]

20 minutes ago, dummzeuch said:

It might not have been a mistake, but it did make it harder to port code that assumed that Integer and Pointer have the same size from 32 bit to 64 bit. That's all I said.

In my opinion, the only unfortunate thing here is that developers we shortsighted enough to treat integers and pointers as interchangeable. I am guilty of having done this 20 years ago myself, but keeping integer bitness consistent with the platform was not an "unfortunate" choice on the part of Embarcadero developers. Having said that, you are undoubtedly correct that this will cause issues when they finally decide to ship a 64-bit IDE, because no doubt, they have made the same bad choices in the past. However, the kinds of bugs that show up because of that do start to become evident with large address awareness, so maybe they are past that issue now.

[David Heffernan 2300]

5 hours ago, dummzeuch said:

It might not have been a mistake, but it did make it harder to port code that assumed that Integer and Pointer have the same size from 32 bit to 64 bit. That's all I said.

The alternative that you propose would have been far worse. 

[A.M. Hoornweg 138]

16 hours ago, dummzeuch said:

It might not have been a mistake, but it did make it harder to port code that assumed that Integer and Pointer have the same size from 32 bit to 64 bit. That's all I said.

Persisting data through records, files and streams etc would instantly become incompatible with existing software if the size of a common data type like "integer" changes. 

 

[David Heffernan 2300]

10 minutes ago, A.M. Hoornweg said:

Persisting data through records, files and streams etc would instantly become incompatible with existing software if the size of a common data type like "integer" changes. 

 

So yeah, which would have been harder? Changing all such records to use a type other than Integer, or changing all incorrect Pointer/Integer casts?

[A.M. Hoornweg 138]

Changing all incorrect pointer/integer casts is infinitely easier because the compiler tells us that the typecast is invalid at compile time.   

 

[edit] Having said that, I don't usually use the "tag" property of tcomponent etc anymore.  It is much more convenient to use a tDictionary<tObject,tSomethingelse> to figure out if an object is associated with something else.

Edited June 15, 2023 by A.M. Hoornweg

[David Heffernan 2300]

37 minutes ago, A.M. Hoornweg said:

Changing all incorrect pointer/integer casts is infinitely easier because the compiler tells us that the typecast is invalid at compile time.   

Well yes. It was more of a rhetorical question aimed at Thomas. 

[dummzeuch 1392]

2 hours ago, A.M. Hoornweg said:

Persisting data through records, files and streams etc would instantly become incompatible with existing software if the size of a common data type like "integer" changes.

If the number of bits of an integer type matters, don't use Integer, use SmallInt, ShortInt, LongInt and Int64 (and Byte, Word, LongWord and UInt64).

But yes, I see the problem. I am as culpable as anybody else of assuming Integer to be 32 bits and it has bitten me several times when I had to make some changes to an old Borland Pascal DOS program, where Integer is 16 bit. Since then I have been changing data types to (U)Int8, (U)Int16, (U)Int32 and (U)Int64 in records, where the size matters, whenever I come across them. I also add some assertion code as to the size of these records to the initialization section of the unit that declares them.

 

(Yes, we use a lot of these records, the original software was written for DOS and used file of record for everything. We have switched to a self describing file format now that has a header describing the record structure (based on a mechanism described in "Tomes Of Delphi"). And before anybody asks: No, databases are not an option, even DBase is too slow.)

 

But I digress ...

[A.M. Hoornweg 138]

12 minutes ago, dummzeuch said:

If the number of bits of an integer type matters, don't use Integer, use SmallInt, ShortInt, LongInt and Int64 (and Byte, Word, LongWord and UInt64).

But I digress ...

 

Do I have a surprise for you...  Longint is platform dependent.  Integer is now reliably 32-bit on all 32 and 64 bit platforms but not on ancient 16 bit platforms.

 

 

[dummzeuch 1392]

25 minutes ago, A.M. Hoornweg said:

Longint is platform dependent.

Yeah, I kind of knew that, I guess. It came up in a different discussion on a similar topic. That's why I use (U)Int(Len) types everywhere which are declared as being the correct length and also checked by an assertion. Apart from that, with names like these, it's clear what they are. (UInt32 = Cardinal which AFAIK is always 32 bit unsigned).

 

Until somebody comes up with the great idea to change Int64 to be 128 bit for "compatibility reasons".... I guess I'll no longer be around by then and hope that there will be a mob to lynch that person.

[Uwe Raabe 1888]

33 minutes ago, A.M. Hoornweg said:

Longint is platform dependent.

For reference see Platform-dependent integer types

Edited June 15, 2023 by Uwe Raabe

[David Heffernan 2300]

2 hours ago, A.M. Hoornweg said:

 

Do I have a surprise for you...  Longint is platform dependent.  Integer is now reliably 32-bit on all 32 and 64 bit platforms but not on ancient 16 bit platforms.

 

 

Not on all delphi versions, IIRC. If you want a 32 bit integer then there are types for that. FixedInt and FixedUInt. 

 

The whole point of Integer is that it maps to the platform's C int. 

[Brian Evans 83]

I also think Delphi should transition to a 64 bit IDE so it works better with large projects. As well with high entropy ASLR it could make it easier to find memory bugs in the IDE/plugins/design time components as most addresses would be invalid vs valid when the IDE uses a lot of memory. The breaking change of the IDE not running on 32 bit operating systems is a non-issue at this point. 

 

I have no problem with components living / running in the IDE. Perhaps Embarcadero could pay to get a component development guide updated or written along with some helpful tooling / debugging support to help revive wider 3rd party component production. 

[Lars Fosdal 1732]

On 6/13/2023 at 4:12 PM, Brandon Staggs said:

I couldn't find anything in their documentation suggesting it is deprecated. Can you point me to that? Here's what I did find:

It is more a defacto observation - since MDI window styling doesn't happen in Windows 10 and 11.

Ref. https://github.com/dotnet/winforms/issues/3691 which has a series of interesting comments.
So - given it has been like this for 10 years - is it likely to be fixed?

[Brandon Staggs 185]

6 hours ago, Lars Fosdal said:

So - given it has been like this for 10 years - is it likely to be fixed?

I would think not, though for me this is not really what "deprecated" means (not that I want to split hairs; I get what you are saying now). And bringing this back around to my original comment, I am surprised that Embarcadero is spending time on MDI when clearly MS is not. Perhaps they see this as a way to make Delphi stand out a bit-- you can have styling on MDI Windows with Delphi. I guess? My original theory was that they have someone with a fat subscription contract that is demanding the feature. :-)