21-07-2016, 17:30
|
|
|
|
חבר מתאריך: 14.12.09
הודעות: 9,751
|
|
ציטוט:
במקור נכתב על ידי קוביבי
זה לא סיפור מוזר בכלל, אולי השפה לא הייתה ברורה,
מי שנמצא בתוכנית של Windows Insider יקבל את עדכון הRTM (ה"רשמי") יום לפני כולם, זה הוכרז לפני מספר חודשים, אין קשר ליכולת לדווח על באגים - את זה הם עשו במהלך השנה האחרונה, זו "הטבה" שהם מקבלים על ההשקעה, אבל מי שבתוכנית כבר קיבל גרסה כמעט סופית בכול מקרה בשנה האחרונה ולכן זכה לראות את מרבית השינויים וגם כאלו שלא נכנסו למוצר הסופי.
|
זה עדיין סיפור והוא עדיין חסר היגיון לגמרי.
אם ההטבה היא שהם מקבלים את הגרסה הסופית יום לפני ה-GA אין שום בדרך ביקום שבה יום אחרי זה פתאום הוא יקבל "באגים שלא ייצאו לקהל הרחב". להפך.
ציטוט:
במקור נכתב על ידי קוביבי
14393 אינו הבילד הסופי, הוא הבילד האחרון שנוצר אחרי ה bug-bash האחרון, אבל תהליך האריזה לinsiders ולRTM שונה, ולכן הגרסה כנראה תהייה שונה
|
גבר.
לא אמרתי שהוא הבילד הסופי. אמרתי שהוא יהפוך להיות הבילד הסופי.
ברור שישנו את מספר הבילד למספר "יפה" כמו שעשו בפעמים הקודמות.
וגם יבטלו את זה שהתקנה שלו מכניס אותך למצב של Windows Insider.
והוא גם לא יהיה ב-Developer mode בדיפולט.
והוא גם ידרוש אקטיבציה שונה.
יופי.
אבל הקוד, בניגוד לקונפיגורציה אמור להיסגר, והטענה שעלתה היא שאם לא יתגלה משהו נוראי בעקבות השחרור של 14393 לא נוגעים בה יותר.
ציטוט:
במקור נכתב על ידי קוביבי
ובכול מקרה - הבילד הזה כבר נשלח גם ל slow ring
|
וזה קשור למשהו?
ציטוט:
במקור נכתב על ידי קוביבי
Bash - אכן טבעי = native, אני לא מכיר תרגום אחר למילה זו - אשמח שתאיר את עיני
|
כידוע, טבעי זה natural. המילה העברית ל-native האנגלית היא יליד (שם עצם) או ילידי (שם תואר).
אין תרגום "רשמי" ובמאגר המונחים של האקדמיה יש תרגום בהקשר הסוציולוגי-אנתרופולוגי אבל לא מתחום התוכנה.
אף אחד לא קורא ל-native code קוד ילידי ול-Native Wifi "ויפי ילידי", אבל לתרגם native code כ"קוד טבעי" זה ממש שגיאה גסה ומטעה.
חוץ מזה, בפעם המיליון - גם cygwin וגם mingw מריצים "קוד טבעי". לא זה החידוש.
ציטוט:
במקור נכתב על ידי קוביבי
לגבי השאלה שלך - הכוונה היא שbash אולי יהיה על חלונות - אך לא תהייה לו גישה לחלקים פנימיים של מערכת ההפעלה,
Bash רץ על subsystem פנימי שמייקרוסופט כתבו (בשיתוף עם החבר'ה של אובונטו) אך הוא לא מממש את כל ה System-calls, המטרה היא די ברורה (כדי שאנשים לא יהרסו את מערכת ההפעלה וכדי שאנשים לא יישתמשו במערכת הפעלה שמיועדת ללקוחות ויהפכו אותה לשרת)
http://www.pcworld.com/article/3094...bash-shell.html
קריאה נעימה
|
זה לא עונה על השאלה שלי בשום צורה. והמטרה היא ממש לא המטרה שהמצאת. המטרה היא להיות מסוגל לכתוב pico process שידמה לינוקס והסיבה לחלק מההחלטות לא לממש system calls מסוימות היא שהן לא הגיוניות בהקשר של ווינדוס.
גם הקישור שלך לא עונה על השאלה שלי.
קודם כל, אני ממליץ לקרוא קישור קצת יותר רציני, שכבר הבאתי בפורום בעבר. אבל למה לקרוא את הבלוג של מיקרוסופט כשאפשר לקרוא אתרים אקראיים?...
בקישור אין שום התייחסות לא ל-Win32 ולא ל-AppX. הוא אפילו לא קרוב להסביר מה משמעות המשפט ההזוי הזה:
ציטוט:
במקור נכתב על ידי קוביבי
ל bash לא תהייה יכולת לתקשר עם מערכת ההפעלה או אפליקציות (appx, לא תוכנות win32)
|
קצת עברית, אנא ממך!
מה זה בכלל אמור להביע?
לא תהיה יכולת לתקשר עם "אפליקציות", שזה AppX בעיניך, אבל כן עם תוכנות Win32? כן תוכל לתקשר עם תוכנות Win32 אבל לא עם מערכת ההפעלה? אז... למה שלא תכתוב תוכנת Win32 כשתמש כפרוקסי? מה בכלל אומר המשפט ההזוי הזה?
כשקראתי אותו הבנתי את הקושי העצום של מפתחי מנועי HTML בעבר שנאלצו להתמודד עם עמודים לא-קרובים-לתקניים ולנסות לפרסר אותם בצורה שתציג משהו הגיוני למחצה למשתמש.
ציטוט:
במקור נכתב על ידי קוביבי
תוכנות win32, מהזכור לי בכול אופן - אולי ישבו בחנות אבל תמיד הפנו לאתר של הבעלים
|
נו אז?
ציטוט:
במקור נכתב על ידי קוביבי
הוא לא בדיוק "עוטף" כי אפליקציות רצות לך בsandbox, מה שwin32 לא היה מוגבל אליו
|
הוא בדיוק עוטף ואפליקציות שיצרת עם ה-Desktop App Converter (השם הנוכחי של המוצר) לא רצות ב-AppContainer. אתה יכול לשנות את הקוד שלך לבד ולדאוג שכל הקוד שלך ירוץ בתוך AppContainer, אבל זה לא מה שה-Desktop App Converter עושה.
בחייאת, הכל כתוב:
UWP using Desktop Conversion extensions is a bridge that enables you to convert your classic
desktop application (like Win32, Windows Forms, and WPF) or game to a Universal Windows
Platform (UWP) app or game. For more info, see Guide to UWP apps. After conversion, your
classic desktop app is packaged, serviced, and deployed in the form of a UWP app package
(an .appx or an .appxbundle) targeting Windows 10 Desktop.
There are two parts to the technology that enables desktop apps to be converted to UWP
packages. The first is the Desktop App Converter, which takes your existing binaries and
repackages them as a UWP package. Your code is still the same, it's just packaged differently.
The second piece comprises runtime technologies in the Windows Anniversary update that
enable a UWP package to have executables that run as full trust instead of in an app container.
This technology also gives a converted app a package identity, which is required to use some
UWP APIs.
נחש מאיזה אתר לקחתי את זה.
רמז: זה לא pcworld.com.
כשמדברים על sandbox בהקשר של UWP מדובר על AppContainer. אתה טוען שיש sandbox נוסף, אחר, לאפליקציות שנוצרות על ידי ה-converter?
ציטוט:
במקור נכתב על ידי קוביבי
זה כן uwp כי הbackend זהה
|
בטח, זה UWP.
חוץ מזה שאתה יכול להשתמש בכל ה-Win32 API ולא רק ב-subset של UWP.
ואתה רץ ב-"full trust" ולא ב-AppContainer.
ואתה יכול לרוץ רק על PC (ולא על Windows 10 Mobile או על שאר הפלטפורמות של UWP).
אז אין שום דבר אוניברסאלי בתוכנה שלך, אבל סבבה זה UWP. ה-branding ניצח.
מצד שני, יש כל מיני אמירות על registry and file system virtualization. אבל גם כתוב שלא רצים ב-AppContainer.
מה זה אומר? לי זה לא ברור. אם אתה טוען שברור לך בוא תסביר, בלי לשחק אותה "אני מבין לה לה לה אבל אני לא מספר".
_____________________________________
(קרדיט למרשי)
אמר לה ינאי מלכא לדביתיה אל תתיראי מן הפרושין ולא ממי שאינן פרושין אלא מן הצבועין שדומין לפרושין שמעשיהן כמעשה זמרי ומבקשין שכר כפנחס
אמר פסטן: שניהם גרועים, אבל עדיף להיות טיפש מאשר שקרן.
|