Wil van Antwerpen

16 hours ago, dpsoftware said:

The MacOS 13.1 is native on an M1 MacBook Pro and the 14.0 is a virtual machine using parallels 

That is curious indeed as the M1 MBP would certainly support Metal without any issues.
Not sure about the VM on Parallels.

25 minutes ago, dpsoftware said:

I found the original program works if you go to MacOS settings - Displays. Then change the resolution from the default to the maximum available. It didn't work for one of my customers though, so maybe I just got lucky.

 

When I tried GlobalUseMetal:=true, my program doesn't start. The icon just bounces up and down until I terminate it. This is with both MacOS 14.0 and 13.1

Curious.. are you testing in a VM or on recent macOS hardware that supports macOS Sonoma natively?
I'm asking as most VM's won't have metal support. There's also OCLP to get Sonoma running on older hardware and also wonder how good the metal support is on them.
I haven't verified it myself yet, but I doubt that this setting works well if metal isn't available.

--
Wil

As suggested at the Facebook group, setting GlobalUseMetal to true before the form initialize did resolve the issue for me as well.
Pfeww :)

Thanks Dave.

ah facebook.. haven't signed in there in many months, not my thing.
Signed up to those groups now, I suspect it is the same issue.
With SDK12.1 my app didn't even start via 10.4.. let's try SDK13.1 from 11.3 (not getting bored)

edit: also didn't start. Probably a red herring.
Will chase that tomorrow, pulling an all nighter isn't going to help speed things up I think.

Thanks Dave.
Good to know I'm not alone. Currently trying to use newer versions of the SDK to see if that makes a difference.
So far no luck, but I was using some pretty dated SDK's, so I'm slowly working my way to something current.

I take it that this was only reported in Delphi groups?

Had some customers upgrade to macOS Sonoma.

My app doesn't work on Sonoma as it has various problems.

The main -in your face- issue though is that the layout of the application is completely messed up. Making it completely unusable.

It's like you're using a magnification application on top of the app, it shows a snippet of the user interface and there doesn't seem to be a way to get it to look normal.

Anyone else seen this?
Tried with Delphi 10.4 as well as Delphi 11.3

So far only tested against macOS Sonoma on the intel platform. But it would surprise me if it hasn't the same issue on Arm.

--
Wil

On macOS if a folder is a bundle or not, is not just determined by a file extension.

It's something called bundle bits.
You can check those with command "xattr -lx"

For more info see: https://ss64.com/osx/xattr.html

17 hours ago, Cristian Peța said:

Just tried in latest VMware 16 Workstation and my Win 11 VM with Delphi works on other machine.

No workarounds. TPM installed and VM password encrypted.

Exactly..

Sadly only see this thread now, or I would have commented on that earlier.

When you use normal VMware disk encryption on VMware Workstation or VMware Fusion then you can actually move the VM to another host.

It is the experimental autoAddVTPM option which creates a VM that is not portable to other hosts (along with other foot gun options)

Thanks!
That does indeed look like it was the missing piece of information that I need.

Hi,

I wrote an ActiveX component with Delphi 10.4.2 and the users are happy with it.
There's lots of legacy software out there and this helps them.

One of the things I am looking into now is how-to add an icon for using it in other development tools.

On the toolbox pane in VB6 it shows up as a black square now and that's not very ideal.

See below:

From what I've found so far, it has to be an image of 16x15 pixels and only 16 colors (oh dear).
Hopefully one can add higher resolutions as well for other environments.

There was also some mention of adding it as resource (.dcr) file, which I tried, but so far, no cigar.

Somehow I'm not finding much details on this. LOL
Ideas welcome, maybe someone down here remembers and is willing to share that tidbit.

Thanks.

20 minutes ago, Wagner Landgraf said:

That was true for Windows 10, are you sure it will be the same for Windows 11? I believe ARM in Windows 11 will be a 1st class citizen like Intel.

I have no crystal ball and really hope you are right on that, but so far the signals have not been very hopeful.
For example: https://www.macrumors.com/2021/09/14/arm-windows-m1-macs-not-supported/

From what I've read the only supported version of Windows on a M1 mac is via Windows running in the cloud.

59 minutes ago, Rollo62 said:

I still have hope that we will see VmWare or the like on M1 Macos, which is able to support x86 Win10/11.

That would leave the problem to VmWare to make it run.

I haven't thought too deeply about what that conversion would mean on the CPU virtualization side of an entire OS, but why not its also simply a "program"

Yes, maybe a missing hypervisor emulation would be a problem.

Neither is going to happen, at least not from VMware or from Apple.
VMware in particular has been very clear about this. For example here: https://blogs.vmware.com/teamfusion/2021/04/fusion-on-apple-silicon-progress-update.html but it is not just that one article. The Product Manager has mentioned it many times. They actually looked into it and have decided on not going there. Who knows if there's a skunk works in house version that is capable of doing exactly that. But there has been no hints in that direction, the "not going to happen" signals have been much stronger.

15 minutes ago, Wagner Landgraf said:

Doesn't Windows 11 already provide ARM support?

Yes there is a Windows insider version running ARM and it runs well.
The problem is that Microsoft does not provide licenses for that and so far there are no indications that they ever will. Windows on Arm only works with OEM hardware suppliers and apple isn't one of them.
It is mostly (exclusively?) bundled with laptops having a Snapdragon processor. One could run on a VM with a Windows insider build, but that's not exactly production ready.

3 minutes ago, Rollo62 said:

Why should they kill a well working emulator solution, which can attract all the Windows users to M1, I think cancelling that would be a stupid marketing decision

Rosetta doesn't even work for Windows?
Virtualisation platforms are not supported. If you run Windows in a VM then you have to run an Arm version and MS hasn't provided a license for that (and it isn't looking great on them going to provide you a license to run on non partner hardware)
Also note that there's no bootcamp support now for the M1 platform.

As for why cancelling something that works?
Only apple knows, but it smells a bit like "lock in", but also less maintenance costs.

Hi,

13 minutes ago, Rollo62 said:

By Rosetta this supports ARM M1 and Intel x86 anyway, with good compatibility and at high performance, so I think Wintel / AMD will see a hard future.

One note about Rosetta.
Apple has switched CPU platforms several times. If the past predicts anything then Rosetta will be part of macOS for about 2 releases of macOS and disappear. It's designed to assist in migrating from one platform to another, not intended to stick around forever.

FWIW, TPM 2.0 support has been available for VMware Workstation since at least Workstation 14 IOW since 2017. [1]

Another note is that Windows 11 in a VM appears to run just fine without TPM and even UEFI as I upgraded a Windows 10 VM to Windows 11 and it has neither. To put it in another way. Microsoft relaxes the requirements for virtual machines as was found by VMTN user SvenGus here [2]

To quote SvenGus:

Quote

BTW, in this document:

https://download.microsoft.com/download/7/8/8/788bf5ab-0751-4928-a22c-dffdc23c27f2/Minimum Hardware Requirements for Windows 11.pdf

… they say that certain requirements are ignored when Windows 11 detects a virtual environment:

5 Virtual Machine
Microsoft recognizes that the user experience when running the Windows 11 in virtualized environments may vary from the experience when running non-virtualized. So, while Microsoft recommends that all virtualized instances of the Windows 11 follow the same minimum hardware requirements as described in Section 1.2, the Windows 11 does not apply the hardware-compliance check for virtualized instances either during setup or upgrade. Note that, if the virtualized environment is provisioned such that it does not meet the minimum requirements, this will have an impact to aspects of the user experience when running the OS in the virtualized environment.

[1] https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-B42CAC2A-DC3D-4F15-BEFE-AB4319B288CB.html

[2] https://communities.vmware.com/t5/VMware-Fusion-Discussions/vmware-fusion-on-m1-goal/m-p/2856321/highlight/true#M174764

On 7/4/2021 at 7:49 PM, dkounal said:

As I can understand, Delphi does not support such notifications

Is it different from this?
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_Notifications#Notifications_Support_per_Platform

From the looks of it, Android also has this feature.
I don't develop for Android, so don't know, but the doc appears to suggest that Notification support is available.

edit: Argh.. never mind, please disregard ... "show progress"... not just a notification.

14 minutes ago, PeterPanettone said:

That would the BIGGEST INNOVATION in Delphi ever, giving Embarcadero a 500% boost to Delphi sales.

LOL, it should, but sadly nobody really cares about the size of a binary these days.
Having to roll (and maintain) your own version of a standard unit sadly isn't time best spent either.

Thanks David, yes that seems to be the case.
While other tools can be useful, quite often it is faster to build something in Delphi. Going back to using a very old version is most of the times not the best solution.
Much appreciate all the replies.

Thanks.
I was afraid that it would be hard. I tried to get rid of some standard packages.. but didn't see a byte difference.
None of the suggested packages are easy to remove as that would trigger a lot of extra -hard to maintain- work.
Looks like I will have to learn to live with it for now.

Somehow I had expected that the compiler was smarter and not include parts of the packages I'm not using, but I can see how that's a bit of a pipe dream.

At least I now know what parts to pay attention to.

--
Wil

Back in Delphi 5, Delphi 7 etc... I did built a few DLL's and I was amazed by how small they ended up.
Creating a nice control under 100kB was normal.

Nowadays, with Delphi 10.4 building any control under 2MB looks like it is a challenge.

Has anything changed here?
Is this because I am using VCL and is VCL pulling in 2MB for that? (If so I have to see if I can't eliminate the usage of VCL)

I don't see this happening if I built a component in C++ with Visual Studio.

Has anyone any tips on how-to reduce the size of the resulting binary DLL or ActiveX?

Looks to me that I am just missing something basic here.

Btw, just saying, I'm not interested in packers. I prefer to just cut the "bloat", not compress it.

Thanks for any ideas.

Hi,

Quote

I also still struggle to understand if an EV certificate is really good for anything besides drivers. I don't have a source at hand, but I remember that Microsoft SmartScreen will automatically grant an EV signed application a higher reputation than with a regular certificate.

Exactly that.. if you offer your software as a download then SmartScreen will be a real PITA for your users unless your software was signed with an EV certificate. About 3 times a user gets asked if they really want to do this. First deny the download, then popup a "not often installed" warning with cancel as default choice, then another warning of which I forgot the details.

Sorry, can't test that now as Microsoft has finally started accepting my normal certificate again (after 5 months of pain)

There I was just coming to the conclusion that one of these days I have to accept that the certificate I had bought for 3 years is worthless and that only an EV code signing certificate is going to offer a painless installation for end users. (pffff... )

edit: you asked for a link: https://www.ssl.com/faqs/which-code-signing-certificate-do-i-need-ev-ov/

Quote

Microsoft SmartScreen Reputation

 

According to Microsoft’s FAQ, its reputation-based SmartScreen filter “checks the files that you download against a list of files that are well known and downloaded by many people who use Internet Explorer. If the file that you’re downloading isn’t on that list, SmartScreen will warn you.”

Signing your code is not required to earn a SmartScreen reputation, but EV-signed code’s extra level of trust lets developers skip this hurdle altogether:

• An EV code signing certificate offers an immediate reputation with Microsoft SmartScreen, so your users will never have to click through a SmartScreen warning in Windows.
• With an OV certificate, SmartScreen reputation must be built organically, as users download and install your files. SmartScreen warnings may occur until enough software proves sufficiently popular with Windows users for SmartScreen to view it as “well known.”

I have lost so much time (and sales) on this that when the next renewal comes I will not doubt and buy an EV certificate instead of the -much cheaper- OV one.

9 minutes ago, Lars Fosdal said:

VMware users, patch now!
https://www.bleepingcomputer.com/news/security/attackers-are-scanning-for-vulnerable-vmware-servers-patch-now/

It is good to alert users, but just to be clear this is for vCenter Server, not for VMware Workstation/Fusion/Player.

Normally VMware vCenter server should not be directly accessible from the internet (yes, some people/companies do).

However even when on a local network, it is still good to run the vCenter Server appliance update, if you run it.

Also using everything VMware down here.
All of my code and setup is in a VM.
If I need to share source with other VM's or host then that is done via source control.

Note that VMware shared folders (hgfs) can work for sharing source with host, but if it has a lot of files then I do expect a decreased performance while compiling.

Shared folders are convenient, but they are also known for not being very performant.

This is a common complaint at the VMware Forums.

My recommendation in that case is to use network shares as they tend to be faster.

Another thing to look into when troubleshooting performance issues with VMware shared folders is to make sure you antivirus is not checking your source.

2 hours ago, A.M. Hoornweg said:

The latest VMWare version can co-exist with Hyper-V on the same host machine by the way.

 

Supported since VMware Workstation 15.5

Yet another advantage... I develop for macOS, on my mac I run Delphi in a VM, I can deploy on the mac at my host and when I debug, the screen will switch to the host automatically. Very smooth.

Yesterday I got a bug for latest Big Sur updates.. I fire up a VM that's slightly older and upgrade it to the latest Big Sur version to verify it is indeed an issue in this version only.

You can also take that Windows 10 VM that runs on macOS Fusion and run it on VMware Workstation under Windows .. or Linux. This is exactly what I do when travelling. It is also easy to keep an encrypted version of your VM on a microSD card, so you have something to fall back on in case the laptop goes missing. There are too many advantages to not use it.

As others said, it is easy to make backups.

It is also easy to experiment and share resources.

Would like to run something that might potentially damage your setup? Not something I would do without extra precautions on a physical host. But on a VM? It is easy to experiment. Take a snapshot, do it anyways. If it was as bad as you guessed, roll back the snapshot, otherwise commit the snap.
With backups that takes time to restore, with a snapshot it can all be done within the minute, including roll back and/or commit.

Another scenario I used in the past was where I had to support a multitude of database back ends for a client (Oracle/MSSQL/mySQL/PostgreSQL) Each SQL server was installed in its own VM. Need to support multiple versions of MySQL? No problem, add a VM. On a physical host this can get messy and with all the SQL servers each could burn through resources even when not using. Yes you can mess with starting/stopping services as an alternative, it really all depends on your needs on what is the better choice.

Also moving any of those VMs to a bigger host at any time (scale up/scale out) is easy.

re. slow/fast. I've run tests with development VMs on my MBP against physical host installs (server class, similar CPU type but xeon, SAS RAID) and the difference was negligible. On 2 minute compile times, testing the exact same project, the difference was seconds.

Once the VM had 2 vCPU's or more assigned, it was about as fast as the Windows setup on a physical host. The kicker? I had 4 more VMs actively running on that MBP when running those tests.

It is also easy to do things like kernel debugging. You can connect two VM's via the virtual serial port all on the same host.

Does this mean VM's are always better?
No, there are workloads that will always benefit when running at a physical host.
Audio low latency, video editing, games... they all do better on physical.