Windows 10 Creators Update 1703

[Leon]

keine 4 GB RAM zur Verfügung, alleine das macht einen Entwicklungsrechner schon unnötig langsam. Nur beim Entwickeln sind bei mir schon ein paar Programme ständig offen, die mit Windows zusammen unter Win10 64bit die 4 GB - Grenze sprengen:

• 1-3x Workbench
• Xbase++-Applikation, an der ich gerade arbeite
• Word (Doku)
• Notepad++ für XML, CSV etc.
• TeamViewer
• Outlook
• PostgreSQL-Server local und remote
• IE

Bei einem 32-Bit Windows wird da schon extrem geswapped...

Das kann man auch noch anders machen:

Apple iMac 27", i7, 32GB RAM, ständig geöffnet: Apple Mail, Safari mit mind. 10 Tabs, Word, Excel, Photoshop, Teamviewer, Kalender, Parallels Desktop mit Windows 10 Pro 32Bit mit der Alaska Entwicklungsumgebung. Da läuft nichts langsam

[ramses]

Hallo Georg

der PC kam mit aktivertem Win7 -64 Bit vom Hersteller, das herunterladen und installieren geht über die Webseite, nur das aktivieren ging nicht. (Es musste Win7 32 Bit sein, sonst läuft die Software wirklich nicht) Es musste ein neuer 32-Bit Key her. Wieso auch immer. Danach lief es.

Gruss Carlo

[ramses]

Wenn das auch so sein sollte, das die v1.90SL1 betroffen ist, wird es sicher sehr ungemütlich werden
für manche Entwickler bzw. Anwender.

Und wenn schon, heute noch die 1.9 zu verwenden, mit dem Argument in der 2.0 könnten Fehler sein ...... ist für mich schlicht nicht nachvollziehbar.
Eine der wichtigsten Regeln in der IT ist doch "Haltet eure Systeme aktuell" Updates, Updates, Updates.

Heute noch Programme mit der 1.9 zu übersetzten ist in meinen Augen schon beinahe XXXXXXXX, auf jedenfall alles andere als Professionell.
Auf solche Ideen, 10 Jahre alte Tools zu verwenden kommen nicht mal die "ach so billigen" Inder.....
und bei jedem Kunde der wirklich realisiert dass deine Tools 10 Jahre alt sind, ohne Updates wirst du vermutlich nicht mehr allzugut dastehen.....
besonders da jeder IT-ler seine Zeit ja auch verrechnet muss.


Gruss Carlo

[Hans Zethofer]

Gibt es Sicherheitslücken bei der v1.9 Version die unbedint gestopft werden müssen mit einer v2.0 ?

Ich kenne keine, lass mich aber gerne belehren!

Der Kunde will ein stabiles, für Ihn optimales "Werkzeug" um seine Anforderungen zu erfüllen.
Daher ist es Ihm (jedenfalls bei meinen Kunden) egal was für eine Entwickler-/Softwareversion ihm das anbietet oder dahintersteht.

Sicher kann man dem Kunden ein "Sicherheitspaket (Werkzueug ist ja schon über 10 Jahre alt - bleib aktuell - Bezahle dafür)" schön verkaufen
aber für Ihn wird sich nichts verändern (von der Funktionalität) genauso wie von der Oberfläche also werden hier wieder Fragen aufgeworfen -
war das überhaupt notwendig upzudaten? Es hat sich für mich nichts verändert und wenn dann auch noch Probleme dazukommen die vorher
nicht da waren - dann ist das ein Problem oder wird zu einem PROBLEM.
Da zählen Ausreden - warum das jetzt so ist - realtiv wenig wenn der tägliche JOB nicht mehr erledigt werden kann.

Deine Argumente in Ehren, deine Ansichten sicher überlegenswert - aber nicht alles was Neu ist ist besser und stabiler.

Ich weiß, daß meine Versionen stabil ihren Dienst schon seit der Entwicklung verrichten und ich brauche keine zusätzlichen Aufgaben
- wie Fehler suchen - in einer neueren Entwicklerversion nach Updates.

Wenn ich Funktionalitäten aus einer NEUEREN Entwicklungsumgebung benötige bin ich der letzte der an dem altem hängt und das um jeden
Preis weiter am Leben hält. Aber in meinem Fall schlicht nicht notwendig.

Soweit ich weiß sind hier noch mehrere v1.9 "sehr erfolgreich" im Einsatz - also jedem das seine - dieses Werkzeug funktioniert einwandfrei
für meine Bedürfnisse und die meiner Kunden, also hier von

Heute noch Programme mit der 1.9 zu übersetzten ist in meinen Augen schon beinahe XXXXXXXX, auf jedenfall alles andere als Professionell.
Auf solche Ideen, 10 Jahre alte Tools zu verwenden kommen nicht mal die "ach so billigen" Inder.....

Unprofessionell zu sprechen ist meineserachtens, sehr dreist.

Ich könnte dir genauso gut vorwerfen, das - obwohl du weißt das die v2.0 manche Problemchen hat - lieferst du diese an deine Kunden
aus und gehst bewusst vorausschauend einem Problem entgegen. Nach dem Motto "Bananenstrategie - Produkt reift beim Kunden"
(das ist für mich fahrlässig).

Wenn du aber auf das "verrechnen deiner Zeit" Wert legst (mit Problemsuche), dann ist das die richtige Vorgehensweise.

Ich setze auf zufriedene Kunden und stabile Versionen! (auch wenn das Werkzeug nicht der "letzte Schrei" ist)

Nichts für Ungut, aber für "deinen Kommentar/Kritik bezüglich meiner Arbeitsweise" musste ich schon etwas weiter ausholen
und kann das so nicht einfach ihm Raum stehen lassen (unkommentiert).

Das wäre unprofessionell. (Ich denke manche meiner Entwickler-Kollegen denkt hier genauso)

[georg]

es gibt 32bit und 64bit UEFI und auf letzten kann man kein 32bit OS() > Windows 7 installieren

Hallo, Jimmy -


doch, es geht. Man muss nur das ... secure boot (?) abschalten. Ich habe auch Linux unter UEFI installiert.

Und das Ausgangsproblem waren die Kosten für eine 32bit Version, nicht die Installation (die ja durchgeführt werden konnte).

[Leon]

Das wäre unprofessionell. (Ich denke manche meiner Entwickler-Kollegen denkt hier genauso)

+1

[ramses]

Hallo Hans

ich gebe dir sicher theoretisch teilweise recht.

Jedoch ist die Verwendung überaltereter Tools nicht richtig.

Unprofessionell zu sprechen ist meineserachtens, sehr dreist.

Nein, genau so wirst du beurteilt wenn "Sicherheitsaudits" durchgeführt werden.
Wenn du dabei angeben musst dass du noch mit einer alten Major-Version arbeitest und es seitdem mehrere Major und Minor Updates gab kommst du nicht gut Weg.

Nimm nur mal den aktuellen Titel des Beitrags. Wieso das Problem bei den einen Auftritt und bei anderen nicht weiss ich nicht. Die Ursache wird jetzt von Alaska gefixt.
Angenommen deine Kunden/Programme trifft es in 4 Wochen (nach dem Fix) auch noch.

Würdest du mit der aktuellen Version arbeiten, hättest du keine Sorgen .......
andernfalls ...... kannst du ja deinen Kunden sagen "Hätte ich ein wenig in meine Werkzeuge investiert hätten wir die Probleme gar nicht......"

Wenn es wirklich krass wird und Probleme mit der Software auftreten hast du nur bei Verwendung aktueller Tools eine Chance halbwegs unbeschadet davon zu kommen.
Ich habe da so meine Erfahrungen gemacht.

Der Einsatz der 1.9XX ist für mich ein NO GO ich finde das Verantwortungslos. Meine Meinung.


Gruss Carlo

[Leon]

Nein, genau so wirst du beurteilt wenn "Sicherheitsaudits" durchgeführt werden.
Wenn du dabei angeben musst dass du noch mit einer alten Major-Version arbeitest und es seitdem mehrere Major und Minor Updates gab kommst du nicht gut Weg.

Ich habe einige Kunden mit ISO 9001 Zertifizierung, da werden in regelmäßigen Abständen Sicherheitsaudits durchgeführt. Bei keinem dieser Audits wurde die Verwendung von Xbase++ 1.9.355 je bemängelt. Und zwar deshalb, weil das wirklich nichts mit der IT-Sicherheit des Unternehmens oder der Daten zu tun hat.

Der Einsatz der 1.9XX ist für mich ein NO GO ich finde das Verantwortungslos. Meine Meinung.

Deine Meinung sei Dir unbenommen. Wenn ich mir allerdings Deinen dokumentierten Ärger über die V2.0 hier ansehe, bin ich froh, meine Zeit für andere Dinge als das Ausbessern von Fehlern nutzen zu können. OK, V1.9.355 hat auch Bugs, aber die kennt man und da hat man sich mit eigenen Workarounds damit arrangiert. Aber da gibt es keine unangenehmen Überraschungen mehr.

[AUGE_OHR]

doch, es geht. Man muss nur das ... secure boot (?) abschalten. Ich habe auch Linux unter UEFI installiert.

üblicherweise gibt es nur noch UEFI 64bit wobei die meisten kein "Compatibility Support Module" (CSM) mehr haben. wenn nun schon Windows 64bit installiert ist dann auch GPT Partitionen mit TPM und die S/N steckt im UEFI.

Und das Ausgangsproblem waren die Kosten für eine 32bit Version, nicht die Installation (die ja durchgeführt werden konnte).

auf einer solchen HDD/SDD läst sich nun kein 32bit Windows mehr installieren ... erst wenn man die komplett "platt" macht.

... unabhängig davon kommt das 32bit Treiber Problem.

[AUGE_OHR]

keine 4 GB RAM zur Verfügung, alleine das macht einen Entwicklungsrechner schon unnötig langsam.

und du meinst das der PC was über die Geschwindigkeit beim (Fehler freien) programmieren aussagt ?

[AUGE_OHR]

wie Hans schon sagte gibt es keine "Sicherheits-Updates" für Xbase++ also warum updaten ?
wenn man ein geschlossenes Intranet hat benötigt man auch kein Windows 10 und hat dann auch nicht das 4K Problem.

nun tritt das Problem bislang selten auf ... wer hat (jetzt) schon ein 4K Bildschirm.
viele Kunden arbeiten (noch) mit Windows 7 und wollen gar nicht upgraden oder einen 4K Touch Bildschirm blabla.

---

was nun das 4K Problem angeht ist es die Frage "was" Alaska bei den beiden DLL gemacht hat.
in der XPPDUI.DLL ist ja nun auch IsThemeActive() enthalten was in der v1.9x in der XPPSYS.DLL ist.

sollte IsThemeActive() das Problem sein so könnte man es in der v1.9x selbst "fixen" ( \SOURCE\SYS\xbparts.prg )

[Werner_Bayern]

keine 4 GB RAM zur Verfügung, alleine das macht einen Entwicklungsrechner schon unnötig langsam.

und du meinst das der PC was über die Geschwindigkeit beim (Fehler freien) programmieren aussagt ?

Ja!

[Werner_Bayern]

Gibt es Sicherheitslücken bei der v1.9 Version die unbedint gestopft werden müssen mit einer v2.0 ?

Servus Hans,

https, SSL.

Lt. Doku - kann ich nicht überprüfen - 378 geschlossene PDRs seit 1.90.355.

Ich will Dich nicht bekehren, jeder hat seine eigenen Gründe. Die 2.0 ist auch nicht perfekt, es gibt genügend offene PDRs und immer noch nicht unterstützte must have Features (z. B. S-FTP).

[Hans Zethofer]

Ich sag nur - externe Tools, Stabil und decken solche Anforderungen bisher problemlos ab.

Wenn solche Module und deren Funktionalität dann mal auch direkt in Xbase++ abgedeckt werden, wird es
mich/uns sicher freuen, aber das ist kein derzeitiges Umsteigkriterium für mich.

[ramses]

Hallo Leon

Wenn ich mir allerdings Deinen dokumentierten Ärger über die V2.0 hier ansehe, bin ich froh, meine Zeit für andere Dinge als das Ausbessern von Fehlern nutzen zu können.

Damit hast du recht. Ich hatte richtig üble Probleme, mit einem Bug eines Updates. Glücklicherweise habe ich aktuelle Tools verwendet. So wurde das als "Tücken der Technik" abgebucht und nicht über Haftungsfragen gesprochen, da ich Richtlinenkonform gehandelt habe. Auch wurde neu entschieden weiter auf aktuelle Tools zu setzten. Und wir haben ein Testprozess erarbeitet.

ISO9001 sagt bezüglich Sicherheit eigentlich nichts aus, sondern nur dass Arbeitsschritte festegelegt und immer gleich gehandhabt werden.

Wenn wäre dies ISO27001 sowie zusäzliche Sicherheits Richtlinien.

Gruss Carlo

[Tom]

Die 1.9 SL1 ist bislang nicht abgekündigt; es gibt sogar aktuelle Videovorträge dazu, wie man sie z.B. zusammen mit der 2.0 in einer Entwicklersituation verwenden kann, und das hat seine Gründe. Aus meiner Sicht ist die 2.0 immer noch beta, wenn auch late beta, um mal was Nettes zu sagen. Das Featureset rund um die PG-ISAM-Emulation (früher "Arctica") ist gerade erst halbwegs fertig geworden (DbPosition usw.). Ich würde unsere Software derzeit noch nicht in einer 2.0er-Version ausliefern, obwohl wir natürlich parallel mit der 2.0 arbeiten und die Features, die es darin gibt, testen und migrieren. Aber Kunden bekommen das noch nicht. Wenn ich beobachte, wie sich die Workbench derzeit noch verhält, möchte ich dieses Experiment - übertragen auf die Entwicklungsumgebung selbst - unserem Support nicht zumuten. Vielleicht gegen Ende des Jahres.
Und wenn die Probleme in der aktuellen Windows-Situation auf grundsätzliche Fehler in Xbase++ zurückzuführen sind, wovon auszugehen ist, dann erwarte ich auch einen Fix für die 1.9 SL1.

[Hans Zethofer]

Bin ganz bei dir - würde ich sofort unterschreiben

[Leon]

ISO9001 sagt bezüglich Sicherheit eigentlich nichts aus, sondern nur dass Arbeitsschritte festegelegt und immer gleich gehandhabt werden.

Wenn wäre dies ISO27001 sowie zusäzliche Sicherheits Richtlinien.

Hallo Carlo,

da ich keine Kunden habe, die mir vorschreiben, in welcher Entwicklungsumgebung und mit welchen Tools die Programme geschrieben werden, die sie wünschen und benötigen, stehe ich nicht wie Du vor diesem Problem. Meine Kunden wollen funktonierende Lösungen und keine Experimente mit Betaversionen.

[Werner_Bayern]

Servus Tom,

wir haben seit Mai 2014 auf die 2.0 umgestellt und unsere Kunden ab Oktober 2014 - alle Anwendungen. Aktuell keine Probleme damit.
Hauptgrund war ISAM-SQL, das leider bis dato nicht produktiv eingesetzt werden kann, also weiterhin dbf und alles neue mit eigener Klasse über PostgreSQL.
Alles funktioniert soweit ganz gut, auch immer noch das aktuelle alte FRAX mit dem Patch von Alaska für die 2.0.

M. M. n. spricht nichts gegen einen Wechsel auf die 2.0, im Gegenteil.

[Leon]

M. M. n. spricht nichts gegen einen Wechsel auf die 2.0, im Gegenteil.

Es spricht aber auch nichts für einen Wechsel, es sei denn, man hat Angst vor irgendwelchen Sicherheitsaudits oder möchte schlicht und ergreifend nicht als verantwortungslos gelten...

[Werner_Bayern]

Für einen Wechsel spricht:

- Workbench inkl. Debugger (!!!)
- SSL
- HTTPS
- LayoutManager
- Touch
- Dataobjects
- PostgreSQL (ISAM noch nicht, aber alles andere)
- viele zusätzliche Features und Erweiterungen in Klassen, Funktionen und Befehlen
- Windows10-Unterstützung
- HTML in XbParts
- neue Datentypen
- Support durch Alaska (mit und ohne extra Bezahlung, je nach Umfang und Problematik)
- schnelle Updates (für Alaska-Verhältnisse)
- in einigen Belangen deutlich schneller als die 1.9er (Debugger, versch. Funktionen)
- Bilder-Handling

So, genug Werbung gemacht

[AUGE_OHR]

hi,

der Thread geht in Richtung v1.9x vs. v2.x was aber nicht das Thema sein sollte weil es wohl beide Versionen betrifft.
während es für die v2.x nun die beiden (Test) DLL gibt wird es wohl keine neuen DLL für die v1.9x geben.

das Problem ist nun das Alaska nicht sagt welches Problem die geändert haben ?!
man müsste nun Reengineering mit den beiden DLLs betreiben ...

Frage : hat jemand Windows 7 mit einem 4k Monitor in Betrieb und Probleme mit Xbase++ Apps

[ramses]

Hallo Leon

da ich keine Kunden habe, die mir vorschreiben, in welcher Entwicklungsumgebung und mit welchen Tools die Programme geschrieben werden,

du hast mich falsch verstanden, mir schreiben die "Sicherheitsrichtlinen" vor jeweils mit den aktuelle Versionen der aller Tools zu arbeiten.
Die Entwicklungsumgebung und die Zusatz DLL's, Source-Code Hinterlegung/Übergabe usw. wurde bereits vorgängig schriftlich genau festgelegt.

sonst möchte ich mit Werners Worte anschliessen.

Die 2 er Version brachte uns nur Vorteile.
Die Workbench benutze ich nicht.
Dafür hat die 2er viele viele Probleme der 1.9XX beseitigt und brachte mir bis auf den erwähnten (üblen) Bug in einem Update nur Vorteile.
Die "Sicherheitsrichtlinen" habe ich anfänglich gehasst, heute bin ich sehr froh darüber.
Es ist tatsächlich so: Vorsprung durch Organisation und Aktuelle-Technik.
Das ist der einzige Weg.
Alaska wird wohl kaum noch Updates zur 1.9xxer liefern, die sind sonst auf breiter Linie im Rückstand und werden wohl kaum noch Zeit in ein längst überholtes Produkt investieren.
Besonders da der Funktionsumfang der 1.9er auf der 2er absolut problemlos läuft......


Gruss Carlo

[Jan]

Um auf das ursprüngliche Thema zurück zu kommen: Aus meinen eigenen Tests weiß ich, das mindestens die 1.9 SL1 und die 2.0 von diesem Problem mit dem 1703 betroffen sind. Also den überwiegenden Teil aller aktuell laufenden Xbase++-Anwendungen betreffen dürfte. Ob auch die 1.9 betroffen ist weiß ich noch nicht, müßte ich ebenfalls mal ausprobieren (ich habe einen Kunden, der tatsächlich aktuell noch mit der 1.9.331 entwickelt!)

Es wird zumindest für die 2.0 einen Fix geben, wohl diese Woche noch. Wie das schon vergangenes Jahr passiert ist, wo es ebenfalls mit dem Windows-Update neue Probleme gab.

Aus früheren Gesprächen mit Alaska-Mitarbeitern weiß ich, das die keine Korrekturen mehr für 1.9.nnn erstellen wollen. Wobei es da immer nur um die üblichen Fehlerkorrekturen ging, da hatte noch niemand geahnt, das MS solche Fallen in seine Updates einbauen würde.

Ich befürchte daher, das es auch hierfür keinen Fix geben wird, obwohl die 1.9 SL1 betroffen ist. Ich würde aber vorschlagen das einer derjenigen Entwickler, die noch produktiv damit arbeiten, bei Alaska mal anfragt. Denn egal was wir hier diskutieren - ohne eine klare Aussage von Alaska wird das immer nur Spekulation, Raten, Mutmaßung bleiben.

Jan

[brandelh]

Ich würde sagen, vor der tatsächlichen Veröffentlichung des FIXes ... wird hier nur spekuliert, auch "offizielle Aussagen" ändern nix daran