I'm having a problem with a patch. The patch supports English by default, as well as a few other languages. When a non-English language is chosen while installing the patch in Windows Vista/7 error 2229 occurs referring to a failed SQL query to the CONTROL table. Any suggestions?
Related
I've installed Rust on the system.
I've installed the Corrosion plugin in Eclipse (v.2021-03 - 4.19.0).
I can open rs files and they show syntax highlighting.
But I'm getting this annoying thing when I try to do any rusting: "Rust support not found" --> Open preferences --> Error: "Input a valid path to the Rust Language Server (rls)".
The path for "Language Server" in that dialog is wrong: it is my
Eclipse installation directory. I have installed Rust under D:\apps\rust. I have run this command among others:
C:\Users\Mike>rustup component add rls rust-analysis rust-src
... in the Eclipse dialog I can configure the path to the RLS using a file-chooser dialog. What am I looking for? A file? A directory? Which one?
NB I have also downloaded (and expanded) the RLS from here.
NB2 Perhaps Rust HQ could cater for this OS + IDE combination, with more explicitly idiot-proof instructions?
RLS is the acronym for Rust Language Server. It's an executable file, on Windows rls.exe, on Linux and macOS rls.
The term server is a bit misleading here, as a language server is in general a locally executed headless application. The IDE or editor runs the language server application to get back via the standardized Language Server Protocol (LSP) e.g. which errors and warning exist where and which code completion proposals have to be displayed at a given cursor position.
RLS is written in Rust and is shipped with Rust, in the same directory as the Rust compiler (rustc), at least that was the case in the past. These days, the rust-analyzer (rust-analyzer.exe) is the replacement for RLS and offers better support than RLS. Eclipse Corrosion detects it and prefers rust-analyzer, if it is available in PATH or is found in some standard locations (see Eclipse Corrosion Rust language server documentation and rust-analyzer Eclipse Corrosion documentation).
Since in your case no language server for Rust language support was found, make sure rls.exe or better rust-analyzer.exe is installed on your system (as it is not part of Eclipse Corrosion) and in the Eclipse IDE the language server executable file is configured as language server in the preferences for Rust.
Please note, Eclipse Corrosion is mainly developed and tested on Linux. Therefore, the documentation for Windows might need to be improved and Windows specific glitches might be overlooked. If you find something, make sure it has been reported, preferably with a patch (as I did some time ago).
For me, what I had to do was:
Go to Window > Preferences > Rust
In the field "Language Server", replace the pre-populated entry with C:\Users\[Username]\.cargo\bin\rls.exe
I'm trying to use a custom font in a Tcl/Tk GUI, running on Windows.
I don't really want to install the font system-wide (as this would require admin privileges), so it seems that I need to somehow use the AddFontResourceEx function, to register the font (temporarily)
Now there are a few complications:
needs to be able to run with Tcl/Tk 8.5
must run (at least) on W7 to W10
pure Tcl/Tk solution (no binary extension; any solution must be self-contained with a Tcl/Tk interpreter and with whatever interpreters a pristine W32 installation comes with)
no admin privileges on the deployment machines
no user interaction
So I was thinking on using a VBS script that would do some magical incantations to call AddFontResourceEx. (Originally I though of using a Powershell script, only to discover that Powershell scripting seems to be disabled by default for security reasons)
I'm not much of a Windows person (less so a VBS person), so I wonder, whether it is even possible to register a font with VBS in the way I envision it.
If so, how?
Or are there easier way to register a font from within Tcl/Tk (or a shell).
You can try the extrafont package:
https://wiki.tcl.tk/48903
This package will load external fonts without requiring them to
be installed on the system.
I have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.
I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.
A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?
I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?
(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)
I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.
The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.
A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...
I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.
I have a problem with Firefox 4 Beta.
It seems that firefox somehow ignores all LSP providers installed. But it does use winsock.
What's the problem? Is it my LSP problem and I can fix it or not?
If your LSP has already worked with older version of Firefox and other browsers, it is likely nothing wrong with your code.
In Vista or above, there is a newly introduced concept called LSP categories.
Firefox 4 Beta installer calls WSCSetApplicationCategory() when Vista detected. It sets LSP category for firefox.exe as LSP_INSPECTOR, LSP_REDIRECTOR, LSP_PROXY,LSP_FIREWALL, LSP_INBOUND_MODIFY, LSP_OUTBOUND_MODIFY, LSP_CRYPTO_COMPRESS.
It means only LSPs that categorized themselves as one of the above are allowed to hook in firefox.exe process.
It only happens in Vista or later, your LSP should work fine on previous Windows. Once Vista detected, your LSP installer should call WSCSetProviderInfo() and classify your LSP to match firefox's permitted LSP categories.
For more details, have a read at: http://msdn.microsoft.com/en-us/library/bb513664(v=vs.85).aspx
I had the same problem and solved this. I installed my LSP as a BASE_PROTOCOL instead of LAYERED_PROTOCOL.
However, you have to be careful if you choose to write your own BASE_PROTOCOL. Your provider must work well with other LSP's.
All these years i have been successfully using EnumServicesStatus in combination with OpenScManager (with SC_MANAGER_ENUMERATE_SERVICE) to get a list of the services installed on a computer. This has been working well since NT 4 and up to Vista.
Now, for some reason, in Windows 7 I'm not getting the whole list of the installed services, but only a few of them. No errors, just a very incomplete list of services
Has anything changed in Windows 7? Do I need administrative powers now to enumerate services (I hope that's not the case)? Using Delphi 2010 but the same code was working file in D2007.
I don't think anything has changed here. It would cause huge incompatibilities with old software. But D2007 used the ansi version ENUM_SERVICE_STATUSA and I think D2010 calls the unicode version ENUM_SERVICE_STATUSW. Maybe you are doing some manipulation in the results that assume that the result is ANSI when you are getting Unicode? Just guessing.