Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Delphi 6 and XP 1

Status
Not open for further replies.

poksal

Programmer
Aug 20, 2006
6
US
My old Delphi 4 will not run on an XP system.
Does Delphi 6 run in an XP environment and/or will an application developed in Delphi 6 run in an XP environment?
 
If you are not used with 2K/XP, keep an eye on user rights, not only in your developement station but in the machine where your app will run too.

MS have some directives about how to write XP compatible applications, hunting the doc down in the MS site and reading it is highly advisable.

From my experience, the two most conflictive things are:

1) HKLM is read-only for restricted users (no more one config key set for all users).

2) The "Program Files" folder is read-only for restricted users (no more writing program data in the program folder).

buho (A).
 
I'm confused. Delphi 3 works perfectly fine on XP, I don't know why Delphi 4 shouldn't...
 
Dear confused:

I had to load my D4 in a 98 machine.
When I try to load D4 in an XP machine it states that the program is a DOS based system and refuses to run the install. Also when I developed a simple app on my 98 machine and copied the files to the XP system it refuses to run the app with the same complaint. Additionally complicated by the data base being refused for the same reasons... DOS based, and XP has no DOS base... unless you added it. ... or so is my humble opinion
 
When I try to load D4 in an XP machine it states that the program is a DOS based system and refuses to run the install.

With you saying this, I'm thinking you have a system problem more than a Delphi problem. There shouldn't be anything DOS-based in Delphi 4. There isn't anything like that in Delphi 3, so I should think the same would be for Delphi 4. I mentioned D3 working fine, because I have a fully working install, installed on XP, with apps working fully on XP with no errors nor complaints (and no additional intervention - I installed it on XP the same way I would install it on a 98 system).

DOS based, and XP has no DOS base... unless you added it. ... or so is my humble opinion

It's really irrelevant to what seems to be the problem, as I see it, since DOS has nothing to do with Delphi 4. But XP has a wonderful DOS VDM as installed with the OS.
 
XP sometimes has the nasty habbit to delete things in its own system32 directory, and after that complaining about dos based application that will not run.

In stubborn cases, I uses the big axe method, ..clean install of OS

Steven
 
buho, I'm interested by your comments above. Do you have a link to the document you spoke of, as I am struggling to find it? How do you tackle the 2 issues you spoke of? Currently, we provide instructions, in the CD sleeve, for granting "Full Control" permission to the restricted user whilst installing the program as an Administrator. I'm sure this isn't the best way to do it!

Clive
Runner_1Revised.gif

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096
 
Ok, let's say I decide to clean install my XP OS... these days with no disk supplied.. how do I accomplish that?
 
@Stretch: The document I have is named "Designed for Windows XP.doc". I got it somewhere in the MS site little after the XP release. Do not expect it having solutions, only the guidelines (some ones, like the FUS compliance are actually not guidelines but delusions).

a) HKLM and the configuration keys:

The MS propossed method is (presumibly) to have a copy of the configuration keys for every user. Nice in the sense every user can have his own personalization. Nasty if you keys are mostly global keys, related to the program and not to the user.

Breaking the rules solution: change your key permissions during the instalation process. You'll open a hole of sorts in the system security... so sorry; the security model is flawed, you have little options.

b) "Program Files" folder:

Do not write in PF. Where to write? For user data, in "My Documents". Not my favorite option, but this is the way 2K/XP works. We are sticking to the rules here.

For program global data, things are not so easy. The better place is D&S\All Users\Program Data\<Your App Name>. Nice enough, such folder is read-only for restricted users in XP Home.

Of course, D&S\<User Name>\Program Data\ is read-write for the particular user, but if having a copy of global keys for every user is cumbersome, having a copy of global FILES for every user is a recipe for disaster.

So we are forced to break the rules again: change the permissions in D&S\All Users\Program Data\<Your App Name>. Another hole in the wall.

c) What about user data needing to be shared?

D&S\All Users\Documents\<Your App Name>. Of course, sooner than later some user will be blocked out due to a permissions issue. Change the permissions up front. Another hole and counting...

d) Other secured objects:

Same as above. Change the permissions. From files to pipes to folders to mutexes to whatever thing which uses a security descriptor and needs to be shared among users.

buho (A).
 
Many thanks buho, that's a great help.

Clive
Runner_1Revised.gif

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top