Clipper, CCC

Windows FindFirstFile access denied

Fórumok

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.

Fordítás sebességteszt

Fórumok

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ő.

GTK a SUSE 13.1-en

Fórumok

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

setup problémák: linux suse 13.1

Fórumok

A ccc3 programokat viszonylag jól lehet fordítani a suse 13.1, 32-bit-es linuxon.

Sajnos problát okoz bizonyos programok futtatás, például az xmask.exe, amely a következő hibaüzenettel szál el.

connect_to_terminal failed error=111

Sajnos az X11-es font konfiguráció: xlsfonts és stb. nem müködik.

Talán a hiba ez miatt van.

A TERM és a DISPLAY változok elvileg jól vannak beállítva.

Arra tippelek, hogy font problémák vannak.

Az akábbiakat elvégeztem.

1) export CCCTERM_FONTSPEC=-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1

2) A console8x16.pcf.gz fájlt bemásoljuk /usr/share/fonts/X11/misc-be

Az xlsfonts már nem müködik.

Onkado

Fórumok

Sziasztok!
Google-eztem már ebben a téméban elég soxor ma. Mintha valakik már megoldották volna a fenti program Linux alatt futtatását. Valakinek tipp?

CCCExt honnan?

Fórumok

Sziasztok!

Korábban elérhető volt a CCCExt csomag, és CCC Mysql illesztésre is emlékszem, hogy láttam, de most sehol nem találom. Tudna segíteni valaki?

Köszi!
Konzol

dbf viewer

Fórumok

Sziasztok!
Tudtok valamilyen grafikus programot dbf fájlok nézegetésére, szerkesztésére Linux alatt? Még Windows alá is nehezen talátam, Linux alá meg semmit (most hagyjuk az OO.org-ot, valami kényelmesebbre vágyom).

Filemapping

Fórumok

Egy érdekes program: tutor/filemap/demo.prg


function main()
local fd:=fopen("demo.prg")
local map:=filemap.open(fd)

    fclose(fd) //már nem kell

    // map olyan, mint egy binary string
    // működnek rá a függvények és operátorok
    
    ? valtype(map)
    ? len(map)
    ? map::left(20)
    ? map::right(20)
    ? at(a"demo.prg",map)
    ? rat(a"demo.prg",map)
    ? map[1..32]
    ? map[1],map[2],map[3],map[4],map[5],map[6],map[7],map[8]
    ? a"demo.prg"$map
    ? a"function main()"<=map

// A közönséges bájtstringekkel szemben egy map óriási, akár
// sok GB is lehet (amekkora a címtér), ugyanis valójában nincs 
// benn a tényleges memóriában (csak a virtuális memóriában),
// és az operációs rendszer biztosítja, hogy a buffer megcímzett
// részei (amikor kell) bekerüljenek a tényleges fizikai memóriába.
//
// A map[offset..offset+1023] kifejezés egy avi fájl akármelyik
// részletét beolvassa. Tudni kell, hogy az ilyen "beolvasott" részek
// a fizikai memóriába kerülnek, ezért nem lehetnek akármilyen nagyok,
// a CCC védekezik a MAXBINLEN-nél nagyobb változók ellen.
// Pl. a map[..] vagy substr(map,1) kifejezések áttöltenék az egész 
// buffert a virtuális memóriából a fizikaiba, ami csak akkor sikerülhet,
// ha a buffer mérete < MAXBINLEN.

A program kiírásai:


X
      1288
function main()
loca
mérete < MAXBINLEN.
        34
       420
function main()
local fd:=fopen(
f u n c t i o n
.T.
.T.