I'm looking for an explanation of the different functionality in versions of a application called VMAC (Verix blah blah blah), also called "comm server", which is used on Verifone payment terminals. I've got terminals with versions 1.7 and 3.3 of VMAC, and I'm unaware of the differences.
If someone is a Verifone expert, it would be helpful to know how much of the communication with the processing host vs the merchant services provider's application.
VMAC stands for Verix Multi App Conductor. VMAC provides a platform for multiple terminal applications to run on a single device. Comm server software is used for communication purpose. Versions mentioned by you are bit older version . Latest version of VMAC available is 3.20.0. Differences between different VMAC versions are like newer versions supports more (and/or Enhanced) features of devices and/or are more robust than previous versions.
Related
I have not used RedHawk but am considering using it. Reading the documentation it appears that RedHawk only supports development on varieties of Linux, but it is not clear whether this limitation also applies to target execution environment. Can RedHawk support applications to run on non-Linux target hardware (cross-compile, CoreFramework, remote debug, ...)?
Redhawk is not limited to running applications on Linux platforms, per the SCA standard. An ExecutableDevice (see http://redhawksdr.github.io/Documentation/main.html, Section 6.4 'Executable Device') enables software to be copied to and run on a particular host, which does not have to be Linux-based. However, Redhawk does not provide any implementations, base class/helper libraries, development tools, etc. for other platforms, which makes this less practical.
The only exception to this is the SCA explorer, used to browse/interact with Redhawk domains (for Windows, available on SourceForge). Interacting with a running Redhawk domain from a different platform is fairly straight-forward using CORBA and the interfaces included with the Core Framework.
Note: There is a similar question called 'installing nodejs on windows machine'.
And various answers explaining how by installing cygwin you can get it working there.
now, I don't want to install cygwin.
I just wish I could run nodejs on a windows box.
I want a "nodejs.exe" to kick off.
Can somebody explain to me
1) why nodejs has not been ported on windows - what are the technical reasons for not providing an exe ?
2) are there any plans to have nodejs on windows ?
I really would like to use it but I can't accept that I have to accept cygwin.
That's just not right.
Update:
For optimum node on windows development I recommend you use the Windows Azure powershell for node.js. It's a powershell optimised for using node, npm and the azure APIs. (the azure apis are optional. I would still use this powershell if I didn't use azure).
When : v0.6
Currently you can get a binary file that (kind of) works under windows. Go ask on the node.js IRC channel. They'll hook you up.
Basically if you read up on node.js road plans you will find that proper windows support is planned for 0.6, we are currently on v0.4.7 and the v0.5.x beta is in full storm.
I won't give an ETA but it's soon.
IRC can be found at the Community links
PDF showing v0.6 road plan
July 2011 update:
#nodejs v0.5.1 is the first to ship with an official Windows executable. We're hoping to get some good feedback.
Microsoft has officially gotten involved with joyent in making node.js run natively on windows.
Running Node under Windows presents several technical problems, mostly related to how Windows' internal design differs from that of Linux and the "change in mindset" required to port Unix applications to Windows.
Background
Linux was designed to be a replacement for Unix, a well-known multitasking operating system, so from day one it has been a multi-user/multi-process, server-oriented operating system. The idea of multiple processes sharing system resources is key to its internal design.
Windows was initially designed as a single-user/single-process desktop operating system and so did not support shared access to system resources. In 1993 Microsoft released a newly redesigned version of Windows--called Windows/NT--to better support the shared resource, multitasking model required by servers, but due to its existing installed base of users, Microsoft required NT to also support all the features of its single-user/single-tasking forebearer.
Windows 7 is a direct descendant of NT and Microsoft's need to support legacy users continues to this day (and in the opinion of many, has severely muddled Windows' internal design.)
Further, Microsoft hired a systems architect named Dave Cutler to design NT. Dave is best known for designing a competitor to Unix called VMS, the internal design of which differs significantly from that of Linux, which has caused a lot of problems for developers interested in porting their Unix programs to Windows.
The clearest example of this "impedance mismatch" between the internal design of Windows and Linux is how they handle event-driven, non-blocking input/output (io) on which Node relies to perform its (apparent) multitasking magic in a single thread of operation.
Linux supports two system-level functions called select() and epoll() which can be used to asynchronously inform a process of changes within the operating system that affect it. Node relies heavily on these functions but Windows doesn't support either, relying instead on "Change Notifications" (mostly) to handle event-driven io.
Is there an equivalent to Linux DBus on OSX? I mean, is there a "message bus" available by default on OSX?
Disclaimer: OSX newbie here.
If you need to use DBus you can install it via Homebrew.
Homebrew is a package manager for OS X providing a lot of libraries which where mostly written with Linux as their primary target.
The DBus package can be found here
However, this is not installed by default and if you intend to write Cocoa applications the way to go would be to use the (distributed) notification center as mipadi explained in his post (which you also accepted).
If you need a robust middleware for communication you can also have a look at IceTouch from ZeroC which is a Cocoa library for using the services and functionality offered by their Ice framework.
The package contains IceStorm for example which is a publish/subscribe server or the IceGrid service which can be used to build large scale distributed systems
Probably the closest analog would be distributed notifications (or notifications for same-process communication). It's not a perfect analog, but it fits into roughly the same niche. You can read more about it in Apple's Notification Programming Topics, particularly the part about the distributed notification center.
There's Mach's ports, which will probably do what you need: http://en.wikipedia.org/wiki/Mach_(kernel) .
You could check DarwinPorts. It should include the dBus libraries.
We are about to release a couple of softwares with Linux support.
As for Mac and Windows, the number of version to support is quite limited (xp, 2000, vista, 7 for win, 10.4-6 for Mac). But for linux it's another story.
We'd like to support as many Linux as possible, but the choice is large.
The questions are:
Which distribution format (binaries) to use to support as many Linux as possible?
For testing, what "base linux" can we test on and extend our results to other linuxes.
According we provide statically linked binary with all the dependencies, what do we need to check? I assume kernel version and libc version, but I'm wondering.
Our software is written in ANSI compliant C with a bit of BSD and POSIX (gettimeofday, pthreads).
So you think three versions each for Mac and Windows is normal, but you shy away from Linux? Hm.
Just make sure it builds using the standard tool chains -- configure, make and make install traditionally. The rest should take care of itself.
Else, pick what you are comfortable with. For me that would be Debian/Ubuntu, others prefer Fedora. Look at the Linux Standards Base and things like FreeDesktop.org for other standards. Kernel and libc should not matter unless you are doing something very hardware or driver-specific.
The kernel strives to maintain a backwards-compatible binary API. Statically linked binaries built against 1.0 series kernels are supposed to still run fine to this day on the latest 2.6 series kernels.
If you are statically linking with everything (including libc), then the major problem you are likely to face is different filesystem arrangements, which may not even be a great issue for you. (Testing is the only way to find out, though).
An idea is to survey your proposed customer base so see which linux version they run and make a short list from their feedback. However from what I know (which is subjective!) ...
I would suggest running two different distribution types -- rpm and .tar.gz. With rpm you cater for the latest Fedora/openSUSE/RHEL/SLES (and derived distros, which is a fair chunk of the corporate market). You are already handing a lot of dependency problem by static linking, so kernel version should be sufficient.
With .tar.gz distribution you cater for 'all others' but watch support and configuration problems as they quickly become a time sink.
For testing, have virtual machines of each version you choose to support. These can also be used for product support (I assume you will need to provide product support??) I wouldn't try to extrapolate results between linux versions because there a too many hidden 'gotchas'.
You can release statically compiled Linux binaries against the kernel & version of glibc. You really only need worry about compatibility-breaking revisions. If you have some time, you can setup everything to cross-compile on the same host. The kernel is backward compatible. glibc is more temperamental.
File paths can be assumed to be Linux Standard Base, if you want to package it with an installer. The more flexible you can be here, the better. I've never heard a customer complain about receiving a tarball of binaries, which I'd recommend offering. I have had customers complain about incorrect assumptions.
Your best bet for a formal package format is probably between DEB (Debian Linux & derivatives, like Ubuntu) and RPM (Red-Hat & derivatives, like Cent-OS). Packages are nice to have, but are just a headache if you don't plan on utilizing the native update manager.
For test & build, I'd personally recommend Gentoo. It's pretty raw, however, so you might want to look into Ubuntu as a distant second choice.
This is an issue for your product management team. Once they have determined that producing a Linux version is a desirable idea (i.e. on a cost-benefit basis), then you will need to find out what distros your customers use or want supported.
In principle you can support any but the more you support the more of a headache it will be, so you want as FEW as possible.
Support as few OS / architecture combinations as your PM thinks you can get away with
Deprecate OSs / architectures as soon as you can
Only take on new ones if premium support customers demand it, or to get big deals, as per your PM's decision.
How hard it is to support them is largely dependent on how complex your product is (esp. dependencies) and how complete its auto-test suite is. Adding more supported OSs ties your hands with respect to library usage, kernel feature usage etc as well as testing, so it's not something you want to be lumbered with long-term.
So in short, it's not a software engineering issue, but a product management one.
I need this info to decide on what I am going to do about my platform support of my systems in the coming year, but can't find any real info on that. Maybe someone has some just released information.
Thanks in advance.
There are four projects on the Delphi roadmap:
Delphi Weaver (Firebird support, enhanced RTTI, Windows 7 API)
Delphi X (Cross-platform)
Delphi Chromium (Quality)
Delphi Commodore (64-bit compiler, better multi-threading support)
You are looking for Delphi X, but it is unknown when it will come out. Delphi Weaver will be the next Delphi version.
This is as much as there is publicly available. Marco usually is well informed. But there are no release dates for the version.
Project Weaver
Focused on User Experience (new IDE Insight, Touch support),
Connectivity, improved Documentation,
Team Productivity, DataSnap with HTTP,
REST server, .NET Proxies for
DataSnap, Callbacks supported,
dbExpress with native Firebird
support, Aspect Oriented Programming
support, Subversion integration,
Windows 7 and Direct2D support, SOAP
1.2 clients, enhanced RTTI
Project Delphi “X”
Cross-platform support for MacOS and Linux, server and clients on Linux
and Mac
Project Chromium
All about developer productivity, Pascal code formatter,
documentation for the ToolsAPI, new
Databinding model, integrated DB tools
Project Commodore
64-bit Windows, compiler + RTL + VCL, multicore support, parallel RTL
Future (far)
Cloud computing, Web 3.0++, beyond RIA, Devices, sw appliances,
secutiry, compliance
Beyond the Beyond
Functional programming, declarative programming, natural
input, more platforms…
Nothing official from Embarcadero, but I think around 2010-2011 based on:
Embarcadero's CEO Wayne Williams said in interview with The Register:
Williams says cross-platform is now a
higher priority than a 64-bit
compiler, though both are planned, and
that we will see the first
cross-platform release next year.
Beside Robert Love commented at his blog which was about next Delphi versions:
Nothing was set in stone. These are
current plans and they may change.
Time frames where avoided, but one
comment was made in Q & A... They did
not see anything on this list taking
longer than 2011. So 2-3 years may be
practical since time frames were
really avoided, I would not plan on
anything right now.
We at twinforms provide support for Mac and Linux development using the current Delphi versions (for Linux and Mac, you need to compile the source using FreePascal). Have a look at the screencast that shows how to develop a cross platform application using Delphi and FreePascal - http://twinforms.com/products/wxformsdelphi/screencasts.php
A few things to keep in mind about Delphi forcasting:
At DelphiLive! Nick announced that they changed the way they are doing development now. Previously everyone was working on the next release. This made it harder to get bigger changes done in time and done well. So there would be one "code named" version they were working on, and that was it.
Now there are multiple code named projects that are not necessarily attached to a specific release. So for example the list of code named projects that everyone provided here isn't necessarily each a different release of Delphi. They will take whichever projects are "ready" when they have a release coming and include those.
If you want more information about the road map, you can check out a series of videos I shot at DelphiLive! or the DelphiLive! Recap and Product address.
As far as when we might expect the next Delphi release, I wrote a blog post about that based on information provided at DelphiLive! as well.
If you are going to use this information to plan your Delphi purchases, and you don't currently have Delphi 2009 then buy Delphi 2009 now (at least by Aug 24th). They have a great promotion going on, and you can get software assurance and then you will get whatever new versions come out in the next year.
Delphi 2009 is a fantastic release and you will want to come up to speed on generics and Unicode now so you can take better advantage of them in the next releases.
In Stack Overflow Podcast #61, Miguel de Icaza talks a lot about his work on Mono and briefly mentions Delphi, so one might speculate that any cross platform support is going to be built around Mono.
They tried this before with Kylix. Let's hope history doesn't repeat itself here.
The last thing we need is more proprietary development applications.