Mac Programming Software
- Thread starter dwill54
- Start date
- Status
I use Paralles VM on my Mac. I run RT Systems, Motorola P25 and DMR CPS, Harris, Kenwood, and others with no issues at all.
ko6jw_2
Member
VMware Fusion works well. I'm even running Wires-X on it with an FT2DR and adapter cable. The main problem with virtual machines is the USB interface. VMware works best when you plug in the USB cable AFTER starting the virtual machine. It will then ask if you want to connect to Mac or Windows. I'm running Windows 7 professional at this point.
I'm using Parallels myself and haven't had any problems.
I'm running Windows 10 via BootCamp.
ko6jw_2
Member
VMware and Parallels allow both the Mac OS and Windows to run at the same time - no rebooting. And, you can create other virtual machines like Linux.
I use boot camp it free and I hate windows but running boot camp does the job for programing your scanner so the only cost is windows 10
VMware and Parallels have a cost to them besides windows 10.
VMware and Parallels have a cost to them besides windows 10.
As the author of Scan125 I have a small number of users using Scan125 on their Macs.
From my perspective the most successful and reliable setup would appear to use boot camp and Windows. In this mode you are running Windows natively and windows has direct access to the hardware and in this case good, reliable and fast access to the USB port(s) is crucial.
Windows 10 can be installed an run without activation and you can still do most things and access to settings.
The problems I have seen with VMs, and to a lesser extent Parallels is that they can get in the way of good fast access to the USB ports. This is even more important with the 125 series of scanners as the port speeds are very high at 115200 and any delays can cause nasty time outs and latency. To this end I had to put quite a lot of extra serial port handling/retry code/settings into Scan125.
From my perspective the most successful and reliable setup would appear to use boot camp and Windows. In this mode you are running Windows natively and windows has direct access to the hardware and in this case good, reliable and fast access to the USB port(s) is crucial.
Windows 10 can be installed an run without activation and you can still do most things and access to settings.
The problems I have seen with VMs, and to a lesser extent Parallels is that they can get in the way of good fast access to the USB ports. This is even more important with the 125 series of scanners as the port speeds are very high at 115200 and any delays can cause nasty time outs and latency. To this end I had to put quite a lot of extra serial port handling/retry code/settings into Scan125.
ko6jw_2
Member
Some USB issues seem to be traceable to Windows 10. This true on my PC's too. That's why I use Windows 7 on my virtual machine.
Yes, I am aware that Boot Camp is free and the others are not. I my case I run software for my business with VMware. Being able to switch between OS's on the fly is important to me. If that isn't a factor for you, then by all means use Boot Camp.
Yes, I am aware that Boot Camp is free and the others are not. I my case I run software for my business with VMware. Being able to switch between OS's on the fly is important to me. If that isn't a factor for you, then by all means use Boot Camp.
Well I have Scan125 users on Macs that had issues under W7. I developed Scan125 under W7. Indeed Mac users on W10 have not raised any issues with me to date. (please note that when you provide free software and issues arise then many users will not bother to report/contact you and just walk away. their loss but this attitude/approach does not help the developer(s))
I think the OS in use is not the issue but when the OS is run under a VM / emulator / similar then this is where issues can occur. To my knowledge most PC software run on Macs / Linux / others under VMs do not exploit/rely on fast and dedicated access to serial/USB ports in a "bilateral communicative exchange". I think any hardware/software engineer, especially on safety critical systems, will deem/require/expect a "one to one" interface and not via a third party.
A lot of this comes down to coding design. I could send a command "shut up" to the OS to pass through to a serial/usb device. If I code correctly then I should await the OK response from not only the send process but also from the client receiving process. In 99%+ cases I could just accept that if the send rc was zero then waiting for the handshake acceptance rc of zero was not important. Correctly the software issuing the commands should validate both the send and return paths. With VMs/other intervening bods then the messaging between source to client and client to source can be upset / delayed /etc and this is when issues occur.
Steve's G's Spinrite is a good example. To do what SR wants to do then he needs the fastest most absolute and uninterrupted access to the hardware without going through a "middle man/OS".
Scan125 uses a fully "closed loop" exchange with the scanner. An example would be you send freq 123.456 to the scanner. For Scan125 this is not the end of the process. The scanner could/will change 123.456 to the next nearest step value, say 123.450. Scan125 will do a read back from the scanner and detect the change to 123.450 and then change/alter/adjust it's value from 123.456 to 123.450
To squirt a command to a port is one thing and even under a VM this may work OK. But to dynamically do the whole "round robin" of send cmd/check cmd was accepted with no error/read back from scanner/etc actually involves a sequence of commands and responses and any delay/interuption will either leave the scanner and client out of sync or result in the software eventually saying enough is enough *we* can not reconcile our differences. This is what Scan125 does and under native OS configurations (ie. Windows direct to metal) I've had no issues but when VM's where the VM controls the hardware I've had plenty if timing/response issues to work around.
I think the OS in use is not the issue but when the OS is run under a VM / emulator / similar then this is where issues can occur. To my knowledge most PC software run on Macs / Linux / others under VMs do not exploit/rely on fast and dedicated access to serial/USB ports in a "bilateral communicative exchange". I think any hardware/software engineer, especially on safety critical systems, will deem/require/expect a "one to one" interface and not via a third party.
A lot of this comes down to coding design. I could send a command "shut up" to the OS to pass through to a serial/usb device. If I code correctly then I should await the OK response from not only the send process but also from the client receiving process. In 99%+ cases I could just accept that if the send rc was zero then waiting for the handshake acceptance rc of zero was not important. Correctly the software issuing the commands should validate both the send and return paths. With VMs/other intervening bods then the messaging between source to client and client to source can be upset / delayed /etc and this is when issues occur.
Steve's G's Spinrite is a good example. To do what SR wants to do then he needs the fastest most absolute and uninterrupted access to the hardware without going through a "middle man/OS".
Scan125 uses a fully "closed loop" exchange with the scanner. An example would be you send freq 123.456 to the scanner. For Scan125 this is not the end of the process. The scanner could/will change 123.456 to the next nearest step value, say 123.450. Scan125 will do a read back from the scanner and detect the change to 123.450 and then change/alter/adjust it's value from 123.456 to 123.450
To squirt a command to a port is one thing and even under a VM this may work OK. But to dynamically do the whole "round robin" of send cmd/check cmd was accepted with no error/read back from scanner/etc actually involves a sequence of commands and responses and any delay/interuption will either leave the scanner and client out of sync or result in the software eventually saying enough is enough *we* can not reconcile our differences. This is what Scan125 does and under native OS configurations (ie. Windows direct to metal) I've had no issues but when VM's where the VM controls the hardware I've had plenty if timing/response issues to work around.
- Status
Similar threads
BCD436HP/BCD536HP:
BCD436HP - SCAN speed very slow