using 64 bits Informix CSDK with gcc in AIX? - informix

I don't think this configuration is supported (maybe gcc isn't supported at all) because the esql script uses xlc options only.
But I want to know if other people are using this configuration gcc and informix 64 bits in AIX.

You can get ESQL/C (a part of ClientSDK or CSDK) to use GCC, but it isn't completely trivial. In principle, what I do is:
Make a copy of the original esql script.
Modify the original script to supply the GCC options on demand.
If you only want to use GCC, then this is sufficient. If you want to use both GCC and sometimes XLC (the native compiler), then it is harder.
I have a single script called esql in my private bin directory (which is always on my PATH ahead of things like $INFORMIXDIR/bin). It works out which version of ESQL/C I'm currently using, and runs the appropriate pre-patched version which is stored in a separate directory. And it automatically creates new versions of that script for me so if I work with CSDK 3.00.UC2 one minute and then CSDK 3.50.FC3 the next, it handles the switchover automatically.
Here's the patch applied to ESQL/C 3.50 on Solaris - you'll need to adapt it to AIX.
# #(#)$Id: patch.300.64,v 1.2 2007/09/02 21:46:55 jleffler Exp $
# GCC Patch for esql from CSDK 3.00.FC1
--- esql 2007-09-02 14:44:18.739067000 -0700
+++ esql.new 2007-09-02 14:44:26.812149000 -0700
## -23,10 +23,33 ##
INFDIR=${INFORMIXDIR=/usr/informix}
DB2CLIDIR=${INSTHOME=/usr/db2}
PREPCC=${INFDIR}/lib/esql/esqlc
-CC="${INFORMIXC=cc} -xarch=v9"
-CC_TH="${INFORMIXC=cc} -xarch=v9"
-CPP="${INFORMIXCPP=CC} -xarch=v9"
-CPP_TH="${INFORMIXCPP=CC} -xarch=v9"
+
+: ${INFORMIXC:=cc}
+: ${INFORMIXCPP:=CC}
+case "$INFORMIXC" in
+*perl*esqlcc*) # Building DBD::Informix
+ case "$ESQLCC" in
+ *gcc*|*g++)
+ CC_ARCHFLAGS="-m64"
+ ;;
+ *cc*|*CC*)
+ CC_ARCHFLAGS="-xarch=v9"
+ ;;
+ esac
+ ;;
+*gcc*|*g++*)
+ CC_ARCHFLAGS="-m64"
+ ;;
+# Beware - this normally needs to be last - because things like esqlcc and gcc match too!
+*cc*|*CC*)
+ CC_ARCHFLAGS="-xarch=v9"
+ ;;
+esac
+
+CC="$INFORMIXC $CC_ARCHFLAGS"
+CC_TH="$INFORMIXC $CC_ARCHFLAGS"
+CPP="$INFORMIXCPP $CC_ARCHFLAGS"
+CPP_TH="$INFORMIXCPP $CC_ARCHFLAGS"
STATICFLAGS=""
CP=${INFORMIXCP="$CC -E -C"} # cpp which runs before esqlc
## -51,9 +74,6 ##
then
CC="$CC $CC_AMD32"
CPP="$CPP $CC_AMD32"
-else
-CC=$CC
-CPP=$CPP
fi
: '
## -922,7 +942,7 ##
# Set the linker to CPP
# Set the source files to objects
#
- CC=$CPP
+ CC="$CPP"
A="$AO $CPPOPTS"
fi
fi
Lemme know if you want the controlling esql script that I use (see my profile). I have 9 32-bit scripts and 8 64-bit scripts, created by a set of 12 different patch files (all for Solaris, I'm afraid). The versions range from ESQL/C 5.20 (for OnLine 5.20) via ESQL/C 7.2x (long dead officially) through various versions of CSDK.

Related

Is there a guide on porting edk2 to a new ARM64 platform?

I am new to EDK2.
For porting ekd2 firmware to a new ARM64 platform, it would be good to first get a minimum edk2 port which can run UEFI Shell at least, improvements can be added gradually based on that.
It seems that the first step is rather steep, e.g., how to determine a minimal set of "items" in .dsc and .fdf file for a platform? In my case, I would like to build the .fd for my platform and treat it as BL33 of TF-A, effectively I would like to build an edk2 firmware to replace u-boot.
It seems that such a guide is hard to find on the web. I found a old version of edk2 which contains some instructions, but apparently they are obsolete (not exist in latest master branch, while can be found in UDK branches such as UDK2014), and I am not sure why those documents are removed from master branch.
Currently I can build .fd for FVP (edk2-platforms/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc), and it seems that the build output FVP_AARCH64_EFI.fd is supposed to be treated as BL33. Theoretically this could be a prototype for my new ARM64 platform, but to me it's too complex to start with: the firmware is about 2.5MiB in size (as compare to 500K of u-boot), so I guess it's far from a "minimum" version. but it's hard to figure out what features to be removed (and how).
I am wondering if there is a detailed guide on such topic...
After 1 month of trial and error, today I managed to bring my ARM64 platform into a UEFI Shell environment. I treat it as my 1st milestone on the EDK2 journey. Below I will try to summarize the steps I took so far, as a tentative answer to my question above. Guidance/corrections/comments are welcomed.
Get familiar with UEFI/PI spec and EDK2 implementation by reading books/specs/articles. Well, UEFI/PI specs are thousands of pages long...how to start? My main reading list is:
"Beyond Bios--Developing with the Unified Extensible Firmware Interface", 3rd ed, by Vincent Zimmer, et al. As the authors explained, the book is a kind of high level summary of the thousands-paged specs. And I find that the book is well organized for a new comer to get familiar with various UEFI related concepts. The main purpose of the 1st read (before playing with edk2 code base) is to get familiar with concepts and architectural ideas, not the details yet. Related sections need to be consulted later when reading EDK2 implementations.
EDK2 specs, including:
EDKII User Manual
EDKII Build Specification
EDKII DSC/FDF/DEC/INF File Specification
Various articles on the web...
Get a reference platform which can correctly boot a FD image built from latest EDK2 source, and play with the boot manager and Shell environment a bit. In my case, I chose RPi4B. For me, this is very important, as the reference platform serves as a handrail during the whole process, that whenever I encounter bugs or have doubts, I check the source/log of the reference platform. This solves most of the problems I encountered. Btw, always generating "build log" and "build report" for both reference platform and the target platform, as the two files contains very detailed information for comparison and check. Consult the EDK2 build spec on how to generate these two files during build.
I use the following script to build for RPi4B platform:
#!/bin/bash
# https://github.com/tianocore/edk2-platforms#how-to-build-linux-environment
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
rm -rf ./Build/RPi4
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
#sudo apt install acpica-tools # iasl
# pip install antlr4-python3-runtime # -Y EXECUTION_ORDER
echo "Building firmware for Pi4B..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/RaspberryPi/RPi4/RPi4.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j RPi4-build.log \
-y RPi4-build-report.txt \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
-Y EXECUTION_ORDER \
all
How to use the build result RPI_EFI.fd on RPi4B, consult the following:
edk2-platforms/Platform/RaspberryPi/RPi4/Readme.md
readme.md inside https://github.com/pftf/RPi4/releases/download/v1.17/RPi4_UEFI_Firmware_v1.32.zip. btw, I need to replace the original start4.elf and fixup4.dat with the ones in the zip file, otherwise, the boot of RPi4 will fail, complaining something like below:
RpiFirmwareGetClockRate: Get Clock Rate return: ClockRate=0 ClockId=C
ASSERT [ArasanMMCHost] /home/bruin/work/tianocore/edk2-platforms/Platform/RaspberryPi/
Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c(263): BaseFrequency != 0
It's worth to analysis the RPI_EFI.fd content to some extend, by using some UEFI utilities. I mainly use the GUI version UEFITool of sudo apt install uefitool uefitool-cli. Other tools are also available. The anotomy of RPI_EFI.fd is of help when reading EDK2 build specs for checking understanding of the concepts.
One special aspect of RPI_EFI.fd is that the 1st 128K is bl31.bin binary from ATF. I guess this is due to the special booting connfiguration methods for RPi. For my platform, I don't need such kind of packaging, I only need to build the UEFI image MY.fd, which is treated as BL33 image and packaged into fip.bin togehter with BL2 and BL31 images by ATF build script.
Another aspect to notice is the "reset vector" in the begining of the .fd file. This related to the entry point of UEFI image (and entry point of each EDK2 modules), as well as interpreting the BL instruction for AArch64. Basically, it can be summarized as below:
The first [Components] in RPI_EFI.fd is ArmPlatformPkg/PrePi/PeiUniCore.inf, which is of MODULE_TYPE = SEC.
What's this component: this is the first (and only) SEC (Security) module in RPi4. What the name PrePi and Pei implies?
... the PI spec is not tied to edk2 PEIMs, and I don't see where EDKII PEI modules are currently the only "acknowledged" silicon init environment. The edk2 tree itself seems to contain platforms that don't use the edk2 PEI module set at all, but (IIRC) jump from SEC to DXE. I believe "ArmPlatformPkg/PrePi" and "ArmVirtPkg/PrePi" are related to this.
--- https://listman.redhat.com/archives/edk2-devel-archive/2020-November/msg00021.html
Its entry point: all UEFI components have the same entry point (_ModuleEntryPoint).
By "component", it means either a UEFI driver and UEFI app, both are PE32 executables, usually with suffix .efi.
The .efis are converted from ELF executables (.dll) by GenFw tool: modifying the file headers.
To verify that "all components' entry point is _ModuleEntryPoint":
Check the .dll generating command line in build report (build -y <BUILD_REPORT_FILE>), we have two flags "aarch64-none-linux-gnu-gcc" -o xxx.dll -u _ModuleEntryPoint -Wl,-e,_ModuleEntryPoint ...:
-u: gcc --help -v|grep "undefined SYMBOL" gives -u SYMBOL --undefined SYMBOL: star with undefined reference to SYMBOL.
Wl,-e: ld --help|grep "entry" gives -e ADDRESS, --entry ADDRESS Set start address.
Check all .dll files that Entry point address == _ModuleEntryPoint: find . -type f -name "*.dll" -exec sh -c "readelf -a {} |grep -E 'Entry point address|_ModuleEntryPoint'" \;
Its entry point is the entry point of whole UEFI FD image (i.e., from bl33_base_addr jump to this _ModuleEntryPoint):
Topology of the UEFI Firmware File
A UEFI Firmware File (actually a UEFI Firmware Device - FD file) is a collection of UEFI binaries encapsulated into a single image. The format of this image is defined by the Platform Initialization Specification Volume 3. A Vector Table is located at the base of this file. A 'BL' branch instruction at the base of the firwmare (location of the Reset Entry into the Vector Table) will jump to the first 'SEC' module of the UEFI Firmware Image.
--- https://github.com/lzeng14/tianocore/wiki/ArmPkg-Debugging
To verify the statements above:
Disassember the reset vector (i.e., the 1st word) of generated .FD (we got offset=0x360):
$ xxd -l 4 -e TEST.fd <== dump 4 bytes in little endian
00000000: 140000d8 <== BL {PC}+(0xd8<<2); offset=0x360
Check the Entry point in .dll (we got offset=0x240):
$ aarch64-none-elf-objdump -t ArmPlatformPrePiUniCore.dll|grep _ModuleEntryPoint
0000000000000240 g F .text 0000000000000000 _ModuleEntryPoint
$ readelf -h ArmPlatformPrePiUniCore.dll|grep Entry
Entry point address: 0x240
Compare contents of two files at different offset (we got identicial content):
$ xxd -s 0x360 -l 64 TEST.fd <== skip 0x360 bytes, dump 64 bytes
00000360: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000370: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000380: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000390: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
$ xxd -s 0x240 -l 64 ArmPlatformPrePiUniCore.dll <== skip 0x240 bytes
00000240: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000250: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000260: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000270: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
Prepare an empty pkg, and make it build ok. The main purpuse is to do some exercise with EDK2 build system, and use the empty pkg as the start point for the new platform.
Make a copy of RaspberryPi.dec, change all gRaspberry to gMyPlatform.
Make a copy of RPi4.dsc and RPi4.fdf, and comment out all stuff in DSC and FDF file.
Replace all GUIDs in DSC/FDF/DEC files, generating new ones using online guid generator.
Note that PCD are declared in DEC files, and DEC files are refered by modules (INF files). As the empty package contains no module, no PCD definition will be available in FDF. So for a success build of the empty package, we need to comment out all PCD reference in FDF.
The NOOPT build command for MyPlatform is as below:
#!/bin/bash
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
echo "Building UEFI firmware for MyPlatform..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/MyCorp/MyPlatform/MyPlatform.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j MyPlatform-build.log \
-y MyPlatform-build-report.txt \
-Y EXECUTION_ORDER \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
all
popd
Add the 1st component ArmPlatformPrePiUniCore. This component is to prepare the HOBs for DXE phae. The main purpose is to get serial port working and memory config correct. Another purpose of this step is to familiar with steps for adding a component/module/lib. Below is a brief summary of the steps:
Uncomment the module's INF into both DSC ([Components] section), and FDF ([FV.FVMAIN_COMPACT]).
Rebuild the pkg, and resolve all Instance of library class [xxxLib] is not found errors reported, by updating [LibraryClasses] sections of DSC.
This step is a repeating process for dozens of times.
Some lib-class has multiple lib-instances, making sure choose the appropriate lib-instance (ref the build-report of RPi4).
if encounter ModuleEntryPoint.iiii:31: Error: immediate out of range: enable gArmTokenSpaceGuid.PcdFdBaseAddress and gArmTokenSpaceGuid.PcdFdSize in FDF.
if encounter undefined reference to _gPcd_BinaryPatch_PcdSerialClockRate: set PcdSerialClockRate in [PcdsPatchableInModule] section in DSC. FIXME: why? ref.
Check the PCDs listed in build log: inspect any abnormal PCD values, and supply correct values.
Customize platform-specific drivers or libraries.
SerialPortLib: locate the lib-class header file (MdePkg/Include/Library/SerialPortLib.h) by find edk2 -type f -name "*.dec" -exec grep -Hn SerialPortLib. The following functions are required:
SerialPortInitialize()
SerialPortWrite()
SerialPortRead()
SerialPortPoll()
SerialPortSetControl(): RETURN_UNSUPPORTED
SerialPortGetControl(): RETURN_UNSUPPORTED
SerialPortSetAttributes(): RETURN_UNSUPPORTED
ArmPlatformLib: interface header at Include/Library/ArmPlatformLib.h. The following functions are required:
ArmPlatformGetCorePosition(): return cpu idx in the cluster given the MPIDR value. this function is used in _ModuleEntryPoint for setting stack for secondary cores. Assuming one cluster for now.
ArmPlatformIsPrimaryCore()
ArmPlatformGetPrimaryCoreMpId()
ArmPlatformGetBootMode()
ArmPlatformPeiBootAction()
ArmPlatformInitialize()
ArmPlatformGetVirtualMemoryMap()
ArmPlatformGetPlatformPpiList()
etc...
Uncomment more modules in DSC/FDF, module by module...For driver/libs which are RPi platform specific, we can:
either search the edk2/edk2-platform for similiar driver or lib instances, or
copy the RPi4 implementation and comment out most of the content, make the pkg build success first, and then bug fixing.
Debugging: my current main debugging method is through adding "printf()", i.e., the edk2 macro DEBUG((DEBUG_INFO,)). One needs to set gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel to an appropriate value to see more debug info.

Fortify, how to start analysis through command

How we can generate FortiFy report using command ??? on linux.
In command, how we can include only some folders or files for analyzing and how we can give the location to store the report. etc.
Please help....
Thanks,
Karthik
1. Step#1 (clean cache)
you need to plan scan structure before starting:
scanid = 9999 (can be anything you like)
ProjectRoot = /local/proj/9999/
WorkingDirectory = /local/proj/9999/working
(this dir is huge, you need to "rm -rf ./working && mkdir ./working" before every scan, or byte code piles underneath this dir and consume your harddisk fast)
log = /local/proj/9999/working/sca.log
source='/local/proj/9999/source/src/**.*'
classpath='local/proj/9999/source/WEB-INF/lib/*.jar; /local/proj/9999/source/jars/**.*; /local/proj/9999/source/classes/**.*'
./sourceanalyzer -b 9999 -Dcom.fortify.sca.ProjectRoot=/local/proj/9999/ -Dcom.fortify.WorkingDirectory=/local/proj/9999/working -logfile /local/proj/working/9999/working/sca.log -clean
It is important to specify ProjectRoot, if not overwrite this system default, it will put under your /home/user.fortify
sca.log location is very important, if fortify does not find this file, it cannot find byte code to scan.
You can alter the ProjectRoot and Working Directory once for all if your are the only user: FORTIFY_HOME/Core/config/fortify_sca.properties).
In such case, your command line would be ./sourceanalyzer -b 9999 -clean
2. Step#2 (translate source code to byte code)
nohup ./sourceanalyzer -b 9999 -verbose -64 -Xmx8000M -Xss24M -XX:MaxPermSize=128M -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC -XX:+UseParallelGC -Dcom.fortify.sca.ProjectRoot=/local/proj/9999/ -Dcom.fortify.WorkingDirectory=/local/proj/9999/working -logfile /local/proj/9999/sca.log -source 1.5 -classpath '/local/proj/9999/source/WEB-INF/lib/*.jar:/local/proj/9999/source/jars/**/*.jar:/local/proj/9999/source/classes/**/*.class' -extdirs '/local/proj/9999/source/wars/*.war' '/local/proj/9999/source/src/**/*' &
always unix background job (&) in case your session to server is timeout, it will keep working.
cp : put all your known classpath here for fortify to resolve the functiodfn calls. If function not found, fortify will skip the source code translation, so this part will not be scanned later. You will get a poor scan quality but FPR looks good (low issue reported). It is important to have all dependency jars in place.
-extdir: put all directories/files you don't want to be scanned here.
the last section, files between ' ' are your source.
-64 is to use 64-bit java, if not specified, 32-bit will be used and the max heap should be <1.3 GB (-Xmx1200M is safe).
-XX: are the same meaning as in launch application server. only use these to control the class heap and garbage collection. This is to tweak performance.
-source is java version (1.5 to 1.8)
3. Step#3 (scan with rulepack, custom rules, filters, etc)
nohup ./sourceanalyzer -b 9999 -64 -Xmx8000M -Dcom.fortify.sca.ProjectRoot=/local/proj/9999 -Dcom.fortify.WorkingDirectory=/local/proj/9999/working -logfile /local/ssap/proj/9999/working/sca.log **-scan** -filter '/local/other/filter.txt' -rules '/local/other/custom/*.xml -f '/local/proj/9999.fpr' &
-filter: file name must be filter.txt, any ruleguid in this file will not be reported.
rules: this is the custom rule you wrote. the HP rulepack is in FORTIFY_HOME/Core/config/rules directory
-scan : keyword to tell fortify engine to scan existing scanid. You can skip step#2 and only do step#3 if you did notchange code, just want to play with different filter/custom rules
4. Step#4 Generate PDF from the FPR file (if required)
./ReportGenerator -format pdf -f '/local/proj/9999.pdf' -source '/local/proj/9999.fpr'

How to get CMake find_file to accept UNIX-style paths on MSYS2?

I'm using CMake 3.4.1, on Windows 10, with MSYS2 (everything up-to-date as of Dec. 25 2015).
When I use CMake's find_file command, it won't work unless the path is in Windows-style. This is a problem for me, because I'm trying to use findwxWidgets.cmake, which fails because of this.
For example:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
find_file(version_h version.h PATHS /mingw64/include/wx-3.0/wx)
message(STATUS "version_h: ${version_h}")
Running cmake spits out:
-- version_h: version_h-NOTFOUND
But it's clearly in there:
>>> file /mingw64/include/wx-3.0/wx/version.h
/mingw64/include/wx-3.0/wx/version.h: C source, ASCII text
I'm wondering if this is a bug, or if there's some obscure flag I have to set to get this to work. How do I get CMake's find_file to find files with UNIX-style paths?
MinGW-w64 cmake can't understand MSYS2 paths. You might propose a path transformation test program to the CMake developers, but that's fairly gross and I'd hope the would reject that. Instead these things must be solved case-by-case. wx-config, being a shell script, is providing an MSYS2 path.
This is a bug in the currently release MSYS2 wxWidgets packages that will be fixed in the next release. To work around it, find the line in /mingw64/bin/wx-config or /mingw32/bin/wx-config:
prefix=${input_option_prefix-${this_prefix:-/mingw64}}
(or /mingw32 of course) and add after it:
if [ "x${MSYSTEM}" = "xMINGW32" ] || [ "x${MSYSTEM}" = "xMINGW64" ]; then
prefix=$(cygpath -m ${prefix})
fi
Be careful to remove it at upgrade time though.

Lua change current/working dir, Linux (without LFS or any non-std modules)

I need to change current working dir in lua script for execute specific actions, but i have a trouble with this simple task.
I write test script test.lua :
os.execute("cd /usr")
os.execute("ls")
But lua test.lua output is:
test.lua
Current dir doesn't change. What's is wrong? And i can't use LFS or any non-std modules.
Thanks to all for explaining it situation. I choose another way : change work dir before run lua script, but i have a lot of troubles with paths which use in scripts and with scripts.
On Unix, os.execute() spawns a child process and its children. In
jpjacobs's answer, the first process would execute the shell.
The directory change operation only affects the child process, not the
process in which the Lua interpreter is executing your program.
It's simply not possible without external libraries. You can use stuff like
os.execute("cd /usr/ && ls")
The Lua standard library is intended to be both small and portable. Therefore, it is based on the capabilities of the C-standard library for all but a select few functions. It has no function to change directories; that's why libraries like LFS exist.
Have you considered that Lua may not be the appropriate language for your needs? If you're doing shell-style scripting work in an environment where you're not allowed to load non-standard modules, perhaps Python or Perl would be better for you. Both of them have extensive standard libraries with a host of features, all without the need to download non-standard modules.
If you want to do any real shell-style scripting in Lua, you need modules. It's that simple. So you should either use external modules or use a different language.
This is a bit of hack, but have you tried creating symbolic links to the folders you need in the current folder, so you don't have to change the current folder at all?
os.execute("ln -s /usr/foo") -- link called "foo" in current dir
os.execute("ln -s /usr/bar") -- link called "bar" in current dir
baz = require('foo.baz') -- loading file /usr/foo/baz.lua
Here is the program written using Zerobranie Lua 5.2:
local sP = "E:/Documents/Lua-Projs/SVN/ScriptsWireE2"
local a, b, c = os.execute("cd "..sP.."&& dir")
print(a,b,c)
And the outpuit:
Програма 'lua.exe' пусната в 'E:\Documents\Lua-Projs\ZeroBraineIDE\ZeroBraineProjects' (pid: 8832).
Volume in drive E is Data
Volume Serial Number is DE34-ED00
Directory of E:\Documents\Lua-Projs\SVN\ScriptsWireE2
08-03-2016 18:25 <DIR> .
08-03-2016 18:25 <DIR> ..
17-03-2016 18:15 <DIR> Bridges
07-03-2016 18:21 11 558 license
07-03-2016 18:21 87 readme.md
2 File(s) 11 645 bytes
3 Dir(s) 181 729 161 216 bytes free
true exit 0
Програмата завършена за 0.06 секунди (pid: 8832).

How to control cmd-window in win32 from Ada-code?

I've made a simple Lua-execution in Ada, it cooly run everything I need via Lua.Load_Buffer("os.execute('wxlua.exe wx.lua')") but I don't need win32 cmd.exe-window, which is default opens on program's start-up. Is there any way to control this event directly from Ada?
P.S. os.execute() sends commands directly to Windows, not via cmd.exe.
To help see what's going on, try creating a desktop shortcut that executes that command.
If double-clicking on it also brings up the win32 cmd.exe window, then that means they compiled wxlua.exe to be a windows console app. You can try reading their docs or poking around in their exe directory to see if there's a Win32 version instead. If that doesn't do it for you, your best remaining option I know of is to call Win32's CreateProcess with the CREATE_NO_WINDOW or DETACHED_PROCESS flag set instead of using os.execute.
If the shortcut doesn't bring up a console window, that means os.execute is doing it to you. In that case, you'll have to go directly to the CreateProcess solution mentioned above.
Gnat should come with the Win32 bindings you need to call CreateProcess. If you'd like a cleaner interface to that routine, I have some thicker bindings I created to some of the Win32 calls, including that one and some other calls associated with creating Win32 services. I released them to the Public Domain (or tried to...) They are available in the source distribution of my old SETI#Home Service, and I believe they are somewhere in the examples directory of AWS (at least it used to be before ACT took it over).
Standard Lua os.execute calls the standard C function system(). The C standard only requires that system() do something platform dependent, and specifically avoids saying what that might be. On Unix-like platforms, system() usually invokes the shell /bin/sh. On Windows it usually invokes cmd.exe.
Of course, its exact implementation could depend on exactly which toolchain you are using. You haven't said where you got your Lua (or for that matter, who's Ada compiler you have). One likely and recommended source is Lua for Windows, which is linked to the C runtime library from VC8, aka VS2005. Quoting from VS2005's documentation:
int system(const char *command);
.... The system function passes command to
the command interpreter, which
executes the string as an
operating-system command. system
refers to the COMSPEC and PATH
environment variables that locate the
command-interpreter file (the file
named CMD.EXE in Windows NT and
later). If command is NULL, the
function simply checks to see whether
the command interpreter exists.
Since os.execute calls system which invokes cmd.exe, you will get the console window. The way to avoid that is to not use os.execute.
If the program being executed is compiled for Windows Console Mode, then you will get a console window, regardless. However, wxlua.exe is almost certainly not compiled as a console application since it is intended to host GUI applications written in Lua based on the wxWidgets library.
Edit:
Naturally, if your lua.exe is built in a way that replaces either the implementation of os.execute or the standard library routine system() with a different implementation then you might see different results.
To demonstrate that standard Lua's os.execute() eventually invokes cmd.exe, try the following:
C:\Documents and Settings\Ross>lua -e "os.execute[[pause]]"
Press any key to continue . . .
C:\Documents and Settings\Ross>wlua -e "os.execute[[pause]]"
C:\Documents and Settings\Ross>
This invokes a simple Lua script from the standard Lua interpreter, first the usual one that is a console application, and second from the variation supplied with Lua for Windows who's only difference is that it is linked to be a Windows GUI application.
Both cause the "Press any key" message to appear. The first in the same console window where I invoked Lua, and the second in a separate console.
Before hitting a key, I used PsList from Sysinternals in a separate console to show the process tree, with the command pslist -t. I've excerpted out only the relevant bits below:
C:\Documents and Settings\Ross>pslist -t
pslist v1.29 - Sysinternals PsList
Copyright (C) 2000-2009 Mark Russinovich
Sysinternals
Process information for LAMPWORK:
Name Pid Pri Thd Hnd VM WS Priv
Idle 0 0 2 0 0 16 0
System 4 8 79 1208 1884 220 0
...
explorer 3592 8 17 1263 115968 33964 25816
...
cmd 4300 8 1 96 35032 4448 2260
PsList 4688 13 2 109 29556 2776 1248
cmd 5208 8 1 33 30340 2704 1984
lua 5592 8 1 17 8528 1564 400
cmd 5680 8 1 30 30144 2428 1956
Notice that the instance of CMD that invoked Lua has a CMD as a child.
Repeating the experiment with wlua -e "os.execute[[pause]]" and pslist -t again:
C:\Documents and Settings\Ross>pslist -t
....
Name Pid Pri Thd Hnd VM WS Priv
Idle 0 0 2 0 0 16 0
...
explorer 3592 8 16 1251 115712 33956 25752
...
cmd 4300 8 1 96 35032 4448 2260
PsList 4888 13 2 109 29556 2780 1248
procexp 4800 13 7 328 108492 33232 29464
cmd 5208 8 1 32 30340 2704 1984
wlua 3272 8 1 15 8536 1576 400
cmd 5104 8 1 30 30144 2440 1956
Again, wlua has a CMD as a child.
Using ProcessExplorer, also from Sysinternals, I can see the command line of the child CMD process. It is CMD.EXE /C pause. In effect, system() prepends CMD /C to its argument and passes the result to spawn() for execution in a child process.

Resources