Leaderboard

I think it could have been better worded - it's not that there are different levels of beta testers as such. It's more that the betas are released to a progressively wider audience. Early betas are generally released to a hand-picked cadre of users who either have a very specific situation which has a significant bearing on elements of the beta or are long-term 'advanced' users such as MVPs along with key tech partners. As the betas become more stable that audience is widened to more people who can receive value from a beta which while useful might still have potential instabilities which some could find challenging. This iterates with a wider and widening group until we begin to roll out to a broader general audience such as key accounts and known large projects, culminating in a general beta which goes out to people who have a maintenance subscription. There are different types of forums where the level of engagement is tempered to suit the type of beta customer. For example, MVPs often discuss things of a very esoteric technical nature with a more profoundly explicit type of conversation which, while entirely professional, might be more akin to a collection of colleagues and friends discussing a SNAFU in a particularly blunt way. These kinds of conversations don't sit so well among conversations with, perhaps, a 'regular' customer who is merely trying to see if the new beta solves an issue they have had with their project. I want to emphasize that this is not to bring about a kind of elitism and I try *really* hard for Embarcadero to be approachable by anyone - and I do get emails from all sorts of people, so I think that message is starting to be understood. I am here, I am listening. We are listening. The differentiation is more to ensure the level of interaction is appropriate for the expectations of the persons participating. MVPs are chosen for a multitude of reasons. Tech Partners are also the same - and some MVPs work for Tech Partners, but many Tech Partners do not have that kind of relationship with us. The same is true of customers who are neither MVPs or TPs and are trying out the beta thanks to their maintenance subscription. Administering the betas such as managing the beta keys and validating the requests to join the beta can be an intensely onerous experience which can place demands on internal staff at a time when they are already working close to capacity preparing for the eventual full release. Because of that, and in recognition that a valid premium or maintenance subscription should bring additional benefits such as access to betas, our current preference is not to simply push out a beta to one and all. We are also constrained by legalities such as getting sign-off on sub-licensed materials, EULAs, ensuring any OSS is properly credited and made available. That's not even an exhaustive list of what has to be done. We obviously want to ensure that as many people as practical can participate in the beta because the more that try it the more likely we are to shake out bugs or other issues before we release to GA - but we also do not have unlimited resources and we simply cannot currently let everyone on the planet join the beta. I know not everyone agrees. We are trying to listen more and more to your feedback, good or bad - we want to know the whole truth - because that's the best way to give you what you want and to make RAD Studio a product you love, and which genuinely adds value to your work. I promise you that everyone I work with is remarkably passionate about creating and sustaining a quality product that you will keep on choosing to create applications that help you achieve your goals and successes too. Ian.

That is perfectly OK. Especially if Embarcadero knows that this person/company is using Delphi certain way, change possibly breaks it or makes better, let them test first etc... That is smart I think. Beta should be, at first for small group of people, to keep amount of messages and bugreports at bay etc... I was referring to the communication channel/channels to take full advantage of the Public Beta. Also if there would be private repository for Beta testers of open code that is ready for the future release. Would make testing with everyone's own products faster and more efficient.

You will have to roll your own file picker or simply display something like "Sorry, this file is not allowed" if it's not in the correct directory. Windows regular file picker does not stop the user from entering an absolute path, following shortcuts, drag & dropping files, copying & pasting, ... the list goes on.

11.3 works well on WfW for ARM under Parallells on my MBP M1 Pro.

Personally I wouldn't buy Windows ARM because incompatibilities. 20 hours without charge is nice but is not a must have for me.

Not sure ARM will avoid the fate of the Motorola 68000 and PowerPC when going against x86 head on. The size of the full x86 ecosystem means there is much more money for processor development so that even when a competitor gets in a few wins it often falls behind over time. ARM has racked up some solid wins due to circumstances that are changing - x86 is no longer stalled by AMD (Bulldozer) or Intel (14nm) with both now making solid progress. Apple added support for the x86 memory access model to the M1/M2/M3 processors which makes running multi-core x86 emulation much easier and higher performing. This means during Apple's transition to ARM the latest x86 based Mac software runs well on the new M1/M2/M3 hardware. Since no other ARM systems currently have anything equivalent it means the latest Windows x86 software will run comparatively poorly on an ARM based system. That makes any transition or even just fielding Windows ARM systems harder as some programs will fare poorly. Apple has really aced the transition to ARM. I think x86 will remain strong due to the large legacy and current software libraries. Same for Windows itself. I do not think Windows for ARM will succeed - it can't run modern x86 software well making any transition off x86 very rough.

Sure? Intel apps for Mac OS work well in Arm Macs, thanks to Rosetta 2. Probably, the problem is that Microsoft does not have this technology. Arm technology allows, with the same batteries, more than 20 hours between charges, for example. Arm technology allows a much more power computation, without consuming more energy. Really do you think that the future is Intel architecture? Or do you think that Intel is ready to create processors without these limitations?

But I still don't get it - What exactly is Microsoft allegedly still waiting for? Windows on ARM has been a thing for several years now, and all major Microsoft software (I might be wrong) has been available natively for ARM for quite some time now. Granted, Apples Rosetta emulation is superior to how Windows emulates x64 code on ARM, but this is what we have now. What else would one now expect from Microsoft? From my point of view, their job is more or less done.

Maybe contact with the author and ask him? I guess there are plenty of OSS devs that don't bother about choosing a license for their product at all and just take the first random one when Github urges them to make the choice.

In fact, most of people really, though indirectly, have this kind of data sorted 😉 DB keys

Yeah I did have a quick look at it.. not what I need. I found plenty of code for reading the basic PE/MSDOS headers, but I need to get into the sections etc. I'm investigating adding certificates so need to enumerate sections and append some data to to the exe. So it's a lot more involved than just reading the basic info.

Ctrl+Alt+Del: Snapdragon X Elite has one fatal flaw – Windows on Arm