Clipper, CCC

A következőt kellett megváltoztatni.

Az új javac-ben bizonyos class-ok a import java.util.*; ból átkerültek az import java.lang.*;-ba.

Tehát a régi import java.util.* a import java.lang.* is szükségeltetik.

A fordítást nem tudtam automatizálni az m.bat segítségével. Tehát nálam a következőt csináltam, az jterminál mappából kiindulva:

cd getutil

javac *.java

cd ..

javac -classpath . jterminal.java  ( Esetleg Note: jterminal.java uses unchecked or unsafe operations.
                                                                Note: Recompile with -Xlint:unchecked for details.)

Tisztelt Dr. Vernes Úr !

Sajnos a jeed készitése a következő hibát eredményezi:

             ....ccc3\usr\lib\mng\ccc3_sslsocket.lib(sslcon_funif.obj):sslcon_funif.cpp:(.text+0x1e6): undefined reference to `SSL_new'

Persze több hibasor is van, de mindegyik az SSl-el kapcsolatos hibaüzenet.

Az ccchome\ccc3\usr\bin\windows-ben van egy pár exe, mint a bt2ted.exe és stb.

A ccchome\ccc3\usr\lib\mng-ben is van egy ccc3_jeed.lib, meg egy ccc3_socket.lib és egy ccc3_sslsocket.lib is.

A socket-ben a demo programok is müködnek.

A jeed-ben a parfile.bld tartalma:

-lccc$(CCCVER)_jeed

-bccc$(CCCVER)_tds
-bccc$(CCCVER)_sql2_oracle
-bccc$(CCCVER)_sql2_postgres
-bccc$(CCCVER)_sql2_sqlite3
-bccc$(CCCVER)_sql2_mysql
-bccc$(CCCVER)_jt
-bccc$(CCCVER)_xmldom
-bccc$(CCCVER)_socket
-bccc$(CCCVER)_sslsocket
-bccc$(CCCVER)_btbtx

BUILD_EXE=$(CCCDIR)/usr/bin/$(CCCUNAME)

A kedves segítségét szivesen elfogadom.

Üdv.

beg

A ccc3\tools\sql2\test\basicdemo\exe-pg mappában szeretném a connect.exe progit kipróbálni.

A cccenv.bat file-ban van nálam egy új bejegyzés, ami a következő:

     set POSTGRES_CONNECT="host='192.168.1.66' dbname=testdb  Port=5432"

A hiba üzenet:

      Operation: _pg_connectdb  

Description: invalid connection option ""host"
    Subsystem: sql2.postgres

Persze van még egy clipper-ben szokás hosszú call_stack:

default error block evaluated
errorclass: sqlconnecterror
operation: _pq_connectdb
description: invalid connection opti

severity:          2
subcode:          1
subsystem: sql2.postgres
  called from deferror(216)
  called from _blk__2(0)
  called from _pq_connectdb(0)
  called from sql2.postgres.sqlconne
  called from sqlconnect(22)
  called from main(65)

Ami nekem fetünik, hogy a connect.exe nem függ semmi dll-től, például a libpq.dll-től.

Vagy már a connect.exe előállítása is hibás ?

Vagy a LD_LIBRARY_PATH-t is kell használni ?

Kérnék egy rövid példát a connection-string-re.

A következő oldalon kereslgéltem, ami nem vezetett eredményre:

   https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNSTRING

Sajnos csak a 32-bit-es fordítás müködik, mert a 64-bit-en hiányzik a libgmp-10.dll.

Mit kellene tenni, hogy a ccc3 a QT vagy a wxWidget-tel tudna müködni ?

Felraktam ide egy egyszerű, CCC-ben írt mitm (man in the middle) HTTP(S) proxyt. Mire jó?

* Szórakoztató.

* Tanulmányozni lehet vele a HTTP üzeneteket.

* Ki lehet belőle nézni egy csomó fontos dolgot: socket programozás, ssl programozás, autentikáció, kulcsgenerálás.

* Le lehet tiltani bizonyos site-okat. Ha például elegem van belőle, hogy a browser tízezredszer is konnektál a safebrowsing.googleapis.com-ra (a mobilinternetem terhére), akkor azt letilthatom.

Man in the middle: Azaz a böngésző és a szerver üzeneteit közvetíti egymásnak. Eközben a HTTP üzeneteket elemzi, hogy értse, mikor melyik és mekkora üzenetrész (header, body, chunk) következik, és hogy mikor mennyit kell olvasni a socketekből. Ehhez nyilvánvalóan dekódolni kell a titkosított üzeneteket, majd a továbbítás előtt újra titkosítani. A böngésző ellenőrzi (ellenőrizné) a szerverek tanúsítványát, a program ezek helyett röptében olyan tanúsítványt generál, amit a böngésző elfogad.

Látni lehet belőle, milyen egy CCC program hangulata. Hasonló, mint a pythoné, kivéve, hogy nem interpretált, hanem fordított/linkelt programról van szó. Az egész program kb. 700 sor (pythonban is kb. ennyi volna). Csak a legelemibb dolgokat tudja, de az olyan egyszerűbb oldalak, mint a hup.hu vagy a github.com már böngészhetőek rajta keresztül.

Úgy adódott, hogy elromlott az ubuntus telóm, úgyhogy vettem helyette egy Redmi Note 4-et. Ez most az első ilyen androidos izém, és ha már talákoztam az Androiddal lefordítottam rajta a CCC-t. Itt van néhány screenshot:

CCC fordítás Androidon:
https://photos.app.goo.gl/GDJWZh5iex23CafC3

Teszt browse:
https://photos.app.goo.gl/JTnYNkIld9FfLP7n1

A gitnav browseolja a CCC3 repóját:
https://photos.app.goo.gl/oCK9spIWGBvFo4kU2

X az persze nincsen, tehát nincs GTK sem, meg ilyesmi, a terminalok közül is csak a curses-es megy, de amúgy nem kellett különösebben hozzányúlni. Később aztán (miután teljesen lemerült) az ubuntus teló is előjött a tégla állapotból. Úgyhogy minden szempontból happy end.

CCC a github-on: https://github.com/mrev11/ccc3

Azzal kísérletezem, hogy a FindFirstFile API-val bejárjam az NTFS directory struktúrát. Vannak azonban olyan directoryk, amikben a FindFirstFile nem látja a fájlokat (GetLastError=5, access denied). Ugyanakor ilyen directorykban is tudok fájlt kreálni. Vagy át tudok nyúlni az olvashatatlan directory szintjén, és mélyebbre nyúlva a FindFirstFile működik az kérdéses directory subdirectoryjában.

Azt találtam a neten, hogy ez azért van így, hogy egyes alkalmazások, amik beégetett directorynevekkel dolgoznak, ilyen symlinkeken át továbbra is megtalálhassák a vackaikat, miközben a normál FindFirstFile API-val nyomuló programok számára körmentesnek (vagyis fának) látszik a struktúra.

Jó, ebben meg is állapodhatnék, de azt látom, hogy vannak olyan programok, amik mégis csak tudják listázni az ilyen directorykat is. Ott van pl mindjárt a dir parancs. Meg ott van a Far Manager. Ha véletlenül valaki tudja, hogy ezek hogy csinálják, ossza meg az infót.

Bocs a kezdő kérdésért, de az utolsó húsz évben csak 2-3 évente veszek a kezembe windowst, és teljesen új nekem ez a windowsos symlink téma.

A minap (pár hete) ellenőriztem a CCC installálását különféle rendszereken, azaz szakmányban végeztem C fordítást. A fordítás sebességében elég nagy eltérések adódtak, azért azt gondoltam, érdemes csinálni egy összehasonlító táblázatot. Íme:

system                                      real   user

Fedora 20       PAE     Qemu   gcc.4.8.2   0m56s  0m27s
Arch            64-bit  Qemu   gcc.4.8.2   1m50s  1m27s
FreeBSD 10.0    64-bit  Qemu   clang-3.3   2m17s  1m37s
CentOS 6.5      64-bit  Qemu   gcc-4.7.7   2m13s  1m41s
Debian Wheezy   64-bit  Qemu   gcc-4.7.2   2m16s  1m47s
Ubuntu Precise  64-bit  natív  gcc-4.6.3   2m37s  1m55s
Ubuntu Saucy    64-bit  Qemu   gcc-4.8.1   2m43s  2m01s
NetBSD 5.1      64-bit  Qemu   gcc-4.1.3   2m40s  2m09s
SUSE 13.1       32-bit  Qemu   gcc-4.8.1   2m45s  2m14s
NetBSD 6.1      64-bit  Qemu   gcc-4.5.3   2m56s  2m18s
FreeBSD 8.4     64-bit  Qemu   gcc-4.2.1  10m12s  2m21s

A tesztben összesen 660 darab object fájl készült, aminek kb. 2/3-a volt generált (Clipper->C++) kód. Ezekből 124 darab végrehajtható program linkelődött.

A táblázat jobb oldali oszlopa a user time-ot mutatja, méghozzá 3 egymás utáni futtatásból a legjobbat. A user time növekvő sorrendjében vannak rendezve a sorok.

Megjegyzések:

1) Érthetetlen és hihetetlen, hogy a Fedora 20 (-on futó gcc) hogy lehet ennyivel gyorsabb a többinél. Viszont akárhányszor megismétlem a mérést, mindig ez jön ki. (Nincs véletlenül kihagyva a teszt egyik része sem. A keletkezett objectek újak és működőképesek.)

2) Az Arch jó eredményét viszont nem tudom reprodukálni. Az utólagos ellenőrzés során az Arch visszacsúszott a középmezőnybe. Újrainstalláltam, akkor is. 64 bit helyett 32 bites installáció, akkor is. A táblázatban az elsőre mért jó idők vannak.

3) A FreeBSD 10.0 a clang miatt gyorsabb az átlagnál.

4) Az egész teszt az Ubuntu Precise gépemen futó qemu-kvm-ben folyt. A natív Precise-on kapott idő a középmezőnyben van.

5) Negatív rekord a FreeBSD 8.4 kiugróan rossz real futásideje. Már a teszt indulásakor végzett clean (bele volt mérve a tesztbe) érthetetlenül lassú.

Következtetés:

Nem vonnék le semmilyen következtetést a fentiekből. Az Arch példája azt mutatja, hogy általam nem ismert körülmények szerencsés együttállása (vagy együtt nem állása) gyökeresen megváltoztathatja az erdeményt. Például nagyon valószínűnek tartom, hogy más installációkon a Fedora sem körözné le ennyivel a mezőnyt.

Szerk: Kiegészítve a CentOS 6.5-tel. Semmi meglepő.

A GTK-t fordítása a SUSE-13.1-en egészen jól índul el, de egyszer csak hiba lép fel.

Valahogy ki tudom a híbát javítani, de sajnos csak probálkozva, úgy hogy valamilyen gtk csomagokat telepítek.

Ha lehetne szeretnék a hibára egy potos leírást adni.

Most egy kis kivonat a log-mkall-ból.

~/ccc3/gtk/codegen ~/ccc3/gtk
CCC Program Builder 1.3.03 Copyright (C) ComFirm Bt.
. dd
PRG2OBJ.BAT _gtkapi dd
Clipper/C++ Compiler 5.0.18 Copyright (C) ComFirm Bt.
Parsing complete.
----------------------------------------------------------------
PRG2OBJ.BAT codedir .
Clipper/C++ Compiler 5.0.18 Copyright (C) ComFirm Bt.
Parsing complete.
----------------------------------------------------------------
PRG2OBJ.BAT codegen_api .
Clipper/C++ Compiler 5.0.18 Copyright (C) ComFirm Bt.
Parsing complete.
----------------------------------------------------------------
PRG2OBJ.BAT codegen_reg .
Clipper/C++ Compiler 5.0.18 Copyright (C) ComFirm Bt.
Parsing complete.
----------------------------------------------------------------

.....
.....
.....
PRG2OBJ.BAT wdg_gladewindow .
Clipper/C++ Compiler 5.0.18 Copyright (C) ComFirm Bt.
Parsing complete.
----------------------------------------------------------------
LEM2OBJ.BAT gtksym_parser .
16 (sr=16/rr=0) parsing conflicts.
pathsearch /home/gyula/ccc3/usr/bin/linux/lempar.c
----------------------------------------------------------------
LEX2OBJ.BAT gtksym_lexer .
----------------------------------------------------------------
OBJ2LIB.BAT ccc3_glade
ar: creating objlin/ccc3_glade.lib
----------------------------------------------------------------
OBJ2SO.BAT libccc3_glade
----------------------------------------------------------------
LIB2EXE.BAT gui /home/gyula/ccc3/usr/bin/linux
----------------------------------------------------------------
/home/gyula/ccc3/usr/lib/lin/ccc3_gtk.lib(gtk_init.obj): In function `_nsp_gtk::_clp_init(int)':
gtk_init.cpp:(.text+0x28): undefined reference to `gtk_init'
/home/gyula/ccc3/usr/lib/lin/ccc3_gtk.lib(gtk_init.obj): In function `_nsp_gtk::_clp_main(int)':
gtk_init.cpp:(.text+0x71): undefined reference to `gtk_main'
/home/gyula/ccc3/usr/lib/lin/ccc3_gtk.lib(gtk_init.obj): In function `_nsp_gtk::_clp_main_quit(int)':
gtk_init.cpp:(.text+0xba): undefined reference to `gtk_main_quit'
/home/gyula/ccc3/usr/lib/lin/ccc3_gtk.lib(gtk_init.obj): In function `_nsp_gtk::_clp_main_depth(int)':
gtk_init.cpp:(.text+0x11f): undefined reference to `g_main_depth'
/home/gyula/ccc3/usr/lib/lin/ccc3_gtk.lib(gtk_init.obj): In function `_nsp_gtk::_clp_events_pending(int)':
gtk_init.cpp:(.text+0x16a): undefined reference to `gtk_events_pending'
.....
.....
/home/gyula/ccc3/usr/lib/lin/ccc3_gtk.lib(gtk_tree_view_column_api.obj): In function `_nsp_gtk::_nsp_tree_view_column::_clp_cell_is_visible(int)':
gtk_tree_view_column_api.cpp:(.text+0x46a6): undefined reference to `gtk_tree_view_column_get_type'
gtk_tree_view_column_api.cpp:(.text+0x46b2): undefined reference to `g_type_check_instance_cast'
gtk_tree_view_column_api.cpp:(.text+0x46ba): undefined reference to `gtk_tree_view_column_cell_is_visible'
collect2: error: ld returned 1 exit status

~/ccc3/gtk
Linux linux-sat8.site 3.11.6-4-desktop #1 SMP PREEMPT Wed Oct 30 18:04:56 UTC 2013 (e6d4a27) i686 i686 i386 GNU/Linux