I know I need to use .NET 4.0 for older OSP200 controls running Windows XP Embedded SP3 but I'm looking for help about the latest version of API on the machine, it is showing 1.22.0 in the Scout.log report but the front panel of Scout says the Thinc API is "Unknown", is 1.22.0 too new?
**************************************************
[INSTALLED_PROGRAMS]
THINC-API=1.22.0
D300win Ver 3.1.4.20=3.1.4.20
OSP-PLC Loader Ver 3.1.4.0=3.1.0.0
Vektek AWP version 1.2XP=1.2XP
WebFldrs XP=9.50.7523
Okuma THINC Startup Service=4.6.0
**************************************************
Our application started out with the latest API/SDK and we backed it down to .NET Framework 4 for Win XP target. What version level of Okuma.API and Okuma.Scout should we be using to be compatible with .NET 4 and our version of API?
Currently I have 1.18.0 of Okuma.API and 4.12.0 of Okuma.Scout.
We are getting an Okuma DLL not found error in our programs Log File.
**************************************************
2020-07-15 01:57:12.6920 [FATAL]: Error Initalizing Cmachine and CVariables: Could not load file or assembly 'Okuma.Interop.MCMDAPI, Version=1.0.3.0, Culture=neutral, PublicKeyToken=4e002078be5840a0' or one of its dependencies. The system cannot find the file specified.
**************************************************
I think I see what has happened here.
I suspect that when you downgraded your app's THINC API version, you didn't remove all of the old API references. Okuma.Interop.MCMDAPI is not a part of 1.18.
Try removing that reference.
Also, I know SCOUT is over-due for an update. It is in the pipeline.
You should always use the latest library version available for development.
I think the latest version of THINC API that SCOUT knows about is 1.22 which means the SCOUT app should be able to correctly identify it in your case.
There are several possible reasons that the SCOUT app might not be able to positively identify the THINC API version. One of the most common reasons is a miss-match of Custom API files. If you send the full SCOUT log to "API" at Okuma dot com, I can take a look and tell you what is going on.
When developing apps using SCOUT, please do not rely on SCOUT to positively identify the THINC API version. Use the ThincApi.DoesMachineSupportThincApiVersion Method instead.
Related
I'm trying to revive some old software: it was developed on Windows XP, and I'm trying to get it working on Windows 10.
However, this software is dependent on api-ms-win-core-wow64-l1-1-1.dll, which isn't co-operating: Dependencies states that api-ms-win-core-wow64-l1-1-1.dll is missing imports, while Visual Studio's dumpbin states that it has no dependencies.
I'm aware that Microsoft has migrated its functionality and that nobody should link to the implementations directly, but is there any way to get api-ms-win-core-wow64-l1-1-1.dll functionality for this old software on Windows 10? Alternatively, is there an accessible way to rewrite old .dlls to link to Microsoft's Win32 APIs?
(For those who need the file: I got api-ms-win-core-wow64-l1-1-1.dll by running $ locate api-ms-win-core-wow64-l1-1-1.dll on a linux machine with wine installed on it.)
I'm not sure whether this directly addresses your issue. I'm supporting a Java app which uses JNI with some native Windows libraries. I used Dependencies to check what was missing and it turned out to be api-ms-win-core-wow64-l1-1-1.dll (through WS2_32.dll).
The solution for me was to install the latest VC redistributable from MS.
Getting libraries from Wine is probably not a solution, in case you seek to use them outside the linux environment. (They are wrappers and obviously not using native Windows assemblies)
You can get some success by using extracting them from the ReactOS live CD. However, you should be aware that many of these are umbrella libraries, as explained here:
An umbrella library is a single static-link library that exports a subset of Win32 APIs. For example, an umbrella library named OneCore.lib provides the exports for the subset of Win32 APIs that are common to all Windows 10 devices.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-umbrella-libraries
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis
I am having difficulty installing various Julia packages on my Windows 7 laptop. When trying to add certain packages I receive the following error:
(v1.3) pkg> add MbedTLS
Updating registry at `C:\Users\uname\.julia\registries\General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
Resolving package versions...
ERROR: Unable to automatically install 'MbedTLS' from 'C:\Users\uname\.julia\packages\MbedTLS_jll\wUtL4\Artifacts.toml'
Several packages install happily, and I think I've narrowed it down to those that are supplied via BinaryBuilder.jl, such as MbedTLS, Arpack, OpenSpecFun. If I try to install any packages that have any such packages as a dependency I get the same error message when it hits one of these (initially encountered when I was trying to install Genie.
I am using the latest Julia (1.3.1), although I encountered the same issue previously in 1.2 - I managed to fix things eventually in that case, and tried a similar approach (manually downloading and placing in packages folder) but have not been able to fix things in this instance (although I confess that my notes were a little lacking so can't be certain I'm doing the correct thing). The various packages seem to exist in ...\.julia\packages\ (although not in .julia\compiled), but julia complains whenever I try to add them to some environment.
I don't think I understand julia's package system well enough to see quite what is going on here. I have seen other people with similar issues but not found anything yet which has worked - any help would be much appreciated!
This usually is due to an issue with your powershell installation, which is what we use to download these binaries in Julia 1.3 and 1.4. In particular, most of the internet (including GitHub, where most of our binaries are hosted) disabled SSL v3, TLS 1.0, and TLS 1.1 in 2018. Windows 7 is old enough that it doesn't speak TLS 1.2+ natively; instead you must install two packages:
This TLS easy_fix
Windows Management Framework 3.0 or later, to get Powershell v3+
This is necessary on Windows 7, but not on Windows 10. For more instructions, you can read the Julia platform specific instructions: https://julialang.org/downloads/platform/
I am learning to build a web application for Hbbtv using the Hbbtv SDK.
So for testing a sample app, I was looking for an emulator and came across FireHbbtv Extension by firefox.
However, whatever I do, it says the extension is not compatible with the version of Firefox. can any of you help with what is happening
Firehbbtv extension is abandoned, but you can install it using an old Firefox version (<52 as far I remember). Make sure the automatic updates are disabled if you want to keep the extension available.
There is another HbbTV plugin named hybridTV (https://github.com/karl-rousseau/HybridTvViewer) It works fine, but it is in development.
There is also a third option, using the opera (now called vewd) SDK. You can find the info and the virtual machine downloads visiting
https://www.vewd.com/products-services/vewd-tv-emulator/
I have had a Windows 8 build associated with my app, say with version 1.0.4. I also have an active 1.3.4 version which targets Windows 10. I wanted to make the 1.0.4 build unavailable so I removed it. But it still appears in the Windows Store on Windows 8 devices. Then I read that I need to submit an update and change the pricing & availability. But I don't see a way to do that without also removing the 1.3.4 version from the Windows Store. Any ideas?
EDIT: I added an image of the dashboard which shows which packages are installed. The Windows 8 package is still available even though it is not visible in the dashboard.
Based on your description, can I understand that your app has two packages, one version is 1.0.4 that targets Windows 8, another version is 1.3.4 that targets Windows 10, and you just want to make the package version 1.0.4 unavailable, am I right?
I suggest you to remove package version 1.0.4 from the submission and you don’t need to change the pricing & availability, after the update is published(new submission submitted in the store), no new customer on Windows 8 will be able to acquire the app(though customer who already have is can continue to use it). The app will still available for new customer on Windows 10.
More detailed info, please refer to guidance for app package management
In addition, there are just Windows Phone store and Windows Store now, please note it.
When ready to present an app to put on the appStore; is there a minimum version of Xcode required? Or any version however old is good?
Thanks
According to Apple,
You should always use the latest Xcode (requires Apple ID to login)
Note: You can build with the very latest SDK, and run your app on an earlier operating system. The Deployment Target build setting controls the lowest operating system version that your app will run on. This setting is independent of the Base SDK build setting.
Using any other SDK is TEMPORARY
It's important to understand that using an older SDK is a temporary workaround, not a solution. Issues preventing your app from using the latest SDK should be fixed as soon as possible. It will be much easier to fix these issues while the older build system is still supported.
Latest & Easiest way
Application Loader
You need to have some minimum version of the XCode, but no need to have the very latest one...
And for easy steps & guidelines to submit app in to appstore please check out the following url
Easy Steps for App Store Submission & Certificates creation - By iOSCodeGUIDE