Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
( http://www.kbalertz.com/technology_3.aspx).
If you are going to use .Net......I highly recommend signing up for the free
KBAlertz newsletter at http://www.kbalertz.com/default.aspx.
Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.
I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........ isn't it?
Jim Hubbard 14  2322 
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:0Y******** ************@gi ganews.com... Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).
Ah. Selling Thinstall by means of FUD?
"Michael A. Covington" <lo**@ai.uga.ed u.for.address> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:0Y******** ************@gi ganews.com... Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).
Ah. Selling Thinstall by means of FUD?
Nah Thinstall sells itself. Once you try it - you're hooked. And,
Thinstall is not .Net specific. It also works with Visual Basic and C++
applications. (I really need to learn C++.....know of any books for fast
learners? My attention span can't handle most dry, drawn out manuals.)
I am just surprised at the number of errors you run into while programming
..Net. It can be frustrating, and this site can help with that.
To be complete honest, I am not a fan of .Net. I liked classic VB. It was
easy, it was RAD, it was just what I (and 3,000,000+ other developers)
needed.
..Net removed the RAD from VB, added complexity that 98% of the classic VB
developers never asked for, didn't desire and will never use. For me,
VB.Net sucks.
..Net is the death of VB. I wish they had been honest enough to name VB.Net
something else.....like B#. It would be like C# - where the syntax is
similar to JAVA, but that's all that's similar.
If we hadn't been lead to believe that this .Net stuff was a continuation of
VB, there would be less of an uproar. Of course, there'd be fewer B#
developers, but there are fewer VB developers with the current approach - so
it wouldn't really matter.
I'm concerned that Microsoft has again rushed a product to market full of
holes. This product (.Net framework) in particular can produce problems
with much more than a simple desktop app. Screw-ups here affect company
bottom lines....and that affects the economy.
Sometimes its REALLY important to get things right the first time.
Jim Hubbard
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:uJ******** ************@gi ganews.com...
Nah Thinstall sells itself. Once you try it - you're hooked. And,
Thinstall is not .Net specific. It also works with Visual Basic and C++
applications. (I really need to learn C++.....know of any books for fast
learners? My attention span can't handle most dry, drawn out manuals.)
I am just surprised at the number of errors you run into while programming
.Net. It can be frustrating, and this site can help with that.
To be complete honest, I am not a fan of .Net. I liked classic VB. It
was easy, it was RAD, it was just what I (and 3,000,000+ other
developers) needed.
.Net removed the RAD from VB, added complexity that 98% of the classic VB
developers never asked for, didn't desire and will never use. For me,
VB.Net sucks.
.Net is the death of VB. I wish they had been honest enough to name
VB.Net something else.....like B#. It would be like C# - where the syntax
is similar to JAVA, but that's all that's similar.
If we hadn't been lead to believe that this .Net stuff was a continuation
of VB, there would be less of an uproar. Of course, there'd be fewer B#
developers, but there are fewer VB developers with the current approach -
so it wouldn't really matter.
I'm concerned that Microsoft has again rushed a product to market full of
holes. This product (.Net framework) in particular can produce problems
with much more than a simple desktop app. Screw-ups here affect company
bottom lines....and that affects the economy.
Sometimes its REALLY important to get things right the first time.
Jim Hubbard
FUD, regardless. Many of us are using the .NET Framework successfully
despite your list. FUD, regardless. Many of us are using the .NET Framework successfully
despite your list.
Correction: Microsoft's list.
Please note that all 1,500+ are listed in the Microsoft KB.
What would be cool is if Microsoft allowed you to actually download the
fixes WITHOUT having to call and talk to a Microsoft rep. This calling for
every fix is beyond stupid. Not to mention it's absolutely atrocious
customer service.
If the .Net framework (which has an integrated browser) checked for fixes,
told us what the fixes affected and allowed us to select which fixes to
install it'd be more on par with the Windows Update service.
But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.
If you apply a "fix" to your development boxes, you can be damned sure that
99.9% of your external users will NOT have this "fix" installed. That makes
the .Net runtimes incompatible. Now we're right back where we were with DLL
Hell - except it's "fixes" missing instead of overwritten files.
..Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.
And (joy of joys), if a customer installs a "fix" for another vendor's
application, it may cause unintended consequences in your .Net application.
And, again - you are screwed. Like it or not, Thinstall app are immune
from this "fix" issue.
Don't throw FUD at me just because you are unfamiliar with the tool that you
are placing your company's future on.
Jim Hubbard
Jim Hubbard wrote: FUD, regardless. Many of us are using the .NET Framework successfully
despite your list. Correction: Microsoft's list.
Fix-lists are good for seeing how actively things get fixed, their level
of detail reflects how maticulous the bug-tracking is.
This makes fix-lists a very bad tool for evaluating stability for a
specific application, but a very good way to evaluate which effort, and
quality of effort is put into improving erorrs.
If the list spreads FUD, then it is because it is interpreted wrongly.
To me it indicates that an active effort is done to improve .NET.
What would be cool is if Microsoft allowed you to actually download the
fixes WITHOUT having to call and talk to a Microsoft rep. This calling for
every fix is beyond stupid. Not to mention it's absolutely atrocious
customer service.
Actually, I haven't needed any of the fixes yet, but if such a
requirement exists, then I would agree with you; that's simply silly.
If the .Net framework (which has an integrated browser) checked for fixes,
told us what the fixes affected and allowed us to select which fixes to
install it'd be more on par with the Windows Update service.
That would be a nice feature. An API for doing it programmaticly would
be even nicer.
Being able to identify which fixes have been installed would be
marvelous (inspecting the registry sucks, it would be nice to have it
"from the horses mouth": the binary).
But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.
That's what fix, SP, "new version", etc. means. Everyone has to start
somewhere, code has bugs.
The CLR provides a virtual machine that fits many languages needs for an
execution run-time. This removes all kinds of problems with
calling-conventions, struct-layout, and numerous c++ ABI problems. It is
possible to share code across languages, and c++-compilers in CLR.
That's the "end-all" part.
That you can now share much more code open up new problems, as you
observe, but they are definatly "better" problems than writing all the
code you use from .NET yourself :)
If you apply a "fix" to your development boxes, you can be damned sure that
99.9% of your external users will NOT have this "fix" installed. That makes
the .Net runtimes incompatible. Now we're right back where we were with DLL
Hell - except it's "fixes" missing instead of overwritten files.
There is no other way, if you want to share code; it's for better and
worse, in sickness and health. The good part is, it's not 'til death do
you part, you can ask the client to fix his .NET (may be hard enough,
esp. if they got a sysadmin -- whoose job it is to do these things :).
The other good news is, that you can ship your own .NET dll with the fix
if you need, and DLL-hell isn't there, you can actually have two DLL's
with different names opened in .NET, and *use* them with minimal effort.
(have you tried dynamic-loading under WIN32?)
.Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.
Well, autoupdates are evil, you know what you have, and if it doesn't
*need* fixing, don't apply the fix, simple rule of keeping things alive.
You know the old bugs, the new ones are the ones that hurts.
And (joy of joys), if a customer installs a "fix" for another vendor's
application, it may cause unintended consequences in your .Net application.
And, again - you are screwed. Like it or not,
That's what sharing code does. Often, it doesn't cause too much trouble,
but sometimes (and those are frustrating times, I'll admit that) you
(often implicitly) depended on buggy behaviour that meant that your code
didn't exhibit it's own bugs.
Thinstall app are immune
from this "fix" issue.
If I read the docs correctly, it does this exactly by packaging the
transitive closure of the code (and registry information) of the
developer-machine and run that in a virtual machine. This sounds like a
nice solution when you have enough problems with different versions of
things: You get exactly the bugs that the developer-machine have,
nothing more, nothing less -- of course including the bugs in thinstall,
but you can try those out before you ship.
In the days gone by, this was static linking, which was really not an
option back then -- storage-space was expensive.
Strong-naming in .NET provides for some of the benefis and drawbacks of
static-linkage, but also (largely) prevents fix-after-ship with small
amounts of data and is a pain to use.
Don't throw FUD at me just because you are unfamiliar with the tool that you
are placing your company's future on.
Well, I guess the amount of problems people have with .NET differs
greatly. I got some nags about C#, found a few leaks and bugs in the
libs, but I worked them out.
The important thing for me is that the bugs that i've seen are a *lot*
easier to find than back in the c++ days (/me thinks back to the month
spent debugging untill it was discovered that std::string::st ring(const
std::string&) wasn't thread-safe).
--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
"Helge Jensen" <he**********@s log.dk> wrote in message
news:OA******** ******@TK2MSFTN GP12.phx.gbl... Jim Hubbard wrote:
FUD, regardless. Many of us are using the .NET Framework successfully
despite your list. Correction: Microsoft's list.
Fix-lists are good for seeing how actively things get fixed, their level
of detail reflects how maticulous the bug-tracking is.
This makes fix-lists a very bad tool for evaluating stability for a
specific application, but a very good way to evaluate which effort, and
quality of effort is put into improving erorrs.
If the list spreads FUD, then it is because it is interpreted wrongly. To
me it indicates that an active effort is done to improve .NET.
I think it can be interpreted both ways. Good point.
What would be cool is if Microsoft allowed you to actually download the
fixes WITHOUT having to call and talk to a Microsoft rep. This calling
for every fix is beyond stupid. Not to mention it's absolutely atrocious
customer service.
Actually, I haven't needed any of the fixes yet, but if such a requirement
exists, then I would agree with you; that's simply silly.
If the .Net framework (which has an integrated browser) checked for
fixes, told us what the fixes affected and allowed us to select which
fixes to install it'd be more on par with the Windows Update service.
That would be a nice feature. An API for doing it programmaticly would be
even nicer.
Amen!
Being able to identify which fixes have been installed would be marvelous
(inspecting the registry sucks, it would be nice to have it "from the
horses mouth": the binary).
Doesn't seem like it'd be hard to list the .Net needs in the assembly.
Here's hoping they will.
But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.
That's what fix, SP, "new version", etc. means. Everyone has to start
somewhere, code has bugs.
Mine too. But, when the IDE and framework is buggy and they are running on
a buggy OS, it concerns me. Especially since I subscribe to KBAlertz and
see a new "problem" almost every day. Honestly, it shakes my faith in the
framework.
The CLR provides a virtual machine that fits many languages needs for an
execution run-time. This removes all kinds of problems with
calling-conventions, struct-layout, and numerous c++ ABI problems. It is
possible to share code across languages, and c++-compilers in CLR. That's
the "end-all" part.
These are the things that VB developers (the camp I'm from originally) have
never worried about. So, these neat new things mean virtually nothing to
the 3,000,000+ classic VB users like myself.
That you can now share much more code open up new problems, as you
observe, but they are definatly "better" problems than writing all the
code you use from .NET yourself :)
With the mountain of 3rd party controls available, code sharing also was not
an issue for classic VB users. It's just one more thing that we didn't ask
for, need or have any plans to use.
If you apply a "fix" to your development boxes, you can be damned sure
that 99.9% of your external users will NOT have this "fix" installed.
That makes the .Net runtimes incompatible. Now we're right back where we
were with DLL Hell - except it's "fixes" missing instead of overwritten
files.
There is no other way, if you want to share code;
I never wanted to share code. But, I wrote and shared activeX controls.
Maybe that's the break I'm having with this whole .Net thing. It's an
answer to a problem I never had.
it's for better and worse, in sickness and health. The good part is, it's
not 'til death do you part, you can ask the client to fix his .NET (may be
hard enough, esp. if they got a sysadmin -- whoose job it is to do these
things :).
And, if your changes break another developer's stuff, they ask them to
change back and now you're back to being broken. The end user then has to
decide which app to throw out. Let's hope it's not yours.
The other good news is, that you can ship your own .NET dll with the fix
if you need, and DLL-hell isn't there, you can actually have two DLL's
with different names opened in .NET, and *use* them with minimal effort.
(have you tried dynamic-loading under WIN32?)
But you can't (AFAIK) ship the actual .Net framework DLLs with your
application - without using something like Thinstall. If they have applied
a "fix" that patches core functionality of the .Net framework, and you coded
around the bug the "fix" fixed - your code will not run correctly on their
system.
You have always been able to ship your own DLLs with Win32 apps - just drop
them in the same directory as your EXE and use that directory as your
"working" directory. This actually ends "DLL Hell" without a need for a new
language.
.Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.
Well, autoupdates are evil, you know what you have, and if it doesn't
*need* fixing, don't apply the fix, simple rule of keeping things alive.
True. But, having a slew of clients with disparate .Net frameworks will
also be no walk in the park.
You know the old bugs, the new ones are the ones that hurts.
And its the "fix" that puts the new bugs in....
And (joy of joys), if a customer installs a "fix" for another vendor's
application, it may cause unintended consequences in your .Net
application. And, again - you are screwed. Like it or not,
That's what sharing code does. Often, it doesn't cause too much trouble,
but sometimes (and those are frustrating times, I'll admit that) you
(often implicitly) depended on buggy behaviour that meant that your code
didn't exhibit it's own bugs.
What is the big deal with "sharing code"? I am not getting it.
Thinstall app are immune from this "fix" issue.
If I read the docs correctly, it does this exactly by packaging the
transitive closure of the code (and registry information) of the
developer-machine and run that in a virtual machine. This sounds like a
nice solution when you have enough problems with different versions of
things: You get exactly the bugs that the developer-machine have, nothing
more, nothing less -- of course including the bugs in thinstall, but you
can try those out before you ship.
Good thing is that if it works when you ship it, it should work for all
supported OSs without altering their systems. And, their changes shouldn't
affect your aplication.
In the days gone by, this was static linking, which was really not an
option back then -- storage-space was expensive.
Strong-naming in .NET provides for some of the benefis and drawbacks of
static-linkage, but also (largely) prevents fix-after-ship with small
amounts of data and is a pain to use.
Don't throw FUD at me just because you are unfamiliar with the tool that
you are placing your company's future on.
Well, I guess the amount of problems people have with .NET differs
greatly. I got some nags about C#, found a few leaks and bugs in the libs,
but I worked them out.
Cool! It's nice when things work out.
The important thing for me is that the bugs that i've seen are a *lot*
easier to find than back in the c++ days (/me thinks back to the month
spent debugging untill it was discovered that std::string::st ring(const
std::string&) wasn't thread-safe).
Hehehe.......ev en the lowly VB developers had those days. I don't think
we'll ever see the end of those weird time-sucking problems. But that's
just a part of programming.
In my mind, the thing that seems to frustrate me is that my favorite
language is being killed (VB 6) instead of fixed and extended. It has been
replaced by something that only has syntax in common with my trusted classic
VB.
I am told that it is because I can now have all of this new functionality
that I never desired, asked for and can see no reason to use. It's added
complexity, reduced the RAD development capabilities and hasn't provided an
adequate tool for upgrading VB6 apps to the new language.
My old language was great for RAD development of office applications (even
for web apps - if you bothered to learn about activeX documents and controls
that would run in IE).
For me, .Net is an answer to a problem that didn't exist. And, I have daily
reminders of the flaws in .Net that makes it just as buggy as my old
solution - if not more so.
Sharing code meant writing activeX controls or classes. Now, by simply
distributing your application you have essentially joined the open source
movement.
Progress....rig ht.
Jim Hubbard
Funny, we've been using c# extensively since beta 1, and experienced no
problems. Mind you, we have writen our own stuff from primitives, such as
O/R mapper and dont used datasets etc, but we've got a full ERP system
hosted as Web Services with stateful user sessions. So far, so memory
leaks, no crashes, no hacks. Thats in over 4 years totals, and about 2
years live in production. If there are bugs, they are not in the core
functionality. Overall, .NET and the CLR are one of the best things MS has
ever done (although I do miss MI, and see no need for so many languages - c#
will do fine).
Radek
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:0Y******** ************@gi ganews.com... Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).
If you are going to use .Net......I highly recommend signing up for the
free KBAlertz newsletter at http://www.kbalertz.com/default.aspx.
Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.
I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........ isn't it?
Jim Hubbard
"Jim Hubbard" wrote: Are you up to speed on the difficulties in using the 1.1 .Net framework?
Not if you are unaware of the 1,596 issues listed at KBAlertz
(http://www.kbalertz.com/technology_3.aspx).
Yea, im sure all 1500+ issues affect typical day-to-day development. We've
been doing large, complex apps with .NET since beta and I can think of maybe
3 or 4 times a KB item has applied.
If you are going to use .Net......I highly recommend signing up for the free
KBAlertz newsletter at http://www.kbalertz.com/default.aspx.
Looking at all of the errors and quirks sometimes makes me wonder if this
thing is really ready for prime time.
Are you aware that there are even more KB items for your favorite tool VB6?
And VC++ 6.0 has almost twice as many as .NET? So in your professional
opinion VB6 and VC++ 6.0 may not be ready for primetime. Thanks for the tip.
I still think Microsoft is using us as the world's largest beta test group
for it's own internal initiatives. But, that's just my paranoia shining
through........ isn't it?
Jim Hubbard
If this is the typical of the logic and reasoning skills you use in your
daily job, its no wonder that you are having difficulties adjusting to .NET
development, which really isnt difficult at all as long as you stop wasting
brainpower on constantly crying "but it didnt work like this in VB6 or ASP!"
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:mr******** ************@gi ganews.com...
Correction: Microsoft's list.
Please note that all 1,500+ are listed in the Microsoft KB.
What would be cool is if Microsoft allowed you to actually download the
fixes WITHOUT having to call and talk to a Microsoft rep. This calling
for every fix is beyond stupid. Not to mention it's absolutely atrocious
customer service.
If the .Net framework (which has an integrated browser) checked for fixes,
told us what the fixes affected and allowed us to select which fixes to
install it'd be more on par with the Windows Update service.
But, doing so would show that the .Net framework is no the end-all-be-all
solution that Microsoft said it was.
If you apply a "fix" to your development boxes, you can be damned sure
that 99.9% of your external users will NOT have this "fix" installed.
That makes the .Net runtimes incompatible. Now we're right back where we
were with DLL Hell - except it's "fixes" missing instead of overwritten
files.
.Net has not and cannot deliver the experience Microsoft has promised
without automatic updates (including fixes) to all .Net-capable desktops.
And (joy of joys), if a customer installs a "fix" for another vendor's
application, it may cause unintended consequences in your .Net
application. And, again - you are screwed. Like it or not, Thinstall app
are immune from this "fix" issue.
Don't throw FUD at me just because you are unfamiliar with the tool that
you are placing your company's future on.
Jim Hubbard
Maybe you're just having trouble adapting to change. Every major development
tool has long lists of open "bugs", including the now *very* mature VS 6.
Microsoft, unlike some competing vendors, chooses to make the issues public
so we *are* aware of potential problems. Try getting a list of open "bugs"
from Oracle.
It appears to be you who wants to apply the "chicken little" spin to the
situation. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Jerome Lefebvre |
last post by:
Hello,
Hope this will interest a few. I been working with a friend on the
problems given out during the "International Collegiate Programming Contest"
(ICPC) http://icpc.baylor.edu/icpc/ . Started out just trying to find the
solutions and then moving on, to "aggressively" trying to find the best
solution for each problems. First started to work on the problems using
C++ and then moved on to using Python, mostly since it was much easier...
|
by: 3f |
last post by:
Hello;
We have made a web application that people can download from our web site
and installed on:
Windows XP
Windows 2000 Professional
Windows 2003 Server
Windows 2000 Server
|
by: Corky |
last post by:
This works:
db2 SELECT DISTINCT PROBLEM_OBJECTS.PROBLEM_ID FROM PROBLEM_OBJECTS
INNER JOIN PROBLEMS ON PROBLEM_OBJECTS.PROBLEM_ID =
PROBLEMS.PROBLEM_ID WHERE INTEGER(DAYS(CURRENT DATE) -
DAYS(PROBLEMS.CLOSE_DATE)) = 365 AND PROBLEMS.CLOSE_DATE IS NOT NULL
But this doesn't:
db2 SELECT DISTINCT PROBLEM_OBJECTS.PROBLEM_ID FROM PROBLEM_OBJECTS
|
by: Ellen Graves |
last post by:
I am having a lot of problems with DB2 8.3.1 on RH Linux AS2.1.
Installing and running stored procedures is problematic. Stored
procedures I have used for years on V7 on WinNT are now failing
multiple times/day.
Data that exists in the db is not returned with a select *, but is
returned when a where clause with a primary key value is specified.
There are other problems, including the db crashing in the middle of a
simple query.
|
by: Jim |
last post by:
I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines...
| | |
by: BBFrost |
last post by:
We just recently moved one of our major c# apps from VS Net 2002 to VS Net
2003. At first things were looking ok, now problems are starting to
appear.
So far ...
(1) ComboBox.SelectedValue = db_value;
If the db_value was not included in the ComboBox value list the
ComboBox.SelectedIndex used to return -1, Now the very same code is
|
by: Dales |
last post by:
I have a custom control that builds what we refer to as "Formlets"
around some content in a page. These are basically content "wrapper"
sections that are tables that have a colored header and provide an
open TD with a DIV in it for the content of this formlet. (The DIV is
for DHTML to hide and show the content)
I've created a web page showing step by step the two problems I'm
encountering. This problem is much easier to see than it...
|
by: Brian |
last post by:
NOTE ALSO POSTED IN
microsoft.public.dotnet.framework.aspnet.buildingcontrols
I have solved most of my Server Control Collection property issues.
I wrote an HTML page that describes all of the problems that I have
encountered to date and the solutions (if any) that I found.
http://users.adelphia.net/~brianpclab/ServerControlCollectionIssues.htm
This page also has all of the source code in a compressed file that you are
free to download...
|
by: Sergistm |
last post by:
Hello World, :D
I have a problem that it is making me crazy, I hope you can help me.
I'm trying to execute a .exe file with the Procces.Start, and there
is no problem when the file is on my computer, the problem comes when
the file is in a network drive.
The most amazing thing is that in one computer I can
execute my .Net program without problems independently if the file is
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| | |
