SMB1 und Dateizugriff-Schweinkram

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Ich würde dennoch immer einen allgemein erprobten Weg gehen
Do you like green eggs and ham?
Sam-I-am
Benutzeravatar
nightcrawler
1000 working lines a day
1000 working lines a day
Beiträge: 650
Registriert: Di, 24. Apr 2012 16:33
Wohnort: 72184 Weitingen
Hat sich bedankt: 3 Mal
Danksagung erhalten: 96 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von nightcrawler »

brandelh hat geschrieben: Sa, 23. Jun 2018 10:15 ist die Datei exclusive geöffnet ?
Aus Dateisystem-Sicht schon ;) ADS im proprietary locking braucht keinen lock offset des Dateisystems.
--
Joachim
Joachim Dürr Softwareengineering
https://www.jd-engineering.de
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf »

Hallo,
gibt es eine Chance dass das Projekt im Echtbetrieb mal eingesetzt werden kann ? Ich könnte es gut brauchen wegen Verschlüsselung und Datenschutz. Natürlich auch gegen Entgelt. Finde die Idee sehr gut da ich eine einfache Client Server Variante SQL und ADS vorziehen würde.
Grüße
Rudolf
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Hallo Rudolf,

diese Frage ist ähnlich gelagert wie die Frage: "Kann man auf einem Flug von Walldürn nach Würzburg in 3.500 Fuss Höhe über mittlerem Meeresspiegel Winnetou und Old Shatterhand begegnen?"

Hier die Antwort auf diese Frage, sie stammt von letzter Woche.

Bild

Viele Grüße
Michael
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Tom »

Ist das ein Ja? 8)
Herzlich,
Tom
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf »

:D für mich ein eindeutiges JA
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Cheers Lads,

dass es geht, steht außer Frage. Als schwierigsten Teil sehe ich eine gute Performance. Ich habe mal ein wenig optimiert und die Aufrufpaare (Positionieren/Lesen) und (Positionieren/Schreiben) zusammengefasst. Das halbiert die Anzahl der Server-Requests. Das Ergebnis ist auf einem Rechner mit Loopback gar nicht schlecht.

Über's Netz auf einen echten Server merkt man, dass viel Optimierungspotential in der TCP/IP-Verbindung liegt. Da müssen mal Parameter studiert und justiert werden.

Mit reinem Xbase++ auf der Serverseite, könnte es bei großer Client-Zahl kitzelig werden, wäre meine Vermutung.

Ein richtig guter Server müsste in C++ geschrieben werden. Das, was ich testweise fabriziert habe, ist auch nicht unbedingt eine gute Herangehensweise. Ein Thread pro offener Datei. Eigentlich igitt.

C++ bringt jede Menge Vorteile:
- Pfeil-Schnell (Winnetou)
- 64Bit-Adresseraum
- Alle calls Unicode, keine ANSI-Umsetzungen nötig
- Nutzung der O/S I/O-Completion Ports macht Sinn, weil der Performancegewinn nicht durch langsamen Xbase-Code zunichte gemacht wird

Da das umzusetzende Problem ohne Optimierungen als beinahe trivial anzusehen ist, sollte der Sache nichts im Wege stehen, wenn man denn möchte.

Man könnte auch mal mit einem Xbase-Server anfangen und schauen, wie weit man kommt.

Ich habe noch das Problem, dass R&R dann nicht mehr an meine Daten rankäme. Also müsste ich eine DLL schreiben, die in den R&R-Prozess injiziert wird. Einmal geschrieben könnte man das Biest auch verwenden, um FoxPro oder CAVO-Anwender mit ins Boot zu kriegen.

Nutzer von L&L sind hier fein raus.

Bleibt als größtes Problem die Zeitfrage. Hat mal jemand über die Machbarkeit einer Zeitmaschine nachgedacht?

Aber von den Problemen abgesehen, könnte man aus dem Baby ein duftes Tool machen. Zeitaufwändige und netzwerkbelastende Aktionen wir z.B. REINDEX, PACK, ... könnte man den Server machen lassen. Und noch einiges mehr fällt mir ein, was man damit hinbekäme.

Viele Grüße
Michael
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

...

Den Server und den Client kann man hier runterladen. Die Xbase2.0 Runtime wird natürlich noch benötigt.

http://www.xcockpit.com/files/HamServerDemoZip.zip

Erst den Server (fmredirserver.exe) starten, dann den Client (fmredirector.exe).

Hier der ablaufende Client-Code ohne Qualitätsanspruch.

Code: Alles auswählen

FUNCTION Main

   FIELD car_id

   StartDebugThread(0,.T.,.T.,.T.,SW_SHOWNA,"FMRedir Client Messages")
   InstallCockpitGuiErrorHandler()

   * Try to connect to the server and install the redirecting file monitor class
   FMRedirect(SERVER_INADDR):Register()

   SET EXCLUSIVE ON

   USE ("\\HAM\CARS") ALIAS file1
   INDEX ON car_id TO ("\\HAM\CARS")

   Browse()

   * Disconnect from the server
   FMRedirect():Done()

RETURN NIL

FUNCTION Browse

   LOCAL appWindow := BrowseDemo():CreateEx(0,"Green Eggs - Client",(WS_OVERLAPPEDWINDOW|WS_CLIPCHILDREN))
   LOCAL msg := MSG():emptybuffer

   appWindow:Show(SW_SHOWNORMAL)
   appWindow:Update()

   DO WHILE GetMessage(@msg)
      TranslateMessage(@msg)
      DispatchMessage(@msg)
   ENDDO

RETURN NIL

FUNCTION AppSys
RETURN NIL

********************************************************************************
*        Browse Demo Window                                                    *
********************************************************************************

CLASS BrowseDemo FROM CrackAndDispatch,Window

EXPORTED:

   INLINE CLASS METHOD InitClass
     ::CrackAndDispatch:InitClass()
     ::Window:InitClass(0,,,0)
   RETURN self

   VAR browser
   VAR statusBar

   VAR cxClient,cyClient

   METHOD OnCreate
   METHOD OnSize
   METHOD OnSetFocus
   METHOD OnDestroy

ENDCLASS

********************************************************************************
*                Browse Demo Window Message Handlers                           *
********************************************************************************

METHOD BrowseDemo:OnCreate(createStruct)

LOCAL cd := ListViewBrowseCreationData():New()
cd:browseCursor := DbfCursor():New("file1")

::browser:= ListViewBrowse():CreateEx(WS_EX_CLIENTEDGE,"File-Browse",;
             (WS_CHILD|WS_VISIBLE|WS_CLIPCHILDREN),0,0,0,0,self,;
              ID_BROWSER,,,cd)

* Now a StatusBar would be nice to have
::statusBar := CreateStatusWindow( (WS_CHILD|WS_VISIBLE|WS_CLIPSIBLINGS|CCS_BOTTOM;
                                    |SBARS_SIZEGRIP),;
                                   "Ready",self,ID_STATUSBAR )

RETURN 0

METHOD BrowseDemo:OnSize(wParam,cxClient,cyClient)

   LOCAL temp,dwp,rect

   ::cxClient := cxClient
   ::cyClient := cyClient

   * get the statusbar rectangle
   ::statusBar:GetRect(@rect)

   * that's the statusbar height
   temp := rect:bottom - rect:top

   * Start repositioning
   dwp := BeginDeferWindowPos(2)

   * Now reposition the StatusBar and redraw it
   * ::statusBar:Move(0,::cyClient-temp,::cxClient,temp,.T.)
   DeferWindowPos(dwp,::statusBar,0,0,::cyClient-temp,::cxClient,temp,SWP_NOZORDER)

   * And finally the Splitter
   * ::splitter:Move(0,0,::cxClient,::cyClient-temp,.T.)
   DeferWindowPos(dwp,::browser,0,0,0,::cxClient,::cyClient-temp,SWP_NOZORDER)

   * Finsih repositioning
   EndDeferWindowPos(dwp)

RETURN 0

 :?: METHOD BrowseDemo:OnSetFocus
   IF ::browser # NIL
      ::browser:SetFocus()
   ENDIF
RETURN 0

METHOD BrowseDemo:OnDestroy
   PostQuitMessage(0)
RETURN 0

Alle Dateien, die mit "\\HAM" beginnen werden über den Server abgewickelt.

Wer mal sehen will, warum dies im Code steht,

"InstallCockpitGuiErrorHandler()"

der beende erst den Server und dann den Client, der ja dann voll auf die Nase fallen muss. Das kriegt er sogar recht grazil hin.

Viele Grüße
Michael
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf »

Hallo Michael,
hört sich vielversprechend an. Für ich ist derzeit die Geschwindigkeit bei vielen Usern kein Problem, sehr selten dass wirklich viele gleichzeitig exzessiv arbeiten. Es müsst nur für 1.9 auch verfügbar sein und dann problemlos transparent in eXpress++ einbindbar sein. Aber ich denke das sollte kein Problem sein, zumindest hoffe ich es.
Grüße
Rudolf
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Koverhage »

Rudolf,
1.9 macht doch irgendwie kein Sinn mehr. Warum stellst Du nicht um ?
Gruß
Klaus
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf »

Hallo Klaus,
vor allem weil ich momentan keinen Bedarf habe und es nur Arbeit, Kosten und Risiko sind. Die neuen Dinge benötige ich nicht ungedingt, nur SQL wäre interessant, geht aber nicht wegen der komplexen Dialoge mit indexsequentieller Suche die ich nicht alle Umstellen kann.
Grüße
Rudolf
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Hallo Rudolf

irgendwann kommt der Moment an dem du Umstellen musst. Jetzt könnest du das in "Ruhe" und geplant umsetzten. Anderfalls dann irgendwann in Zeitnot vorallem wenn dann deine Kunden Probleme haben.....

Als Entwickler sollte man doch aktuelle Tools einsetzten...

Zum Sicherheitsstandard gehört ja auch "Patch und Update Management"

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Koverhage »

Rudolf,
wie Carlo schreibt. Die Kosten hättest Du doch nur für Xbase++.
Express++ sind ja beide Versionen drin, was Du sonst noch einsetzt kann ich nicht sagen,
wobei digipen normalerweise auch kein Update erfordert.
Xb2.NET bist Du bestimmt eh schon auf dem aktuellen Stand.
Gruß
Klaus
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Jan »

Wenn ich sehe, was Alaska in den vergangenen zwei Jahren alles Patchen musste, nur um irgendwelche Schweinereien in den Halbjahresupdates von Windows 10 abzufangen, dann würde ich nachts nicht mehr schlafen können, wenn ich noch mit der nicht mehr weiterentwickelten 1.9 arbeiten würde. Die ja per se in keinster Weise für Windows 8 oder 10 freigegeben ist.

Ich seh natürlich das Problem der Umstellung. Ich selber hatte welche in der Betaphase von Xbase++ 2.0. Aber danach nie wieder. Ich weiß aber auch, das einer unserer Sprecher auf den Forentreffen massive Probleme hat, die er schon seit Monaten zusammen mit Alaska abarbeitet. Der geht aber auch extrem tief in die Innereien von Xbase++, API, Schnittstellen, etc. Sowas machen eher die Wenigsten hier.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Koverhage »

Jan,
Windows 8 dürfte wohl am wenigsten im Einsatz sein.
Bei unseren Kunden gibt es eigentlich nur WIN 7 und WIN 10, wobei WIN 10 immer mehr zunimmt.
Gruß
Klaus
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Jan »

Klaus,

ist mir schon klar, freiwillig macht doch mit Windows 8 keiner einen einzigen Tag länger als unbedingt notwendig, slebst mit der wesentlich besseren 8.1 nicht. Ich wollte damit nur ausdrücken, daß Alaska die 1.9 SL1 nur bis Windows 7 freigegeben hatte, die 1.9 noch nicht einmal dafür. Alles darüber geht offiziell nur mit Xbase++ 2.0.

Mir ist vollkommen klar, das die 1.9/1.9 SL1 auch immer noch unter Windows 10 läuft. Aber Alaska hat das nicht freigegeben. Und wir sehen halt auch, das MS immer wieder fiese Sachen einfallen, die in der Programmiersprache dann speziell berücksichtigt werden müssen. Die 1.9 SL1 wird schon seit Jahren nicht weiter entwickelt, und der Patch für die Auflösungsprobleme ist auch nur deshalb von Alaska für die 1.9 SL1 rausgegeben worden, weil eben noch zu viele Entwickler an der Umstellung auf 2.0 beschäftigt waren. Und auch nur Entwickler, die eine laufende Subscription auf die 2.0 haben, bekommen überhaupt diesen Patch.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 133
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 18 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von mikehoffmann »

Bad News,
ich habe ein paar Vergleichsläufe meines Servers gegen normales Sharing gemacht. Das Ergbnis lässt mich den Hut vor den Microsofties ziehen. Die normale Sharerei ist um den Faktor 100-400 schneller, als die Weiterleitung der API-Zugriffe. Selbst wenn man da noch optimiert, wird man so nicht an die Leistung von SMBx kommen. Das liegt auch nicht am langsamen Netzwerktransfer sondern an der schieren Datenmenge und der Anzahl der Zugriffe, die über's Netz rumpeln. Um die CARS.DBF (130k) über die CARS.NTX (26k) einmal durchzuskippen, werden 2,6MB an Daten über's Netz geschoben. Bei SMBx passiert hier fast gar nix. Da wird also gecached wie verrückt und wohl Invalidierungsmeldungen vom Server zum Client geschickt, dass dieser dann beim nächsten mal nicht aus seinem lokalen Cache liest. Hätte ich mir so krass nicht vorgestellt. Sehr, sehr schade.
Interessanterweise ist dieser Unterschied in einem Browse fast nicht zu merken.
Viele Grüße
Michael
Zuletzt geändert von mikehoffmann am Fr, 13. Jul 2018 12:16, insgesamt 2-mal geändert.
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf »

Hallo,
ok, ich nehme es zur Kenntnis dass eines Tages große Probleme auf mich zukommen und dass ich als Entwickler verantwortungslos handle. Aber damit bitte Diskussion über Update beenden, ich habe meine Gründe für mein Handeln. Für die Tips bin jedoch dankbar, darüber diskutieren ist immer von Vorteil, und irgendwann steige ich sowieso um. Mich interessiert hier nur die Client/Server Lösung von Michael momentan für die 1.9er Version.
Grüße
Rudolf
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Jan »

Rudolf,

da hast Du mich falsch verstanden! Ich wollte lediglich ausdrücken, das man jetzt schon in Probleme läuft, wenn man mit der 1.9 arbeitet. Und diese Probleme immer mehr werden im Laufe der Zeit, weil Microsoft da immer mehr alte Zöpfe abschneiden wird. Mir ist bewußt, das aus welchem Grund auch immer noch viele Entwickler mit der 1.9 arbeiten. Da geht es nicht nur um Ärgern über die Subscription-Politik von Alaska oder um Geldmangel. Es gibt auch durchaus reale und handfeste Gründe der verschiedensten Art dafür, die absolut nachvollziehbar sind.

Das ändert aber eben halt nichts daran, das man mit der alten Version immer mehr eine Gratwanderung macht.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Jan,

du hast vergessen:
Wenn man sich an der 1.9 festhält und sich selbst nicht weiterbildet lernt man auch die neuen Möglichkeiten gar nicht kennenlernt. z.B DataObject usw. usw. und sammelt auch keine Erfahrungen. Dies wird sich einmal rächen. Keine Weiterbildung = Stillstand = Man wird zur Geschichte

Auch die eigene Qualität leidet da man kein "Patch und Update Management" hat.

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Rudolf
Programmier-Gott
Programmier-Gott
Beiträge: 1418
Registriert: Mo, 02. Jan 2006 23:03
Wohnort: Salzburg/Österreich
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Rudolf »

Hallo Carlo,
glaube nicht dass ich deshalb zur "Geschichte" werde, da nimmst Du ein paar neue Dinge in xBase++ ein wenig zu wichtig denke ich ;-) Abgesehen davon sind mir derzeit Zusätze in B4X auf Tablets und Smartphones sowie Microcontroller Programmierung wichtiger als Dataobjects oder ähnliches.
Jan: welche Problem derzeit ? Mich hat bis jetzt noch nichts betroffen wie schon so oft geschrieben, außer dem Debugger, aber daran gewöhnt man sich auch, eXpress++ hat ein paar nette Möglichkeiten dazu.
Grüeß
Rudolf
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Tom »

:lol:

Ausgerechnet Rudolf indirekt diesen "Vorwurf" zu machen, das ist schon originell. :wink:
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Hallo Tom

es waren in keiner Art und Weise Vorwürfe! Nicht im entferntesten.

Sobald du einem "Patch und Update Management" unterliegst oder angeben musst wie du selbst mit Updates umgehst ist dass aus eigener Erfahrung genau die Beurteilung die du bei Verwendung Jahre alten Tools die nicht mal für's Zielsystem freigegeben sind erhältst!

Da kannst du wohl lachen, das sind leider Tatsachen.

Gruss Carlo
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von Tom »

Hallo, Carlo.

Das mag ja sein. Aber, mal unter uns: Selbst Xbase++ 2.0 ist in der aktuellsten Version ziemlich weit von allem entfernt, was man als den technologischen Stand der Dinge bezeichnen könnte. Das ist kein Urteil und kein Argument gegen Xbase++, weil erstens gerade die vertikalen Märkte eher konservativ sind und man zweitens ja alles irgendwie hinbekommt, was man hinzubekommen hat, aber wenn man argumentiert, dass die 1.9 (von 2006) veraltet wäre und man Gefahr läuft, selbst zur Geschichte zu werden, wenn man sie nutzt, während die nach wie vor unfertige 2.0, die seit 2012 (!) existiert und diese Versionsnummer trägt, da irgendwie der sinnvolle Schritt wäre, dann mogelt man sich ein wenig in die eigene Tasche. Weil man längst auf ganz anderen Schienen unterwegs sein müsste, um technisch topaktuell zu sein. Oder wenigstens halbwegs aktuell. Aber diese Diskussion müssen wir nicht wirklich schon wieder führen. :wink:

Und ausgerechnet Rudolf ist jemand, der sich intensiv umschaut und mit diversen Technologien arbeitet. Wenn er im Kern noch bei der 1.9SL1 ist, die sich soooooo sehr auch nicht von der 2.0 unterscheidet, dann wird er dafür gute Gründe haben - Gründe, die möglicherweise sogar besser als das Argument sind, das Du vorgetragen hast. Ich mache es übrigens ganz ähnlich. Wir fahren immer noch zweigleisig. Viergleisig, um genau zu sein, weil wir parallel mit anderen Technologien arbeiten.
Herzlich,
Tom
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: SMB1 und Dateizugriff-Schweinkram

Beitrag von ramses »

Hallo Tom

es ist genau so wie du schreibst.

Nur: Einem nennen wir Ihn "Prüfer" kannst du nicht mehr plausibel erklähren wieso deine verwendeten Tools aus 2006 stammen. Den Interessiert die Xbase Geschichte gar nicht sondern nur ob du aktuelle und aktuell gepatchte Werkzeuge verwendest.

Mit Werkzeugen aus 2006 bist du für den "Prüfer" wie ich Ihn hier nenne einfach nicht mehr auf der technischen Höhe sondern "Rückständig"

Hast du gedacht ich sei mit der gebotener Leistung und Umfang von XBase 2.00.? zufrieden? Nein sicher nicht. Aber mit Xbase 2.00 habe ich wenigstens die Vorgaben "aktuelle gepatchte Tools" zu verwenden erfüllt.
Andernfalls kann ich mir gleich einen neuen Job suchen.


Gruss Carlo
Valar Morghulis

Gruss Carlo
Antworten