The situation is simple. I've created a complex Delphi application which uses several different techniques. The main application is a WIN32 module but a few parts are developed as .NET assemblies. It also communicates with a web service or retrieves data from a specific website. It keeps most of it's user-data inside an MS Access database with some additional settings inside the Registry. In-memory, all data is converted inside an XML document, which is occasionally saved to disk as backup in case the system crashes. (Thus allowing the user to recover his data.) There's also some data in XML files for read-only purposes. The application also executes other applications and wants for those to finish. All in al, it's a pretty complex application.
We don't support Citrix with this application, although a few users do use this application on a Citrix server. (Basically, it allows those users to be more mobile.) But even though we keep telling them that we don't support Citrix, those customers are trying to push us to help them with some occasional problems that they tend to have.
The main problem seems to be an occasional random exception that seems to pop up on Citrix systems. Never at the same location and often it looks related to some memory problems. We've p[lenty of error reports already and there are just too many different errors. So I know solving all those will be complex.
So I would like to go a bit more generic and just want to know about the possible issues a Delphi (2007) can have when it's run on a Citrix system. Especially when this application is not designed to be Citrix-aware in any way. We don't want to support Citrix officially but it would be nice if we can help those customers. Not that they're going to pay us more, but still...
So does anyone know some common issues a Delphi application can have on a Citrix system?
Does anyone know about common issues with Citrix in general?
Is there some Silver Bullet or Golden Hammer solution somewhere for Citrix problems?
Btw. My knowledge about Citrix is limited to this Wikipedia entry and this website... And a bit I've Googled...
There were some issues in the past with Published Delphi Applications on Citrix having no icon in the taskbar. I think this was resolved by the MainFormOnTaskbar (available in D2007 and higher). Apart from that there's not much difference between Terminal Server and Citrix (from the Application's perspective), the most important things you need to account for are:
Users are NEVER administrator on a Terminal or Citrix Server, so they no rights in the Local Machine part of the registry, the C drive, Program Folder and so on.
It must be possible for multiple users on the same system to start your application concurrently.
Certain folders such as the Windows folder are redirected to prevent possible application issues, this is also means that API's like GetWindowsFolder do not return the real windows folder but the redirected one. Note that this behaviour can be disabled by setting a particular flag in the PE header (see delphi-and-terminal-server-aware).
Sometimes multiple servers are used in a farm which means your application can run on any of these servers, the user is redirected to the least busy server at login (load balancing). Thefore do not use any local database to store things.
If you use an external database or middleware or application server note that multiple users will connect with the same computername and ip address (certain Citrix versions can use Virtual IP addresses to address this).
Many of our customers use our Delphi applications on Citrix. Generally speaking, it works fine. We had printing problems with older versions of Delphi, but this was fixed in a more recent version of Delphi (certainly more recent than Delphi 2007). However, because you are now running under terminal services, there are certain things which will not work, with or without Citrix. For example, you cannot make a local connection to older versions of InterBase, which use a named pipe without the GLOBAL modifier. Using DoubleBuffered would also be a really bad idea. And so on. My suggestion is to look for advice concerning Win32 apps and Terminal Services, rather than looking for advice on Delphi and Citrix in particular. The one issue which is particular to Citrix that I'm aware of is that you can't count on having a C drive available. Hopefully you haven't hard-coded any drive letters into your code, but if you have you can get in trouble.
Generally speaking, your application needs to be compatible with MS Terminal Services in order to work with XenApp. My understanding is that .NET applications are Terminal Services-compatible, and so by extension should also work in a Citrix environment. Obviously, as you're suffering some problems, it's not quite that simple, however.
There's a testing and verification kit available from http://community.citrix.com/citrixready that you may find helpful. I would imagine the Test Kit and Virtual Lab tools will be of most use to you. The kit is free to use, but requires sign-up.
Security can be an issue. If sensitive folders are not "sandboxed" (See Remko's discussion about redirection), the user can break out of your app and run things that they shouldn't. You should probe your app to see what happens when they "shell out" of your app. Common attack points are CHM Help, any content that uses IE to display HTML, and File Open/Save dialogs.
ex: If you show .chm help, the user can right-click within a help topic, View Source. That typically opens Notepad. From there, they can navigate the directory structure. If they are not properly contained, they may be able to do some mischief.
ex: If they normally don't have a way to run Internet Explorer, and your app has a clickable URL in the about box or a "visit our web site" in the Help menu, voila! they have access to the web browser. If unrestrained, they can open a command shell by navigating to the windows directory.
Related
I'm developing an application that is able to determine which application using internet. Now my problem is that i want to know the process name before it successfully establish connection much like a firewall.
I'm using Delphi2009. So the suggestions in that technology are appreciated.
Look at Winsock Layered Service Providers to monitor traffic. I believe LSPs are DLLs that get loaded into each process, so you should be able to call GetModuleFileName(NULL) to discover the EXE name when your DLL is loaded.
The Wikipedia article linked above shares my strongest concerns:
One major common issue with LSPs was that if they were to be removed
or unregistered improperly or if the LSP was buggy, it would result in
corruption of the Winsock catalog in the registry, and the entire
TCP/IP stack would break and the computer could no longer access the
network.
So if you are new to Windows programming and/or do not take proper precautions with writing these types of filter drives, then tread carefully. Otherwise, a bug in your program will easily screw up the user's machine.
I have a related post - Assertion failure in DBAccess.pas but thought this was worth asking separately.
We are licensed for the full source-code release of DevArt ODAC but have been experiencing tremendous difficulties performing an upgrade. In the course of investigating this I have noticed that there is no .pas file for OraNet.dcu.
This is making it difficult to establish what the cause of our difficulties is as we cannot fully debug the code.
Also - what is this unit? From its name and the directives in the code it would be reasonable to suppose it is a .NET required unit - not something we are interested in.
There is the Direct DB connection mode implemented in the OraNet.dcu module, and we don't distribute the source code of this module, this limitation is specified at our website (the reference at the bottom of the page). If you don't use the Direct mode, and work via the Oracle client (the OCI mode), you can specify DEFINE NONET in your project settings, in this case, the Direct mode will be unavailable, and this module won't be used.
The client usage (even Oracle Instant Client) really allows using more features, than our Direct mode, but the Direct mode even surpasses OCI by performance in some cases. Besides, the Direct mode significantly simplifies application deployment and decreases the application size on disk due to the fact that there is no need to supply and deploy additional libraries, and set additional registry parameters and environment variables. The Direct mode also allows application deployment to systems, for which there are no native Oracle clients, for example, iOS. Choosing of the way of working with the DB (Direct or OCI) depends on developer and tasks resolved by each particular application. As it was mentioned above, if the Direct mode is not used, additional module plugging can be disabled by setting DEFINE NONET
I'm a hobby programmer trying to build a client/server application suite, using Delphi XE.
I write stand-alone applications occasionally, for my personal use. The problem is I don't know ANYTHING when it comes to networking / multi-tier. I am willing to learn though.
I looked for ways to do this and DataSnap and IntraWeb jump out as the most likely candidates for the job. But, before I start using one or the other, I would like to know a few info I wasn't able to find on the web:
If I build an IW stand-alone app and deploy it on my site (as server) will I be able to connect to it/retrieve data with a client application? I need to do that within my Delphi written app, without using a browser and without using HTML (I know very little HTML and I'm not eager to learn). I know IntraWeb isn't meant for this, but will it work?
If I go with DataSnap and build a server app, will I be able to deploy it to my website? Or do I have to make a computer on the network the server?
In case anyone wants to know, I want to connect 5 computers(from different cities), to exchange information between them, if at all possible using ADO, as I'm very familiar with it.
Intraweb is a server based tool for building web sites, accessed via a browser. It is not "proper" multi-tier, and it sounds like it isn't what you need.
DataSnap is designed to do what you want I think. First, the ADO part would be on the server, and you would define an interface that the server offers to do tasks. Then your clients would call that interface over the internet to get data or do those tasks etc.
As for whether they will work on your web server, that depends on what your server is, and the access that is provided to it. A web server is just a PC, but typical hosting is fairly restricted to running "scripted" languages on that server, which reside in the hosting directory. A Delphi server would be a running executable (usually a Windows Service), listening on a port, and needs much more access to the computer than typical. You would need at least a virtual Windows server with administrator access to the desktop to allow it to work. In the first instance though, you could happily run the server on a DSL line or similar and make it work just fine. You can worry about hosting it on the net when you have customers paying for it.
I'm looking at porting an Interbase 6 / Delphi 7 application to embedded Firebird in Delphi 2007. One of the problems we have is getting our users (often quite an unskilled bunch, really - though I love them to bits, naturally) to unblock our applications in their firewall. Windows firewall itself is fairly straightforward but often they are running McAfee or similar (they tend to buy cheap Dells with this stuff pre-installed) and it seems that each and every variation of this stuff has a slightly different user interface. sigh
Still, I'm digressing, sorry. Straight to the point; If my Delphi app connects to an embedded Firebird database, will I still need to all/open something in the user's firewall (as I currently do when installing stuff that makes a connection to 'normal' IB6)?
And if you've read this far (thanks) - can embedded Firebird be used concurrently on a machine? Let's say we have 2 applications, both of which want to use DIFFERENT databases - could the user run both of these apps simultaneously on the same machine or is there some kind of port binding that goes on under the hood, which we'd have to work around?
I have never had a problem with firewalls or McAfee with embedded firebird. (I assume this is because embedded is not really a 'server' and does not require a port to operate)
Yes you can have two apps concurrently, just keep the executables & databases in two different folders.
Even using Firebird in a non-embeded install on the local machine we have never bumped into any firewall issues in hundreds of installations. You don't even have to use TCP/IP to connect to the database. We do use TCP/IP, but using the local shared memory protocol would avoid the issue entirely.
Firebird makes an excellent embedded or semi-embedded database. We just install it in it's normal mode and it runs in the background without any user intervention 24x7 for years at a time.
As the embedded version of Firebird doesn't use TCP/IP to talk to the database, you'll be fine on single user machines. Bear in mind that Firebird Embedded is single-user and you won't be able to get two apps talking concurrently to the same database. To do that you'd need to install the Firebird server on the machine and in the connection string use localhost:C:\Data\MyDB.FDB on both apps.
I use UIB to talk to Firebird (I wrote a persistence layer for the OPF I use using it), it's thread-safe (unlike IBX) and I've found it to be appreciably faster than IBX. There's a version that comes with JVCL and a slightly later version at http://www.progdigy.com
I understand that Window's Services have no desktop, and can't access any of the user's desktops directly (indeed, they can run when there is no desktop loaded). Why is it though that launching a form in a Window's Service causes an error?
A service should run without any user interaction, so there is no need for a form. If a service has to wait around for user feedback then it probably isn't going to be doing what it is supposed to.
You have to understand three related concepts: sessions, windows stations and desktops. But because there's a one-to-one relationships between sessions and stations, we can broadly ignore stations for this discussion. A session contains a station (winSta0 being the only interactive station) and stations contain one or more desktops.
Now session architecture differs according to Windows version. For NT <= 5 (XP/2003 and everything before them) services execute in session 0 along with the interactive user's apps. This is why you can configure services to interact with the desktop in these Windows NT versions - they are in the same session. For NT >= 6 (Vista, Server 2008 going forwards), services exists in session 0 but the interactive desktop is in another session. This is what's known as "service hardening", and is basically a security fix.
So since session 0 apps cannot get at the interactive console, it makes no sense for them to attempt to display a user interface of any kind.
Just to make this more confusing, Vista has a temporary kludge to cater for this situation: if an app in session 0 tries to create a dialog, Windows will trap this and present a warning to the user so they switch to a (I presume temporary) desktop where they can interact with the dialog. However this measure is explicitly temporary and you cannot rely upon it being in future Windows releases. I've seen this working in native code, but I suspect you are in managed code and the runtime is being smart enough to catch your behaviour and deliver a metaphorical slap to the hindquarters :-).
Ummm... what and whose desktop is that form going to appear on, exactly? A 'desktop' is an operating system concept: each window handle is owned by a specific desktop within a window station belonging to a single (interactive) user. The process within which the service is executing isn't going to find the user's visible desktop in its window station. For a rather dry reference, look at MSDN.
Actually, it's even nastier. You might be able to configure permissions for the service to be able to create a desktop -- but then nobody will see it! Alternatively, you could grant the process the rights to switch desktops, and confuse the heck out of the user!
There's a setting you must enable in order to allow your Windows Service to access certain folders directly (like desktop) or show forms (including MessageBox pop-ups): "Allow service to interact with desktop"
To see this, right click on My Computer => Manage => Services and Applications => Services. Double-click on a service to access its properties. On the "Log On" tab there is a checkbox for this setting.
Here is an article for how to set it programmatically in C#
[Edit] As Stephen Martin points out in the comments: this is only valid advice for pre-Vista versions of Windows.
Because if nobody is going to see the Form, nobody is going to dismiss it - running a modal dialog is a recipe for a hang - so you want it to complain loudly when this happens rather than sit there quietly until you kill the process (or look at a stack trace to determine what'd going on). (The other obvious problem is, who is going to pick the DialogResult if there is more than one possibility?) You want to know when this is happening. (Assert dialogs that dont throw if they cant show anything are a fun way of making people mad.).
In other words, because you want to know when things are confused enough in your code that a dialog is being shown within a service context.
(I'm assuming you're using Windows Forms on .NET, eve though you didnt tag it as such)
(If you have correctly configured things such that the service is allowed to interact with the desktop, you won't get an Exception)
When a Windows Service is started it is assigned to a Window Station and Desktop according to well documented, though somewhat obscure rules. As mentioned elsewhere it is not assigned to the interactive desktop (unless it is set to interact with the desktop on a pre-Vista OS) but it definitely runs in a desktop.
It is a common misconception that services cannot use UI elements. In fact many services (such as SQL Server) have in the past used hidden windows and windows messages for thread synchronization and work distribution purposes. There is no reason that a Form cannot be shown in a service. If you are getting an error it is due to something you are doing with the form or some component that is on the form. The most likely issues have to do with whether or not you need an STA thread for your form or are you creating a message pump for your form or something similar.
While you certainly can use a form in a Windows Service you almost certainly shouldn't. There will be threading issues, cross apartment call issues, possible blocking UI issues, etc. There are a very few situations where using a window in a service is a good choice but there is a better way, with no UI, in 99.99% of all cases.
Because at the time when the operating system needs to paint the window there is nothing to draw the form on.