Strconv() data corrupted in exe creation?

[grahamrhind]

Hello,

I distribute lookup tables with an application, which had been encrypted using Cryptor. As Cryptor does not work well with Windows 7 I altered the encryption to use strconv(). This works fine in testing.

When building an .exe file with InstallShield 5 for Foxpro these tables go into the build process looking correct, but come out of it encoded differently, which makes them useless. Can anybody confirm that this occurs, tell me why and whether there's a workaround?

If not, does anybody have a simple but effective (and quickly implemented!) piece of code for basic encryption (it doesn't have to be hacker proof) which won't get messed up by Installshield? I'm using VFP 9.

Many thanks.

 

[grahamrhind]

I think it may just be down to a simple case of having reversed the parameters at some point in the process. I'm just having a dizzy time today. Thanks for the extra information, though.

 

[grahamrhind]

Going back to my initial problem, I have found out that tables with strings processed using chrtran have the same problem - that they become corrupted during install. (See:

http://dl.dropbox.com/u/450542/BeforeAfter.png).

Following this through each phase in the process I have found that it is not InstallShield itself which is causing the issue, but installation into the Windows 7 directory \program files (x86)\. Table installed into that directory become corrupt (strings within them, that is), whilst the same installation to a different directory, such as c:\grc\ installs without corruption.

Can anybody shed any light upon what is happening, why, and if there's a way around it?

Thanks!

 

[Olaf Doschke]

When are you actually decrypting the values? You can't vfp run during the installation itself, so you run your decryption once after the install, right?

Then the phenomenon is easily described: This is file virtualisation. Any change you make to a file stored within program files goes into virtualisation directories. You should find the decrypted data in the first users profile at:

C:\Users\”username”\AppData\Local\VirtualStore\ within the program files subfolder there.

The simple solution is as you did, not install to progrm files, the clean solution is to not store data into program files or if, then also let installshiled give write priviliges, which you can by right clicking your application folder in the ISX project and defining the access rights.

Bye, Olaf.

 

[grahamrhind]

Hi Olaf,

This has nothing to do with VFP, actually, and no decryption takes place. The corruption occurs when moving a dbf into the'\program files (x64)\ directory on a Windows 7 64 bit machine. Even doing it via Windows Explorer it causes the same corruption, so it's clearly something to do with the inbuilt permissions of that directory which I can't change (and wouldn't want my customers to have to try to change either).

And yes, the files at C:\Users\"username"\AppData\Local\VirtualStore\program files (x86) show the same corruption.

I can't find what you're referring to in the InstallShield program, and I am hesitant to start playing about with permissions because the install needs to work the same on every Windows machine.

My workaround currently is to install outside of that directory, but I would like to know why it happens (and why I can't find any reference to other people having this issue ....).

Cheers.

 

[Olaf Doschke]

First of all I can't say I heard anywhere before that files get corrupted when written to program files, also not with UAC in control. Setup is working with sufficient privileges in order to write to program files, no matter what files. The exe itself also is left untouched and not corrupted. Your dbfs just look to me like the unencrypted versions ou install, as I don't see how your encrypted data looks I can't judge that of course, but the files are written 1:1 by Installshield. The corruption cannot really occur there, as the files remain unchanged, changes are then written to Virtualstore and then also read from there. Problematic is, that each user will have it's own Virtualstore and so it's own copy of the file.

The feature of ISX is not very hidden. I alrady said you right click on the files you install. Within Installshield of course, within the ISX project.

There are, as mostly, many ways to do the same stuff. Simply open your ISX project now or start a new one. In the ISX project, at one step you define the files you want to install and at that step you can right click on the files and then define permissions, not directly in the context menu, but click through to "properties", properties is always an interesting submenu dialog, isn't it?

If you use the Project Assistant tab of ISX, you have a step "Application Files". There you see the destination computer and it's folders and put the files you want to install there on the right side, in the directory listing within [ProfgramFilesFolder] and a subfolder for your company and one for the application you put the files. As I said earlier, simply right click on the file you want to set permissions. And as already said choose "Properties" frm the context menu. Now you're in the general tab and in the bottom left corner is a button labeled "Permissions". Guess what it does.

If you use the Installation Designer tab, almost the same destination computer folders and files can be seen at step 2 (Specify Application Data) in the Files subnote.

When you're in that Permissions dialog of cause ISE can't know what users are on the destination computer, but click on Help to let ISX explain how you set permissions.

Now right click on the names, ISX adds [%USERDOMAIN], so you actually can set permissions for the domain the installation user belongs to. Also you can use genreal names like EVERYONE with or without the domain set. I'd add both to make sure. And below you set eg "Full Control".

Now you lower the security for those files, but then it's ok from the perspective, that you only do that for the files you want users to write to, eg your dbfs.

There of course is the alternative to install into application data. Just go over to the folders of the ISE project Files dialog and see there is an AppDataFolder and CommonFilesFolder. Right click on destination computer, then on "Show predefined folder" and you find more.

Are you never curious about the stuff yyou see on screen in general, right click on something, click on something, explore the possibilities? Especially if you have a problem with file permission, admittedly you first need to know you have such a problem, then it's only natural to explore the spot, where you define what files to install in your installation project.

Bye, Olaf.

You can also see this

 

[grahamrhind]

Hi Olaf,

I appreciate the time and effort you put into answering my, and other, queries - I really do. But I'm not sure you're quite getting this issue. Or I'm missing your point entirely.

Because:

1) You say: "Your dbfs just look to me like the unencrypted versions you install" Please look at

http://dl.dropbox.com/u/450542/BeforeAfter.png

. The top three lines show the data as it is written into the InstallShield file and what the InstallShield installation writes when it writes to any directory on the disk except \program files (x86)\. That is what they should look like. The three lines under are the same three lines after the same installation has been done to \program files (x86)\. They don't look the same to me! That's the corruption you are seeing.

2) As I said, I have established that this is neither a VFP issue nor an InstallShield issue. Because just copying or moving these dbf files into \program files (x86)\ has exactly the same corrupting effect. I believe it is a Windows 7 64-bit-specific problem, and I just don't have enough knowledge of that operating system to work out why it is happening there. There is no issue with XP or Vista.

3) I'm way past the stage of being curious about what things do on the screens I see! I just want to get the damn thing working, and this issue has cost me months of work, most of it looking in places that were completely irrelevant! But, and I did do this before, I tried to change the settings in InstallShield that you pointed out. On the Windows 7 64-bit machine none of those settings can be changed.

I can only assume that this whole issue has to do with the 64-bit nature of the OS. I don't know how much experience people on this forum have of it, but it can be a headache with VFP, that's for sure!

Thanks again Olaf!

Graham

 

[Olaf Doschke]

Please look at

http://dl.dropbox.com/u/450542/BeforeAfter.png

. The top three lines show the data as it is written into the InstallShield file and what the InstallShield installation writes when it writes to any directory on the disk except \program files (x86)\. That is what they should look like. The three lines under are the same three lines after the same installation has been done to \program files (x86)\. They don't look the same to me! That's the corruption you are seeing.

Ah, either this is the first time you describe what those pictures display or i overlooked that beforehand.

To me the second version simply looks like a double encrypted version, eg. I still don't see how copying a file changes it, unless you have an encryption software package running, either cryptor to crypt the dbfs or something else.

Neither installshield nor the OS do influence files during a copy, that would be a totally new effect.

Could you perhaps copy the dbf somewhere else, eg into c:\public\ and see if you get the same effect. That would at least show if its the program files folder, that influences this, or if it's copying the file away from the source folder, that makes it "corrupted".

Also think about this: Real corruption would mean the file would not be recognizable as a dbf anymore. The "corruption" only seems to work on the net dbf data. It looks rather that you have your bdf encrypted with a tool like konxise or cryptor, which decrypts registered files at the places they are registered, while copy of the files remain encrypted. Then you only see the crptor/konxise encrypted version of your dbfs.

Do you have such a tool installed? OR is the original folder encrypted by os, is it on a bitlocker drive?

But, and I did do this before, I tried to change the settings in InstallShield that you pointed out. On the Windows 7 64-bit machine none of those settings can be changed.

Huh? What has the OS to do with this? This is done within Isntallshield, with the project you create to create the setup. and this works the same on all OSes. You say Installshiled itself has no context menus on Windows 7?

Bye, Olaf.

 

[Olaf Doschke]

Another question: What version of Installshield are you using to build your setup? I was talking about Installshield Express Limited Edition for Foxpro 5.0 coming with VFP9, it's even this small express version having that feature of setting file permissions.

The file security you set via windows explorers I talked about is just meant as a comparison. If you don't see a security tab in file properties on window 7, you simply don't have sufficient privileges to change file security permissions. But the setup has during setup and you can set file permissions beforehand during the creation of the setup project.

Bye, Olaf.

 

[grahamrhind]

Hi Olaf,

You said: "To me the second version simply looks like a double encrypted version"

Yes, I agree. And I know that a simple copy shouldn't do that to a file. But that's what is being done. That's the mystery. I can copy the files to other places on the disk, to other directories, without any effect to them. That's why I'm emphasizing that the issue seems to be with only that one directory: \program files (x86)\ which, unfortunately, is when 32 bit program get installed by default.

You said: "Real corruption would mean the file would not be recognizable as a dbf anymore. The "corruption" only seems to work on the net dbf data."

Yes, I agree. Which is why I'm so flummoxed by this. I have Cryptor on my PC but I'm not using it any more because InstallShield won't register the .dll on a 64-bit machine when creating an .exe. That's when I started looking for a new encryption method, which is what started this saga. So I can't imagine it's Cryptor, because it's not being used any more.

You said: "Huh? What has the OS to do with this? This is done within Installshield, with the project you create to create the setup. and this works the same on all OSes. You say Installshield itself has no context menus on Windows 7?"

It has context menus. I just can't change anything by clicking on them. Don't blame me - I'm just the messenger! Perhaps InstallShield needs special permissions to run in a certain way in 64-bit Windows. I haven't the faintest idea.

I have posted this issue on the Windows 7 forum to see if there are any ideas from that direction. No joy yet. Maybe I'm just unlucky with my PC, but I do feel that there's probably an obvious setting somewhere that I'm overlooking ....

 

[grahamrhind]

Hi Olaf,

Yes, I'm using InstallShield Express Limited Edition for Foxpro 5.0.

I've found a way of setting the permissions in that version on this machine, so I'll give that a try.

Graham

 

[grahamrhind]

Olaf,

Changing the permissions in InstallShield does not change the issue. I.e., even with "Full Control" the dbf file contents still become "corrupted".

I'm going to call it a day on this issue - it's taking too much time and effort, and I have a workaround - not installing to that directory. I hope when other's migrate to 64-bit that they take note, as the problem is not immediately obvious - you can run your application, it just doesn't work in the right way any more. And if I come across an answer, I'll post it.

Thanks again for your efforts!

Graham

 

[Olaf Doschke]

Ok,

I'll accept that. Just some arguments for anyone following this or finding this: Windows does not alter files copied to \program files\, there is on strong reasons why this can't be the case with the dbf as shown by Graham:

Why would only the data appear mangled, but the dbf file structure remains intact including the field name.

Graham, let's say just copying a dbf file changes it the way you show, then there must be something involved with knowledge about the inner structure of a dbf, this can't be Windows7.

I actually tried on Windows 7 32 bit and I can try on 64 bit later, but I doubt there is a difference in the file system/file handling.

I suspect you have some addon installed on your development machine you forgot about or you ancrypted the data using the encryption sample of VFP solution.pjx and already forgot about it. This needs to be something in the range of foxpro tools or in your code, Neither Installshield nor Windows are changing your file in the way shown, they can't, they don't know dbfs.

Bye, Olaf.

 

[grahamrhind]

Hi Olaf,

Some fair comments, but to emphasize some points which may have become lost in the length of this discussion:

1) The directory concerned is \program files (x86)\ and not \program files\

2) Important to note is that "untouched" standard dbf files can be copied to that directory without change or corruption. The problem is occurring when the data within those files has first been "encrypted" using either strconv() or chrtran(). Though in both those cases I am just replacing one ASCII character with another, so there should be no real issues as the contents are still "readable", these are the files where the contents are mangled. I think this important point was lost somewhere along the way!

3) No add ons and no other encryption of those tables. I use them every day of my life because I sell the data - you'll have to trust me on that. The strcon()/chrtran() is being done for the same tables when included in a program that uses them, and that's when I discovered the problem.

Graham

 

[Olaf Doschke]

OK,

1) I said I don't have win7 64bit, that folder is there for 32 bit software in the Win7 64 bit edition, while the 32 bit edition has no extra folder for that. Still it's just the normal NTFS file system. I doubt there is a change

2) I understood your post that you get the effect for unchanged dbfs, just manually copying them, as you said " Because just copying or moving these dbf files into \program files (x86)\ has exactly the same corrupting effect.".

As you say you merely exchange letters with other letters there is no substantial difference in the set of bytes used. More general spoken: If any byte values would cause a change during copy, how could binary files like EXE files survive that changes windows does during copy without any changes?

There has got to be some third party component involved. I'd also double check what source folders your Installshield project uses as the source of it's setup creation.

Bye, Olaf.