"DART_SDK" environment variable is officially removed? - dart

I remember DART_SDK was necessary. but now I am not able to find any document about DART_SDK.
When do we need to set DART_SDK ? I think there's no need in normal cases.

Some scripts needed a way to find the SDK and for this usually this environment variable was used. But as far as I have seen most code went away from this way of finding the SDK directory (see for example http://dartbug.com/17349, http://dartbug.com/16994, http://dartbug.com/15019 (fixed), http://dartbug.com/10444)

It depends on the tools you're using.
For example, I made DartVS use this variable to locate the SDK for the Analzyer (I saw it was already being used, so decided to piggy-back on it!).
In the next version, we will automatically download and unzip the SDK if this variable isn't set (so it won't be needed); however support for it still remains so you're able to change/override the SDK being used (eg. if you want to use dev channel versions, or go back to an old version).
(If you keep your SDK in the same place, then there shouldn't be any maintenance in keeping this set/valid. The Chocolatey package keeps the path the same across upgrades to aid this :))

Yes. You are right. This variable becomes unofficial (undocumented).
Of course, this is possible determine from the Dart script the path to Dart SDK.
But for the new programmers, that want to locate the path to Dart SDK from the non-Dart scripts (eg. from the .bat files), this can be problematic because currently not exists official way to specify the path to installed Dart SDK.

Related

Qt generic error message

This is the error messsage I get.
I know it's kind of an eye roller, that it's difficult nigh impossible to tell what I may need without the source, but it seems like a deployment problem as people that installed the Qt SDK can run it. Plus, I figured I'd have better luck asking here than with a chinese developer that speaks google-english.
So here's what I've done:
I installed the MSVC2012.
I used a program called cffexplorer to see what the exe was looking for. I have the 7 or so .dlls that are at the top of the tree.
I found a recent (jun 2013) qwindows.dll from elsewhere on my system and put it in ./plugins (I've tried this file in ./, ./plugins, and ./plugins/platforms
I created a qt.conf with the following data (I determined the format from an existing Qt based app that works)
[Paths]
Plugins = plugins
Yet, I continue to get this message. Any suggestions on what I might look for to clear this up?
Ask the developer what compiler was used to build the application. Then you will need the right dll (that was built with the same compiler as the application). Also notice that (by default) the documentation says that qwindows.dll should be in the platforms folder in the same path as your executable, read more here. Depending on whether the developer used a Qt built with angle, you may also need: libEGL.dll and libGLESv2.dll. Dependency walker might help you find dependencies that are not there.

Using WiX, Windows Services are not installed after a downgrade

While testing the downgrade functionality of one of our WiX-built MSIs, I have noticed something odd.
I have allowed downgrades in the MajorUpgrade element and I have scheduled that element to be afterInstallInitialize (but I have tried it thoroughly with afterInstallValidate and I experience the same problem; we can't have it after that action, but I thought I'd test it).
Many of the files (e.g. the DLLs in our Service's bin folder) are of a higher version, with each release; therefore, the version we are downgrading to includes files of a lower version. Yet all of those files are installed fine, during the downgrade, apart from the Service EXE files; further, the Services are also not installed in Windows.
Considering all of the above, after spending two days on this problem, and after much searching, I appear to be at a loss.
I have tried two things that seem to provide some hope:
1) I have tried setting the REINSTALLMODE property to amus. This ensures that the EXE files are installed, along with the Windows Services. But most things I read about that property warn against using it, and I even have to surpress ICE40, in order to get my package to build, when setting that property. This all concerns me, as I am not sure what negative effects could be missed, if I use this property in my MSI files.
2) When I remove the KeyPath attribute from the File elements that mark up the Service EXE files and place that attribute on the Component element instead, the Service EXE files are installed onto the system during the downgrade, but the Services are still not installed in Windows. After looking into this, it seems that the KeyPath attribute must be on the File element, if I'd like Services to be installed. So it seems to me as if this idea will not help.
Any help or advice would be very much appreciated. We really could do with providing downgrade functionality.
Thank you all for your time.
MSI is essentially opposed to the idea of downgrades. Once a file is on the machine, MSI tries very hard to keep the latest version of the file around as, among other reasons, downgrading the file can re-introduce a security vulnerability. I'd suggest not directly supporting downgrades; instead, you can show a message that tells the user to uninstall the higher version first.
My solution was to use Burn to provide the 'downgrade' functionality using a custom bootstrapper application.
The bootstrapper detects, downloads, and then installs the new version. In the case of a downgrade it performs an uninstall prior to the install. However, this requires that you execute the bootstrapper of the currently installed version to get the ability to uninstall.
You then also need to worry about any state that will be removed as a consequence of uninstalling, this needs to be preserved the same way as you would during an upgrade.
Using Wix, to allow downgrading and still have the Windows Service install properly on downgrade, use the following combination:
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade Schedule="afterInstallInitialize" AllowDowngrades="yes" />
I was also using WixSharp to generate the .wxs file and used this code to do so:
// https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode
// a = Force all files to be reinstalled, regardless of checksum or version.
// m = Rewrite all required registry entries from the Registry Table that go to the HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT registry hive. Rewrite all information from the Class Table, Verb Table, PublishComponent Table, ProgID Table, MIME Table, Icon Table, Extension Table, and AppID Table regardless of machine or user assignment.Reinstall all qualified components.When reinstalling an application, this option runs the RegisterTypeLibraries and InstallODBC actions.
// u = Rewrite all required registry entries from the Registry Table that go to theHKEY_CURRENT_USER or HKEY_USERS registry hive.
// s = Reinstall all shortcuts and re-cache all icons overwriting any existing shortcuts and icons.
project.AddXml("Wix/Product", "<Property Id=\"REINSTALLMODE\" Value=\"amus\" />");
// Allow downgrading versions
// https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
project.AddXml("Wix/Product", "<MajorUpgrade Schedule=\"afterInstallInitialize\" AllowDowngrades=\"yes\" />");
See also:
https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode
https://wixtoolset.org/documentation/manual/v3/xsd/wix/msiproperty.html
https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html

Copy Delphi Profile

My computer crashed recently. We have a Delphi app that takes a lot of work to get running.
One of my co-workers has it all installed still. Is there a way to copy the stuff stored in the palette? And the library paths?
I am using Delphi 5 (I know it is very very very old)
That information is stored in the Registry. I don't know exactly how Delphi 5 does it, but try looking for a key called HKEY_CURRENT_USER\Software\Borland\Delphi\5 or something like that. You'll find all the registration information under that key, including a list of installed packages. You can export the keys to a registry file, copy it to the new computer and install it.
Standard disclaimer: Mucking around in the registry manually can be risky if you don't know what you're doing. Be very careful, and if this solution causes your computer to crash, your house to burn down, or demons to come flying out your nose, it's not my fault.
Try CNWizards which has an export functionality for your IDE settings. You can use the same tool restore them on the new machine. We use it to get the same settings on every development machine. In that way we can ensure that all builds are the same, regardless of who built it.
Based on my experience of having done this a few times(!), the most important registry keys are:
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known Packages
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Library
and possibly
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Known IDE Packages
and maybe
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette
HKEY_CURRENT_USER\Software\Borland\Delphi\5.0\Palette Defaults
So long as you have done a standard D5 installation first.
It's easier/more reliable to let the IDE fill in the other bits as you start using it and you change options as appropriate. Some component packages, eg madExcept, DevExpress etc are often best re-installed using their own installers anyway.
Unless you're going to have multiple users on the same machine using Delphi then the HKLM stuff isn't really all that important - I don't think.
As a related aside - I have learned that a good way to handle this is to build a FinalBuilder script (or similar) to set up my Delphi environment each time I decide to use a new machine/installation. I copy/download/checkout (which can be done in FB too) all package source then use FB to compile it, copy it, create dirs, and fill in the appropriate registry keys etc. I always get a consistent environment and makes it much easier to rebuild individual components or packages as and when they get upgraded too. The items can also be put into the script in 'dependency order' so that you know to re-compile a dependent package if something else changes. I now have a single FB sciprt that builds D5, D2007, D2009, D2010 environments and packages of all my main components, all depending on which compiler(s) I'm interested in which I indicate by a simple variable. Well worth it.
Seems to have just worked for me on a Win 7, SP1 and Delphi 5
Logged as user with Delphi & 3rd party components installed.
registry export
hkey current user\software\borland
(no other borland products so selected Borland)
rather than Borland\Delphi\5.0)
Logged into pc as new user.
Did not start Delphi5 (i.e. never started for this user).
Regedit File, Import
Started Delphi all components, including lots of 3rd
party, present.
Project compiled as expected under new user.

Updating UMDF drivers during development

I am having some trouble updating UMDF drivers using "devcon" during a
standard code-deploy-debug cycle. The problem is that "devcon update" isn't
really updating anything unless the version number or the date of the DLL
file and the INF file has changed from what is stored in the system's driver
cache folder. After a maddening series of experiments I've discovered that
one way to force the thing to use the latest files is by doing the
following:
Change the parameters passed to
"stampinf.exe" in "makefile.inc" by
explicitly setting a version with
the "-v" option.
Modify the
resource script file ("DRIVER_NAME.rc") to first define
VER_USE_OTHER_MAJOR_MINOR_VER
before including "ntverp.h" and then
explicitly define
VER_PRODUCTMAJORVERSION and
VER_PRODUCTMINORVERSION. You'll
note that this system does not allow
us to change the build and the
revision numbers. On Win7 this
seems to be fixed at 7600 and 16385
in "ntverp.h". Is this by design?
So, I first modify "makefile.inc" and set the "-v" option to something like
"1.1.7600.16385" manually incrementing the minor version for every single
build and then modify the RC file and update VER_PRODUCTMINORVERSION with
the same number.
Alternatively, if I run a command prompt under the SYSTEM account and go and
delete the driver cache folder in
"C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER" before
running "devcon" then that works too.
Now, I am thinking I am missing something fairly basic here as this seems to
be a rather painful way of doing it. Please help! Thanks!
Why can't you just unplug the device and replace the unloaded DLL? You shouldn't need to reinstall the driver, just replace the module. Note that you shouldn't do this during production or anything that has to do with customers, but if you're writing a driver, just slam in the new module with the same version number.
On Win7 this seems to be fixed at 7600 and 16385 in "ntverp.h". Is this by design?
Yep, at least until the next service pack
As Paul Betts has suggested above, the way to go seems to be to simply replace the UMDF DLL directly in the driver folder (for e.g. c:\windows\system32\drivers\umdf\) after disabling the device either in the device manager or using "devcon". I'd asked this question on Microsoft's device drivers newsgroup before posting here but hadn't got a satisfactory response - but some folks ended up responding there after I posted here! So I'll put up a link to that post as well:
http://bit.ly/6PDxKT

Delphi app calling cobol app -> error

We need to get data out of an older accounting system. We have received a dll that gives us access to the data we need. It includes a type library that we have imported.
If we run our test application from the same directory as the accounting system, everything works fine. If we try to run our application from a different directory, we get the following error:
Dynamically Bound RTS
Runtime DLL 'OOPS', version 3.1, entry point oops
not recorded in registry, not found or incompatible with requirements
of dynamically bound COBOL program. Dynamic binding of RTS requires:
Runtime DLL 'OOLSM', at least Version 3.1
Can anybody provide some helpful information on this?
Are we supposed to have some kind of cobol runtime in our directory? Or in the path? Or registered in the registry?
Thanks,
-Vegar
Updates:
Setting the system %path% to include the path to the accounting system seems to do the trick. Including it as a user variable did not have the same effect for some reason.
What Cobol are you using?
I had done this for year with Microfocus NetExpress 3.1, and all works just fine.
I write COBOL DLL to access COBOL data files, and also write Delphi DLL to add new features to old COBOL systens.
And yes, I use to set the runtime path, that is environment variable called COBDIR, there are others,but usually %PATH% and %COBDIR%is enough.
If you give more detais about what COBOL compiler are you using, and how is the dll interface that you are calling, will me ore easy to help you.
And maybe "Dependence Walker" can help you to identify what run time files are missing, if it is.
http://www.dependencywalker.com/
If it works from the accounting app's directory, but not a different one, the first thing I'd try is adding that directory to your path.
Unless it is already loaded into memory, Windows looks for DLL's that a program is requesting in every location listed in its PATH environment variable, and also in the directory the application is located within.

Resources