I have an OPC server with built-in Lua 5.1 scripting service. I want to install socket library there.
I downloaded Lua socket 3.0rc1-2 from here, I guess it should work all right with Lua 5.1.
What is "install"? Should I just copy some folders and files to some folders or there's a procedure of installing with IDK adding system paths etc?
When I execute
server.message (package.path ..'\n'.. package.cpath)
on my server I get the next message:
C:\Program Files (x86)\InSAT\MasterOPC Universal Modbus Server\lua\?.lua;
C:\Program Files (x86)\InSAT\MasterOPC Universal Modbus Server\lua\?\init.lua;;
C:/ProgramData/InSAT/MasterOPC Universal Modbus Server/MODULES/?.lua.\?.dll;
C:\Program Files (x86)\InSAT\MasterOPC Universal Modbus Server\?.dll;
C:\Program Files (x86)\InSAT\MasterOPC Universal Modbus Server\loadall.dll;
C:/ProgramData/InSAT/MasterOPC Universal Modbus Server/CMODULES/?.dll
What files and folders from github socket package should put where?
Related
I'm writing a VSCode extension and need to copy some files to a remote machine (this is not a remote development scenario, but rather I've cross compiled and need to copy binaries and supporting files to the device).
My initial plan was to use SSH and SCP the files to the remote target. However, I see that the VSCode FS API allows working with local and remote filesystems. Is this possible and how would I use this API to copy the files I need?
VSCode just introduced a new local history feature built into the application. However I cannot find where the older version of files I worked on are stored on my computer when local history is turned on.
Does anyone know where the local history of older file versions are stored on Windows and Linux computers?
From https://github.com/microsoft/vscode/issues/26339#issuecomment-1070884696
That depends on how VSCode is run:
local desktop client with local workspace: local file system
local desktop client with remote file system backed workspace: remote file system
web client with remote file system backed workspace: remote file system
web client with non-file-system-backed workspace (e.g. vscode.dev): IndexedDB in the browser
When stored in the file system, there is a folder called History in
the folder User that is stored at the user-data-dir, which depends
on the OS you are on. That is the same location where e.g. also
backups go or UI state.
Following those directions, on Windows 11 local file system I found it at
C:\Users\Mark\AppData\Roaming\Code\User\History
for Stable and
C:\Users\Mark\AppData\Roaming\Code - Insiders\User\History
for Insiders.
I can't answer it for Linux. But see https://stackoverflow.com/a/70453798/836330 for more on user-data-dir and Linux. It says it is in ~/.config/Code on Linux but I can't personally verify that.
Linux
/home/USER/.config/VSCodium/User/History/
Windows
C:\Users\USER\AppData\Roaming\VSCodium\User\History
I am using VSCodium, so I imagine you will replace VSCodium with Visual Studio Code in the path.
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
I am using Microsoft enterprise library in one of my projects. I need to strong name one of the dlls which is Microsoft.Practices.EnterpriseLibrary.Common. But it is not working.
When I decompile using ILDASM, it generates 3 files.
IL file
.RESOURCES file
Common resource script file
How do I compile it with the key file. Which ILASM command should I use?
The dll's are distributed from the original install in a few different modes. One set of files is already signed, so you need to find that set and use the files from that set.
When you install the EntLib package, you get the compiled binaries (some are signed) AND you get the source code, which compiles the source-code and creates the dlls (not signed).
My guess is that you are using the non-signed (compiled from the source code on your local machine) files, instead of the signed ones.
I was troubleshooting an issue on a customer's workstation and found that, to my surprise, adodb.dll was nowhere to be found on the customer's workstation.
Typically, I see the file in C:\Program Files\Microsoft.NET\Primary Interop Assemblies folder.
Is this file distributed with the .NET framework or not?
Judging by MSDN, that file is written during a Visual Studio install.
Note Visual Studio.NET provides a Primary Interop Assembly (PIA) for ADO in the "Program Files\Microsoft.NET\Primary Interop Assemblies" directory in the file adodb.dll. If you have a copy of Visual Studio.NET installed, it is recommended that you use this file (adodb.dll) as opposed to importing your own using the Type Library Importer (tlbimp.exe).
I have this file on computers with VS installed, and don't have it on computers without VS installed. It looks like it should be pretty easy to generate your own with TlbImp.