removed by original poster
Last edited:
My Computer
System One
-
- OS
- Windows 7 - Linux (Ubuntu & Zorin) - XP
- System Manufacturer/Model
- iBuyPower
- CPU
- i5-2320 3.00GHz
- Motherboard
- ASRock H61M-VVGS
- Memory
- 8GB
- Graphics Card(s)
- AMD Radeon 6770
What if you can't use Windows 8.1 then what?
- Thread starter KarterJK
- Start date
- Messages
- 1,925
This is an early preview that is released with the understanding that it will have many bugs. Those bugs will be fixed by the time it is released. If you need something stable, you should not be installing beta software.
My Computer
System One
-
- OS
- Windows 8.1 Pro
- CPU
- Intel i7 3770K
- Motherboard
- Gigabyte Z77X-UD4 TH
- Memory
- 16GB DDR3 1600
- Graphics Card(s)
- nVidia GTX 650
- Sound Card
- Onboard Audio
- Monitor(s) Displays
- Auria 27" IPS + 2x Samsung 23"
- Screen Resolution
- 2560x1440 + 2x 2048x1152
- Hard Drives
- Corsair m4 256GB, 2 WD 2TB drives
- Case
- Antec SOLO II
- Keyboard
- Microsoft Natural Ergonomic Keyboard 4000
- Mouse
- Logitech MX
- Messages
- 4,514
- Location
- Germany/Florida
I would say the answer is NO. There was no such announcement from MS and not even any indication from the rumor mill. We'll just have to wait for the RTM.
Now that does not mean that MS wiil not release updates for bug fixes between now and RTM.
My Computer
System One
-
- OS
- Vista and Win7
- System Manufacturer/Model
- 2xHP, 2xGateway, 1xDell, 1xSony
- Hard Drives
- 5 SSDs and 12 HDs
As far as I know, there won't be any more preview/testing versions.
So now is the time to give your feedback around the forums. Fedback is helpful to MS, of course.
My Computer
System One
-
- OS
- 7/8/ubuntu/Linux Deepin
- Computer type
- PC/Desktop
thank you for the response I hope for the later
Sim2 said:
Thank you for the response, I am worried you may be correct since they put this release in the App Store (not the norm for a preview), I fear this may the final with few alterations
My Computer
System One
-
- OS
- Windows 7 - Linux (Ubuntu & Zorin) - XP
- System Manufacturer/Model
- iBuyPower
- CPU
- i5-2320 3.00GHz
- Motherboard
- ASRock H61M-VVGS
- Memory
- 8GB
- Graphics Card(s)
- AMD Radeon 6770
- Messages
- 1,925
This is not going to be the final. And they didn't really put it in the app store. You have to download and install a patch to make it show up in the app store.
There's still 6 months before this will be finished, they have a lot of work to do to finish it. It is likely more or less feature complete, but the bugs have to be fixed.
There's still 6 months before this will be finished, they have a lot of work to do to finish it. It is likely more or less feature complete, but the bugs have to be fixed.
My Computer
System One
-
- OS
- Windows 8.1 Pro
- CPU
- Intel i7 3770K
- Motherboard
- Gigabyte Z77X-UD4 TH
- Memory
- 16GB DDR3 1600
- Graphics Card(s)
- nVidia GTX 650
- Sound Card
- Onboard Audio
- Monitor(s) Displays
- Auria 27" IPS + 2x Samsung 23"
- Screen Resolution
- 2560x1440 + 2x 2048x1152
- Hard Drives
- Corsair m4 256GB, 2 WD 2TB drives
- Case
- Antec SOLO II
- Keyboard
- Microsoft Natural Ergonomic Keyboard 4000
- Mouse
- Logitech MX
My guess is that Win 9 will be released within 12 - 18 months after the RTM for 8.1.
My Computer
System One
-
- OS
- Win 8.1 64bit
- Computer type
- Laptop
- System Manufacturer/Model
- Toshiba
- CPU
- Intel i3, 2348
- Memory
- 4GB
- Graphics Card(s)
- Intel HD3000
yeah, the developer of MetroTwit listed a classic example. currently, the 8.1 preview has a serious bug that affects the touch interface (and lo and behold, MetroTwit got borked by this bug). it will not be patched for the preview version. however, the fix is already in the build that will eventually become the RTM.
when you use a preview or beta, you just have to live with the bugs.
when you use a preview or beta, you just have to live with the bugs.
My Computer
System One
-
- OS
- Windows 8.1 Pro
sayitasitis
New Member
- Messages
- 5
[QUOTE=when you use a preview or beta, you just have to live with the bugs.
Don't you mean when you use a MS product, you just have to live with the bugs.
Don't you mean when you use a MS product, you just have to live with the bugs.
My Computer
System One
-
- OS
- Win 7
Metro isn't a bug - it is a feature... allegedly.
Not even pcdecrapifier can remove it.
My Computer
System One
-
- OS
- 7/8/ubuntu/Linux Deepin
- Computer type
- PC/Desktop
I thought the word Metrotwit was used to describe something else.
Curious if MS will "ask" the dev to stop using the word Metro.
Curious if MS will "ask" the dev to stop using the word Metro.
My Computer
System One
-
- OS
- 7/8/ubuntu/Linux Deepin
- Computer type
- PC/Desktop
- Messages
- 711
- Location
- Cincinnati, Ohio
This reminds me of a story I heard a long time ago in my mainframe days. (Bear with me if you don't know what a mainframe is. )
In the IBM mainframe operating system known (then) as MVS there was a fantastic utility program called IEFBR14. It was so named because all it did was branch to the address in register 14 (BR is the IBM assembly language mnemoinc for the operation "branch to address in register"). Register 14 in mainframe programs was by convention the address of the next intstruction to be executed in the program that called this one - that is, the return address. So, essentially, IEFBR14 just returned control back to the caller.
IBM also used register 15 (by convention) as the "condition code" or error code indicating the outcome of the program call. Typically a zero meant "all is well" while other values like 4, 8, 12, etc., indicated something did not work as expected (or at all). When one program calls another the value in register 15 is usually unpredictable - rarely zero.
The way IBM batch jobs worked was that prior to the execution of the program specified in any step of the batch job, all the dataset (file) allocations required for the program were done. IEFBR14 was a great little do-nothing utility used to create new datasets or delete old ones.
The first version of IEFBR14, as the story goes, was simply one instruction (in assembler, BR 14: that is, branch to the address in register 14). (A "register" was one of 16 temporary storage locations used by a program for things like mathematical operations, addressing, etc.)
That was a bug: the called program is supposed to return a condition code in register 15. Because that didn't happen, the return code from IEFBR14 could be almost anything - when in fact it should have been zero. The non-zero condition code (often used as a check in batch jobs to determine whether the next step should even be executed) could cause all kinds of confusion, especially for a program that presumably did nothing.
The bug fix expanded the program to two lines of assembler code - the new first line of the program cleared register 15 to ensure that IEFBR14 always returns a condition code of zero.
SR 15,15 (subtract the value in register 15 from the one in register 15, storing the result in register 15)
BR 14 (branch to the address in register 14)
My point is this: all software has bugs. Maybe a particular program has been thoroughly debugged over the years but if you're waiting for that bug-free operating system or software package you're going to be waiting a long time.
(I don't have any way to verify this story, nor do I know the origin of it. It could be just another urban (computing) legend.)
)In the IBM mainframe operating system known (then) as MVS there was a fantastic utility program called IEFBR14. It was so named because all it did was branch to the address in register 14 (BR is the IBM assembly language mnemoinc for the operation "branch to address in register"). Register 14 in mainframe programs was by convention the address of the next intstruction to be executed in the program that called this one - that is, the return address. So, essentially, IEFBR14 just returned control back to the caller.
IBM also used register 15 (by convention) as the "condition code" or error code indicating the outcome of the program call. Typically a zero meant "all is well" while other values like 4, 8, 12, etc., indicated something did not work as expected (or at all). When one program calls another the value in register 15 is usually unpredictable - rarely zero.
The way IBM batch jobs worked was that prior to the execution of the program specified in any step of the batch job, all the dataset (file) allocations required for the program were done. IEFBR14 was a great little do-nothing utility used to create new datasets or delete old ones.
The first version of IEFBR14, as the story goes, was simply one instruction (in assembler, BR 14: that is, branch to the address in register 14). (A "register" was one of 16 temporary storage locations used by a program for things like mathematical operations, addressing, etc.)
That was a bug: the called program is supposed to return a condition code in register 15. Because that didn't happen, the return code from IEFBR14 could be almost anything - when in fact it should have been zero. The non-zero condition code (often used as a check in batch jobs to determine whether the next step should even be executed) could cause all kinds of confusion, especially for a program that presumably did nothing.
The bug fix expanded the program to two lines of assembler code - the new first line of the program cleared register 15 to ensure that IEFBR14 always returns a condition code of zero.
SR 15,15 (subtract the value in register 15 from the one in register 15, storing the result in register 15)
BR 14 (branch to the address in register 14)
My point is this: all software has bugs. Maybe a particular program has been thoroughly debugged over the years but if you're waiting for that bug-free operating system or software package you're going to be waiting a long time.
(I don't have any way to verify this story, nor do I know the origin of it. It could be just another urban (computing) legend.)
My Computer
System One
-
- OS
- Windows 7 x64
All non trivial software has bugs. That is a fact of life we must accept. I understand that NASA has a development procedure that greatly reduces the incidence of bugs, but doesn't eliminate them. The problem is that it is very expensive, prohibitively so for a commercial software company. Only where the cost of software is a small portion of the complete project and the consequences of failure so serious can the cost be justified.
My Computer
System One
-
- OS
- Windows 7
- Computer type
- PC/Desktop