The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I wrote a program which will watch all files on your disk. I wrote it up here on CP.
1. Fire up the program.
2. Point it at her C:\ drive and have her start the label maker.
3. You will see every file created. (uses filesystemwatcher and is quite robust)
I even included a zip on that article that contains the pre-built app so you can try it quickly.
It's just one .NET exe.
I've seen this type of problem before which is related to the rights the process has (starting under Vista / Win7) to write files only in certain locations. %programdata%, etc. Anyways, from what I remember, the OS will simply block the creation of the files (which are written in improper places) without crashing the program or anything. The files just never appear. This is all related to when MS made those changes about not allowing a process to create a file (even configuration) in the Program Files directory.
From and old programmer with experiences of old bar code printers a lot did not have Windows printer drivers and needed special coding to produce their labels while other did have printer drivers that I would expect you will need to install and even then they might need the correct bar code font installed before they can print labels with bar codes.
Windows 10 does user names differently to older operating systems e.g. Windows 7. My desktop is stored at C:\Users\benab\Desktop on Windows 10 and C:\Users\Ben\Desktop on Windows 7. If the programmer was using her user name to store it to the desktop (terrible programming practise!), then that would explain it
A few years ago I had a similar problem. The program I was using, try to write something to a specific path. Because it had an error trap, it never showed an error in which I could find the path. I tried almost everything. No. it didn't work.
Finally I used a Hexadecimal editor (I don't remember which one) to look inside the guts. Almost everything is gibberish, but the strings appears bright as a full-moon light. And Voila! the path showed itself hidden inside «─í▀≈┌▀▐C:\Freemont\Data\Packs.dat▌┌░≈Σ
Because I didn't change anything to the program, when I closed the Editor and created the Folder, all work as desired.
I have found often with this type of behavior going from an old OS to Windows 10, problem is often related to security. Even running as Administrator does not always give you access to write. In the past creating the destination folder and adding explicit permissions to the account to have full control and turning off inheritance makes a difference. Given the age of the code there may be missing com objects or DLLs that are no longer part of the Windows 10 OS. These problems are a bear to resolve but with the correct tools you'll learn what's generating the error.
It sounds as if you are dealing with two separate products: a custom "line of business" program written by someone who no longer wants to support it, and a packaged barcode/label making program. Or is it just multiple custom programs that form the "line of business"?
It sounds like the label product installed, but did not create two desktop icons see was expecting to see. It is a bit vague on exactly when the two files are supposed to be created: is it after the software is installed or is one part of the "line of business" software generating those two files which she clicks on and the label software is supposed to utilize?
It is just a slow and steady process to determine her problem, and you indeed might end up with "sorry, there is no solution." How important is this client? Can you skip a lot of the determination work and just get to "sorry" earlier?
Found this that may be fairly easy to figure out what it's trying to create.
There are other solutions too for tracing file access.
It's may be failing the file creation as it's using a on-existent path and hopefully this software sees the failure.
I would run the program in a VM of Windows 7, and use the old SysInternal Tools to identify the file creation.
I have had THESE kinds of problems when going to Windows 8 and Windows 10 from very old code that writes stuff to it's own PROGRAMS folders... ALL due to security differences.
Windows DOES NOT want things written "anywhere", data goes in appdata, etc.
And running as Admin does not always fix stuff, because the resulting EXPLORER instance is NOT in admin mode, so it may not see the files created.
That is the FINAL nail in the coffin. If it is using ANY KIND of share, KNOW THIS: A share created with an ADMIN account is NOT accessible to the USER account, AND VICE VERSA. This crushed us recently on a VM setup where the developer runs as admin, but the use program cannot. AND BAM, the share can only be accessible by one at a time, until you tweak the registry!
This program is extremely handy--it will show you every file that is being created/read/etc, along with what registry keys are being read/added/etc. The log files get huge fast, but for a tricky job like this it will be worth its weight in gold. It's helped me track down really weird/obscure stuff like this.
I'd upvote every suggestion that the program is trying to write files in a now restricted space. There are so many butts running around with chunks taken out of them by this security change, mine being one of them. It's an easy change if you have the source code - muahahaha - don't comment on that. As a consultant, I'd say sorry, your code is obsolete, here are some options and here's what it will cost you. Let me know if I can help.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759